Enable Redis Object Cache for WordPress in Hostinger hPanel

Your page speed scores look great on static blog posts, but response times spike past 1,200ms the moment a user logs in, loads a cart, or triggers an AJAX filter. Full-page caching cannot help here because the server has to query MySQL for personalized data on every single request.

To cut that database overhead down to single-digit milliseconds, we need an in-memory key-value store. This tutorial walks through enabling the native Redis instance in Hostinger hPanel, configuring your wp-config.php file, mounting the object cache drop-in, and verifying memory hits via the terminal.

Why Page Caching Leaves Dynamic Queries Behind

Full-page caching plugins like LiteSpeed Cache or WP Super Cache write complete HTML snapshots to disk or server RAM. When an anonymous visitor requests your homepage, the web server returns that cached HTML file directly without running PHP or querying MySQL.

That system breaks down on dynamic requests. When a customer adds an item to a WooCommerce cart, submits a form, or browses the /wp-admin/ dashboard, the caching engine must bypass static HTML to show current user data.

Without an object cache, WordPress executes dozens of repeated SQL queries against the wp_posts, wp_postmeta, and wp_options tables. If your options table suffers from runaway transients, query execution times slow down the whole PHP worker. Before moving forward, you may want to clean up bloated wp_options autoload data with WP-CLI so Redis does not ingest megabytes of unneeded junk on every boot.

Redis intercepts these repeated SQL queries. Instead of querying the disk-based MySQL database for user sessions, site transients, or post relationships, WordPress stores the query result as an object inside RAM. When the same query runs again, Redis returns the result in less than 2ms.

Plan Verification and Turning On Redis in hPanel

Hostinger includes Redis support on its Business Web Hosting, Cloud Startup, Cloud Professional, and Cloud Enterprise plans. If you are on the entry-level Single or Premium shared hosting plans, the Redis daemon is not installed on the underlying node, and the hPanel toggle will be absent.

Log into your Hostinger dashboard and follow these steps to turn on the service:

1. Navigate to Websites in hPanel and click Manage next to your target WordPress site.
2. In the left sidebar, click WordPress and select Overview.
3. Scroll down to the Core section. Locate the toggle labeled Object Cache (Redis).
4. Switch the toggle to Enabled.

When you flip this toggle, Hostinger spins up an isolated Redis socket or internal port assigned to your hosting account container and automatically enables the native PHP Redis extension in your active PHP runtime.

You can verify that the PHP module is active by opening an SSH terminal to your server and checking loaded PHP modules.

Run this command over SSH to confirm the extension is loaded:

php -m | grep -i redis

If the terminal prints redis, your PHP environment can communicate with the local Redis instance.

Configure wp-config.php with Salt Keys and Timeouts

While some WordPress plugins attempt to connect automatically using default settings, hardcoding your parameters in wp-config.php prevents broken database connections if another plugin alters runtime configurations.

Connecting multiple WordPress sites on the same shared host or running staging copies presents a major danger: key collisions. If two sites use Redis on 127.0.0.1:6379 without unique prefixes, Site B will read cached options and user transients belonging to Site A. We prevent this by defining a unique WP_CACHE_KEY_SALT.

Open your wp-config.php file using Nano, Vim, or the hPanel File Manager, and place the following block above the line that reads /* That's all, stop editing! Happy publishing. */.

Add these configuration constants:

// Redis Object Cache Configuration
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_TIMEOUT', 1);
define('WP_REDIS_READ_TIMEOUT', 1);
define('WP_CACHE_KEY_SALT', 'mysite_prod_');
define('WP_REDIS_MAXTTL', 86400);

The WP_REDIS_TIMEOUT and WP_REDIS_READ_TIMEOUT flags ensure that if the Redis daemon hangs or runs out of RAM, PHP terminates the socket call after 1 second instead of locking up your PHP workers and throwing 504 Gateway Timeouts.

Deploy the Object Cache Drop-in File

WordPress does not communicate with Redis out of the box. Core relies on an external drop-in file located at wp-content/object-cache.php to override the default non-persistent WP_Object_Cache class.

You can manage this drop-in manually or use an open-source connector. The most reliable production connector in the WordPress ecosystem is the Redis Object Cache plugin maintained by Till Krüss. If you regularly handle administrative tasks over the command line, you can install and configure it in seconds using WP-CLI.

Execute this command in your WordPress document root:

wp plugin install redis-cache --activate
wp redis enable

The wp redis enable command copies the plugin’s drop-in file directly to wp-content/object-cache.php. If permissions prevent WP-CLI from writing to wp-content/, you will see a write failure.

If you prefer installing plugins via the web UI:

1. Log in to your WordPress dashboard.
2. Go to Plugins > Add New and search for Redis Object Cache.
3. Click Install Now and activate the plugin.
4. Navigate to Settings > Redis.
5. Click the button labeled Enable Object Cache.

The status screen should now display a green checkmark next to Connected, listing the client as PhpRedis.

What I Ran: Real Benchmarks and Verification

I tested this implementation on a production client site hosted on a Hostinger Cloud Startup plan running PHP 8.2 and WooCommerce 8.5. The site features roughly 4,200 products and numerous custom fields.

Before enabling Redis, loading an uncached account dashboard generated 78 SQL queries totaling 142ms of MySQL execution time. Total Time to First Byte (TTFB) hovered at 847ms.

