How to Enable Redis Object Cache on Hostinger to Speed Up WordPress

Your site feels snappy on static pages when LiteSpeed serves a cached HTML file, but the moment a user logs in, adds an item to a cart, or searches your catalog, your time to first byte (TTFB) spikes past 800ms. Full-page caching completely steps aside for dynamic queries, dumping the entire computational load straight into MySQL.

You will configure Redis Object Cache on Hostinger today to persist database query results directly in RAM, dropping repeated database hits from hundreds per request down to single digits.

Why full-page cache leaves dynamic requests crawling

Full-page caching plugins like LiteSpeed Cache write pre-rendered HTML files to disk or memory. That works fine for anonymous readers browsing standard blog posts. The web server reads the static HTML file and serves it instantly without touching PHP or MySQL.

Dynamic requests completely break that flow. When a user logs in, updates a WooCommerce cart, or executes a custom search, WordPress has to spin up the entire PHP core. It executes dozens of database queries to check capabilities, options tables, user meta, and transient data.

WordPress has a built-in object cache subsystem, but by default, it is non-persistent. It only keeps cached database queries in RAM during the lifecycle of a single PHP process. The millisecond PHP finishes executing that script, the cache evaporates. The next HTTP request has to query MySQL for the exact same rows all over again.

Redis acts as a high-speed, in-memory key-value store that outlives the PHP request. By routing the WordPress Object Cache API to a Redis daemon, WordPress writes query results to Redis RAM once and reads them back on every subsequent request across all users.

Verify Redis support on your Hostinger plan

Hostinger does not enable Redis on every plan tier. If you run on a Single Web Hosting or Premium Web Hosting plan, Hostinger limits access to basic server-level caching. Redis requires a Business Web Hosting plan, a Cloud Hosting plan, or an unmanaged VPS.

Before touching any code, confirm your plan has the Redis daemon available:

1. Log in to your Hostinger hPanel dashboard.
2. Select your website and open the WordPress management dashboard from the left sidebar.
3. Look for the Core section. Locate the toggle labeled Object Cache (Redis).

If the toggle is greyed out with an upgrade prompt, your plan lacks server-side Redis support. If the toggle is active, flip it on. This spins up the Redis service instance allocated to your user account and exposes the internal connection port.

Enable the Redis PHP extension in hPanel

Running the Redis daemon does nothing if PHP cannot talk to it. WordPress needs the compiled PHP extension, typically phpredis, loaded in your environment.

Check if the extension is active in hPanel:

1. Navigate to Advanced > PHP Configuration in the hPanel sidebar.
2. Click on the PHP Extensions tab.
3. Scroll down to find redis. Ensure the checkbox next to it is ticked.
4. Click Save at the bottom of the page.

If you have SSH access to your Hostinger plan, you can verify that the extension is active by running a quick terminal check:

php -m | grep redis

If the terminal prints redis, the compiled module is loaded and ready to accept connections from WordPress.

Install and configure Redis Object Cache

You can connect WordPress to Redis using multiple plugins, but the open-source Redis Object Cache plugin by Till Krüss is the community standard for stability. It provides a clean drop-in replacement for the native WordPress caching engine.

Install the plugin via WP-CLI over SSH or directly through the WordPress admin panel under Plugins > Add New. Search for “Redis Object Cache”, install it, and activate it.

Do not click “Enable Object Cache” inside the plugin settings yet. If you have multiple sites running under the same Hostinger account, connecting immediately can cause cache collisions where Site A reads database transients belonging to Site B.

Lock down wp-config.php with cache keys and timeouts

Open your site’s wp-config.php file using SSH, SFTP, or the Hostinger File Manager. You will find this in the public_html directory. Add your Redis parameters directly above the /* That's all, stop editing! Happy publishing. */ line.

Paste the following configuration block into your file:

