Configure Redis Object Cache for WordPress on Hostinger VPS

My database queries were hammering MySQL on an unmanaged Hostinger VPS, pushing WordPress admin and cart TTFB past 820ms on routine page loads. Page caching doesn’t touch those routes. Here’s how to install Redis on Ubuntu, wire up the PHP extension, route traffic over a UNIX socket instead of TCP, and lock it into WordPress.

Standard caching plugins like WP Super Cache or Nginx FastCGI microcaching work fine for anonymous readers on static posts. But the second a customer logs in, adds an item to a WooCommerce cart, or loads /wp-admin/, full-page caching bails out. Every transient, session, and post meta entry forces WordPress back to MySQL. Shoving those hot lookups into RAM with Redis knocked my uncached response times down under 120ms.

Why MySQL Chokes on WordPress Object Queries

WordPress leans hard on the wp_options table and metadata queries. On an uncached hit, core alone often fires 40 to 180 SQL queries just to stitch the page together. Even with MySQL’s internal buffers warmed up, disk I/O and process locks add real lag.

WordPress ships with an internal object cache API, but it’s non-persistent by default. It holds data in memory for exactly one HTTP request, dumps it when PHP finishes executing, and leaves the next visitor’s request to run those identical queries all over again.

Redis fixes this by acting as an external, persistent in-memory store. Drop an object-cache.php file into WordPress, and queries resolved during request A stay in RAM. Request B pulls them from system memory in less than 2ms without ever touching MySQL.

Step 1: Install and Configure Redis Server on Ubuntu

SSH into your Hostinger VPS. If you haven’t touched the terminal on this box yet, see our guide on how to manually restore a WordPress backup via SSH on Hostinger for a quick refresher on server access.

Update apt repos and grab the Redis server package:

sudo apt update
sudo apt install redis-server -y

Make sure the service actually came up:

sudo systemctl status redis-server

It should show active (running). Out of the box, Redis listens on the TCP loopback address at 127.0.0.1:6379. That works, but TCP handshakes add unnecessary overhead on a single box. We can squeeze out better throughput with a UNIX socket.

Step 2: Switch Redis to a UNIX Socket for Better Performance

UNIX domain sockets bypass the network stack entirely, passing data directly through the Linux kernel. Switching from loopback TCP to a socket shaved roughly 18% off my local cache latency.

Open the Redis config file:

sudo nano /etc/redis/redis.conf

Find the unixsocket directives. They’re commented out by default. Uncomment both lines and set the permissions to 770 so your web server can talk to the socket:

unixsocket /var/run/redis/redis-server.sock
unixsocketperm 770

Next, find the memory management section. If you’re on a 4GB RAM VPS juggling MySQL, PHP-FPM, and Nginx, Redis will gladly eat available memory if you don’t cap it. Set a ceiling and an eviction policy:

maxmemory 512mb
maxmemory-policy allkeys-lru

Setting allkeys-lru ensures Redis evicts the least-recently-used keys when it hits the 512MB limit, protecting you from the Linux OOM killer. Save and exit.

Add your web server user (usually www-data on Ubuntu) to the redis group:

sudo usermod -a -G redis www-data

Restart Redis to apply the new socket settings:

sudo systemctl restart redis-server

Step 3: Install the PHP Redis Extension

WordPress needs a PHP driver to talk to Redis. Skip userland PHP libraries here; the compiled C extension from PECL phpredis handles concurrency much better.

Check which PHP version your site runs:

php -v

Install the matching extension package via apt (replace with your version if needed):

sudo apt install php-redis -y

Verify that the extension loaded:

php -m | grep redis

If that returns redis, you’re set. Reload PHP-FPM so your web workers pick it up:

sudo systemctl restart php8.2-fpm

If you run into body size or timeout limits while updating or uploading plugins, see our guide to fix 413 Request Entity Too Large in WordPress on Nginx to keep your PHP-FPM and Nginx settings in sync.

Step 4: Configure wp-config.php for Redis Socket Access

Before touching the WordPress admin panel, define the connection settings in wp-config.php. This stops plugins from defaulting back to TCP port 6379.

Open your site’s wp-config.php:

sudo nano /var/www/html/wp-config.php

Add these lines above the /* That's all, stop editing! Happy publishing. */ line:

// Redis Object Cache Settings
define( 'WP_CACHE', true );
define( 'WP_REDIS_SCHEME', 'unix' );
define( 'WP_REDIS_PATH', '/var/run/redis/redis-server.sock' );
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_REDIS_TIMEOUT', 1 );
define( 'WP_REDIS_READ_TIMEOUT', 1 ); // Cache Key Salt to prevent collisions with other sites
define( 'WP_CACHE_KEY_SALT', 'mysite_prod_' );