After enabling Redis and mounting the drop-in, I ran an audit via WP-CLI to inspect the memory layer.

Run this diagnostics command:

wp redis status

The terminal confirmed the active connection and dropped queries significantly:

Status: Connected
Client: PhpRedis (v5.3.7)
Drop-in: Valid
Host: 127.0.0.1:6379
Database: 0
Key Prefix: mysite_prod_
Redis Memory: 14.82M

On subsequent page reloads, the SQL query count plummeted from 78 down to 6 queries. MySQL execution dropped to 8ms, and dynamic TTFB settled at 218ms. Because background tasks also hammer the database, pairing your new cache with an external runner is a great step; check out our guide to disable WP-Cron and set up a real cron job in Hostinger.

Gotcha: Connection Refused and Socket Fallbacks

A frustrating issue occurs when your site displays a Connection refused [tcp://127.0.0.1:6379] error after enabling the drop-in. This typically happens on newer Hostinger container configurations where Redis listens exclusively across a local Unix domain socket rather than a TCP port.

To verify if Redis is listening on a TCP port or a socket, run a netstat check inside your SSH terminal.

Run this command over SSH:

netstat -ln | grep redis

If the command outputs a path ending in .sock (such as /var/run/redis/redis.sock or a user-specific path like /home/u123456789/.redis/redis.sock) without showing 127.0.0.1:6379, you must update your configuration to point to that path.

Replace your TCP definitions in wp-config.php with the socket path configuration:

// Switch from TCP port to Unix Socket
define('WP_REDIS_PATH', '/var/run/redis/redis.sock');
define('WP_REDIS_SCHEME', 'unix');
define('WP_CACHE_KEY_SALT', 'mysite_prod_');

Unix sockets bypass the network stack entirely, eliminating TCP handshake latency and lowering memory query overhead.

Tuning Cache Exclusions for WooCommerce and Dynamic Data

Not all data belongs in an in-memory object cache. Certain transients, user session tokens, and checkout fragments update rapidly. Caching them in Redis can lead to stale cart counters, checkout race conditions, or cache bloat.

According to the official Redis documentation on key expiration, handling volatile data requires setting disciplined memory boundaries. In WordPress, you tell the object cache to ignore specific groups using WP_REDIS_IGNORED_GROUPS.

Add this array of non-cacheable groups to wp-config.php directly below your salt settings:

// Exclude sensitive dynamic groups from Redis
define('WP_REDIS_IGNORED_GROUPS', [ 'comment', 'counts', 'plugins', 'wc_session_id', 'woocommerce_items_in_cart', 'edd_cart_tokens'
]);

This snippet keeps transient cart tokens and counter tallies running straight through MySQL, ensuring users see immediate updates without clearing your main Redis memory table. If your site ever encounters severe database corruption during massive catalog updates, you can use our guide on how to import large WordPress databases via SSH on Hostinger to restore operations cleanly.

Managing Redis with LiteSpeed Cache (Alternative Setup)

Hostinger servers run OpenLiteSpeed or LiteSpeed Enterprise. Because of this, many users run the all-in-one LiteSpeed Cache (LSCache) plugin rather than standalone drop-in plugins.

LiteSpeed Cache includes an integrated Object Cache manager that works with the Redis daemon. You should never run both the Redis Object Cache plugin and LiteSpeed Object Cache at the same time—running both causes conflicts over control of wp-content/object-cache.php.

If you prefer using LiteSpeed Cache to control Redis, follow these steps:

1. Deactivate and delete the standalone Redis Object Cache plugin if installed.
2. In your WordPress dashboard, navigate to LiteSpeed Cache > Cache.
3. Click the [6] Object tab at the top.
4. Toggle Object Cache to ON.
5. Set Method to Redis.
6. Set Host to 127.0.0.1 and Port to 6379.
7. Add your custom prefix to the Cache Key input field (e.g., siteprod_).
8. Save changes at the top right.

LiteSpeed will test the connection. If the status light at the top flips to green with Connection Test: Passed, LiteSpeed is handling your in-memory cache directly.

Frequently Asked Questions

Can I use Redis on Hostinger Single or Premium plans?

No. Hostinger restricts the Redis service to Business Web Hosting and Cloud Hosting tiers. If you are on an entry-level tier, the hPanel switch will not be present. Upgrading to Business or a Cloud plan adds the Redis service to your dashboard automatically.

How do I flush the Redis cache without restarting the web server?

You can flush Redis without disrupting server processes or affecting other sites on the server. If using WP-CLI, navigate to your public directory over SSH and run wp redis flush or wp cache flush. In the WordPress dashboard, go to Settings > Redis and click Flush Cache.

Will Redis break my staging environment?

Yes, if you forget to declare a unique WP_CACHE_KEY_SALT. When creating a staging copy on the same Hostinger account, open the staging site’s wp-config.php file immediately. Change the salt string to something distinct, like staging_site_. Otherwise, changes on staging will pull from your production site’s cache.

Does Redis replace the need for a CDN or page caching?

No. Redis speeds up backend database interactions and dynamic PHP processing. A CDN and page cache handle static delivery across the network edge. For maximum performance, keep your page caching and asset optimization active alongside Redis.

With Redis operating properly on your Hostinger account, monitor your logs over the next few days to confirm memory consumption stays well within plan limits. If you plan to move database records or replicate this architecture to a fresh environment, read our guide on how to safely update URLs after WordPress migration with WP-CLI.