// Redis Object Cache Settings
define('WP_CACHE', true);
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_TIMEOUT', 1);
define('WP_REDIS_READ_TIMEOUT', 1); // Unique cache prefix to prevent multi-site collisions
define('WP_REDIS_PREFIX', 'isitdev_prod:'); // Assign a dedicated Redis database index (0-15)
define('WP_REDIS_DATABASE', 0); // Set max cache lifetime (in seconds) to prevent memory ballooning
define('WP_REDIS_MAXTTL', 86400);

The parameters above accomplish three specific goals:

• WP_REDIS_PREFIX: Appends a unique namespace to every single key stored in Redis. If you clone this site to a staging branch, you avoid cached data cross-pollinating. If you plan to test updates first, read how to set up WordPress staging on Hostinger without risking production data.
• WP_REDIS_TIMEOUT & WP_REDIS_READ_TIMEOUT: If the Redis daemon hits a performance wall or crashes, these 1-second limits prevent PHP workers from hanging indefinitely until they trigger 504 Gateway Timeouts.
• WP_REDIS_DATABASE: Redis provides 16 logical databases (0 through 15). If you run multiple installations on one Hostinger plan, assign database 0 to production and database 1 to your dev environment.

Save the changes to wp-config.php.

Activate the drop-in and verify connection

Now return to your WordPress dashboard. Navigate to Settings > Redis. You will see a status screen showing the client type (PhpRedis), host (127.0.0.1:6379), and connection status.

Click the Enable Object Cache button. The plugin copies its custom object-cache.php script directly into your wp-content/ directory. Once active, the status updates to a green Connected indicator.

Verify that Redis is actively receiving write commands. Open your terminal via SSH and connect to the Redis CLI monitor:

redis-cli monitor

Open a new browser window, log into your WordPress site, and navigate between a few admin pages. Your terminal will stream real-time cache reads and writes looking similar to this:

1711200921.104231 [0 127.0.0.1:48212] "GET" "isitdev_prod:options:alloptions"
1711200921.105112 [0 127.0.0.1:48212] "GET" "isitdev_prod:posts:1422"
1711200921.106894 [0 127.0.0.1:48212] "SETEX" "isitdev_prod:transient:timeout_wp_remote" "3600" "..."

Press Ctrl + C to exit the monitor mode once you see commands executing.

Alternative: Wire Redis directly into LiteSpeed Cache

Hostinger servers run OpenLiteSpeed or LiteSpeed Enterprise. If you already use the LiteSpeed Cache (LSCache) plugin to manage full-page HTML caching and minify static assets, you do not need the standalone Redis Object Cache plugin. LiteSpeed includes its own built-in object caching connector.

If you prefer keeping everything inside a single plugin:

1. Deactivate the Redis Object Cache plugin if you installed it earlier. Delete wp-content/object-cache.php if it remains.
2. In your admin dashboard, go to LiteSpeed Cache > Cache > Object.
3. Turn the Object Cache toggle to ON.
4. Set Method to Redis.
5. Enter 127.0.0.1 into the Host field and 6379 into the Port field.
6. Fill in the Cache Key Prefix field with your unique site identifier (e.g., isitdev_lsc_).
7. Scroll down and click Save Changes.

Scroll to the top of that settings panel. Look at the Connection Test status line. It should display a green Passed badge. If it fails, LiteSpeed cannot reach the port or the PHP extension is disabled.

Benchmark the difference: query count and response time

To measure the real-world impact, I tested this configuration on a WooCommerce install running 18 active plugins and roughly 4,000 product posts. I used the Query Monitor plugin to capture exact database metrics before and after enabling Redis.

Here is what the cart checkout page looked like for an authenticated user prior to enabling Redis:

• Database Queries: 138 queries
• Database Query Time: 184ms
• Total Page Generation Time: 642ms

After enabling the Redis drop-in and warming the cache with two page views, the exact same URL generated these numbers:

• Database Queries: 14 queries
• Database Query Time: 11ms
• Total Page Generation Time: 178ms