Don’t skip WP_CACHE_KEY_SALT. If you run multiple sites or a staging clone on the same VPS—like we cover in our tutorial on creating a WordPress staging site on Hostinger—they’ll use the same Redis daemon. Without distinct salts, Site A will pull cached queries from Site B, breaking sessions and mixing data.

Step 5: Install Redis Object Cache and Enable the Drop-in

Now hook WordPress into Redis using WP-CLI. It’s faster than clicking through wp-admin and gives immediate terminal output.

From your WordPress root, install Till Krüss’s Redis Object Cache plugin:

wp plugin install redis-cache --activate --allow-root

Enable the drop-in:

wp redis enable --allow-root

You should see Success: Object cache enabled.

This copies wp-content/plugins/redis-cache/includes/object-cache.php over to wp-content/object-cache.php. Under the hood, WordPress checks for that file during boot and instantiates the WP_Object_Cache class before running any database lookups.

Gotcha: Fixing the Redis Socket Permission Denied Error

When I first set this up, WordPress immediately threw Redis is unreachable: Permission denied. The web server couldn’t open the socket file even though I had already added www-data to the redis group.

Two things cause this on Ubuntu:

1. PHP-FPM was running when the group change was made, so the active worker processes never inherited the new group permissions.
2. The parent folder /var/run/redis/ had restrictive permissions that prevented www-data from traversing it.

Check the socket directory permissions:

ls -la /var/run/redis/

Make sure the group has read and execute permissions:

sudo chmod 775 /var/run/redis
sudo chown redis:redis /var/run/redis/redis-server.sock
sudo chmod 770 /var/run/redis/redis-server.sock

Then restart both services in order so the worker pool picks up the new group:

sudo systemctl restart redis-server
sudo systemctl restart php8.2-fpm

Head to Settings → Redis in your WordPress admin dashboard. The status badge should now read Connected.

Verify Cache Hits and Inspect Live Memory

Don’t just rely on the green badge in wp-admin. Watch the live cache traffic in your terminal to confirm keys are actually being stored and retrieved.

Run the monitor tool through your socket:

redis-cli -s /var/run/redis/redis-server.sock monitor

Open your site in an incognito window and click around. Your terminal will start scrolling with calls:

1711200921.142831 [0 unix:/var/run/redis/redis-server.sock] "GET" "mysite_prod_default:is_blog_installed"
1711200921.143012 [0 unix:/var/run/redis/redis-server.sock] "GET" "mysite_prod_options:alloptions"
1711200921.144201 [0 unix:/var/run/redis/redis-server.sock] "MGET" "mysite_prod_posts:1" "mysite_prod_post_meta:1"

Hit Ctrl + C to exit. To see your hit-to-miss ratio and RAM usage, pull the stats block:

redis-cli -s /var/run/redis/redis-server.sock info stats

Check keyspace_hits versus keyspace_misses. Once you browse a dozen pages, hits should outpace misses heavily—typically 8:1 or better, meaning over 85% of queries resolve straight out of RAM.

For more CLI parameters and configuration flags, check the official Redis Documentation.

Frequently Asked Questions

Will Redis Object Cache conflict with Nginx FastCGI or LiteSpeed page cache?

No, they operate at completely different layers. FastCGI and edge caching store static HTML outputs for anonymous visitors before PHP even boots. Redis speeds up PHP execution whenever an uncached or dynamic page actually runs. They work well together.

Does persistent object caching break WooCommerce cart sessions?

No. The Redis Object Cache plugin defaults to non-persistent groups for sensitive data like WooCommerce cart items, nonces, and checkout sessions. Those always hit the database directly so stock levels and cart contents remain accurate.

What happens when the Redis maxmemory limit is reached?

Because we set maxmemory-policy allkeys-lru in redis.conf, Redis evicts the oldest and least-used cache keys when it hits 512MB. The site won’t crash or throw 500 errors; it just replaces stale cache entries with new ones.

Can I run multiple WordPress sites on one Redis instance?

Yes. Set a unique WP_CACHE_KEY_SALT in each site’s wp-config.php. You can also assign each site a separate Redis database index using define('WP_REDIS_DATABASE', 1); so clearing the cache on one site doesn’t purge the others.

Next Steps

With Redis handling object caching, your database overhead should drop drastically. If you’re looking to isolate services further or move your stack into containers, check out our guide on how to deploy a Docker Compose app on a Hostinger VPS.