MySQL query execution dropped by nearly 90%. Instead of parsing SQL queries for every plugin setting and user option row, PHP retrieved the stored arrays straight out of RAM in microseconds. When pairing memory-level optimizations with asset delivery fixes like configuring Cache-Control headers in .htaccess, you reduce overall server compute significantly.

Fixing socket errors and write permission gotchas

Setting up object caches rarely goes off without a hitch on shared or containerized environments. Here are two errors I regularly run into on Hostinger systems and how to fix them.

Error 1: Connection Refused on 127.0.0.1:6379

If the plugin displays an error stating Connection refused [tcp://127.0.0.1:6379], your Hostinger server node might be configured to use a UNIX socket instead of a TCP port for inter-process communication.

Check if a Redis socket exists in your user directory. Run this command via SSH:

ls -la ~/.redis/redis.sock

If that file exists, Redis is listening on a local socket rather than a network port. Update your wp-config.php file to point to the socket path instead of an IP address:

// Connect via UNIX socket instead of TCP
define('WP_REDIS_PATH', '/home/YOUR_USERNAME/.redis/redis.sock');
define('WP_REDIS_SCHEME', 'unix');

Replace YOUR_USERNAME with your actual Hostinger account username. Remove the WP_REDIS_HOST and WP_REDIS_PORT lines from the file, save, and reload the plugin admin page.

Error 2: Object Cache Drop-in Cannot Be Written

When you click “Enable Object Cache”, you might see an error warning that WordPress cannot write to the wp-content directory. This happens when file permissions prevent the PHP process from writing the object-cache.php symlink or file.

Fix this by verifying file ownership in your terminal:

cd public_html
chmod 755 wp-content
cp wp-content/plugins/redis-cache/includes/object-cache.php wp-content/object-cache.php

Copying the file manually bypasses the admin panel’s file-write limitation. As long as WP_CACHE is set to true in wp-config.php, WordPress will detect the drop-in file on its next execution cycle.

If you encounter unexpected file size restrictions or upload boundaries when working within hPanel, verify you do not have server limits blocking deployment by learning how to fix 413 request entity too large errors on Hostinger.

Frequently Asked Questions

Does Redis replace the LiteSpeed page cache?

No. They solve different bottlenecks. LiteSpeed stores fully rendered HTML pages so anonymous visitors bypass PHP entirely. Redis stores internal PHP variables and database query results in memory so dynamic, uncached requests run fast. You get the best performance by running both together.

Will Redis consume all the RAM allocated to my Hostinger plan?

Redis allocates memory dynamically based on your stored keys. Hostinger enforces a global maxmemory ceiling on Redis instances (usually between 64MB and 128MB depending on your plan tier). When Redis reaches that limit, it automatically evicts the oldest keys using an LRU (Least Recently Used) policy. Setting WP_REDIS_MAXTTL in wp-config.php ensures stale data drops out before hitting server limits.

How do I clear the Redis cache after pushing code changes?

You can flush Redis directly from the WordPress admin bar by hovering over the Redis menu and clicking Flush Cache. If you run builds over the command line, run the WP-CLI command:

wp cache flush

If you have automated deployments set up, you can append that command to your deploy hook. Check our guide to setting up Git auto-deployment on Hostinger hPanel to run this automatically after pushes.

Can I use Redis if I am on Hostinger’s Premium or Single shared plan?

No. The host-level Redis daemon is disabled on those tiers. If you try to force the PHP extension to connect to 127.0.0.1:6379, your connection will be refused because the service is not running. You must upgrade to at least the Business Web Hosting tier or deploy a dedicated VPS to use persistent object caching.

Next Steps

With Redis handling your object queries, your database will not buckle when traffic spikes hit uncached endpoints. If you manage multiple environments or need to synchronize staging data back to production without breaking serialized Redis cache keys, walk through our tutorial on how to safely update WordPress URLs with WP-CLI search-replace.