Redis Object Cache for WordPress on a VPS: Setup Guide

Your WordPress site has a page cache plugin, the PageSpeed score looks decent, and yet the admin dashboard crawls, WooCommerce checkout drags, and logged-in users still see a sluggish site. That's the tell: page caching only speeds up what anonymous visitors see. Everything that runs PHP and hits the database - cart pages, membership content, search, wp-admin itself - gets none of that benefit. This is exactly where a Redis object cache earns its keep, and it's one of the least understood performance layers on VPS hosting.

Symptom: Fast Homepage, Slow Everything Else

If you're seeing any of these, you likely have an object-cache gap rather than a page-cache problem:

• wp-admin feels slower than the public site
• Logged-in users (members, WooCommerce customers) report lag that logged-out visitors don't
• MySQL's process list shows the same queries repeating dozens of times per page load
• Your hosting dashboard shows CPU spikes that don't line up with traffic spikes

Page caching serves a static HTML snapshot for anonymous visits, so it never touches this problem. Anything dynamic - cart totals, personalized content, admin screens - bypasses the page cache entirely and falls straight through to PHP and MySQL on every single request.

Cause: WordPress Re-Fetches the Same Data Constantly

WordPress core, and nearly every plugin, calls wp_cache_get() and wp_cache_set() internally - the option table, taxonomy terms, post meta, user meta, all of it goes through this layer. Without a persistent object cache backend, WordPress falls back to its default "in-memory" object cache, which only lasts for the length of a single PHP request. The moment that request ends, the cache is thrown away. The next page load starts from zero and re-queries MySQL for the exact same data it just fetched a second ago.

On a VPS this shows up as MySQL doing far more work than the traffic justifies. A site with a few hundred concurrent users can generate tens of thousands of near-identical SELECT queries an hour, because nothing survives between requests. Redis fixes this by giving WordPress a cache that persists across requests, shared by every PHP-FPM worker.

Fix: Install and Wire Up Redis

1. Install Redis on the VPS

On Ubuntu/Debian:

sudo apt update
sudo apt install redis-server -y
sudo systemctl enable --now redis-server

On AlmaLinux/RHEL:

sudo dnf install redis -y
sudo systemctl enable --now redis

Confirm it's alive:

redis-cli ping
# should return: PONG

2. Lock Redis Down Before You Do Anything Else

By default Redis listens on all interfaces with no password - fine for a quick test, dangerous left in place. Edit /etc/redis/redis.conf (or /etc/redis.conf on RHEL-based systems):

bind 127.0.0.1 -::1
protected-mode yes
requirepass a-long-random-string-here
maxmemory 256mb
maxmemory-policy allkeys-lru

bind 127.0.0.1 keeps Redis reachable only from the same machine - your WordPress site and Redis should be on the same VPS or connected over a private network, never over the public internet. maxmemory-policy allkeys-lru tells Redis to quietly evict the least-used keys once it hits the memory cap, instead of crashing or refusing writes. Restart to apply:

sudo systemctl restart redis-server

3. Install a Persistent Object Cache Plugin

WordPress needs a drop-in to actually talk to Redis. Redis Object Cache (by Till Krüss) is the standard choice - install it from Plugins > Add New, or via WP-CLI:

wp plugin install redis-cache --activate

Add the connection details to wp-config.php, above the "That's all, stop editing" line:

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_PASSWORD', 'a-long-random-string-here');
define('WP_REDIS_DATABASE', 0);
define('WP_CACHE_KEY_SALT', 'yourdomain.com:');

The WP_CACHE_KEY_SALT matters more than it looks - if you run multiple WordPress sites on the same VPS sharing one Redis instance, this prefix stops their cache keys from colliding with each other.

4. Enable the Drop-In and Verify It's Actually Working

In wp-admin, go to Settings > Redis and click "Enable Object Cache." This copies object-cache.php into wp-content/, which is what activates the persistent cache. Confirm it's live:

wp redis status
# Status: Connected
# Client: PhpRedis (or Predis)

Or check straight from Redis:

redis-cli -a your-password --no-auth-warning INFO keyspace
# db0:keys=1842,expires=...

If keys stays at zero after loading a few pages, WordPress isn't reaching Redis - double-check the host, port, and password in wp-config.php, and make sure php-redis or php-igbinary extensions are actually installed (php -m | grep redis).

5. Set a Sensible Memory Ceiling

A shared VPS with 2-4GB RAM shouldn't hand Redis unlimited memory - that's how a runaway cache starves MySQL and PHP-FPM of RAM until the OOM killer starts picking victims. 256-512MB is plenty for most WordPress sites; increase it only if INFO memory shows you're consistently hitting the ceiling with legitimate cache traffic, not a leak.

Common Problems After Setup

Prevention: Keep It Healthy Long Term

• Monitor Redis memory with redis-cli INFO memory weekly, or wire it into your existing server monitoring
• Never expose Redis's port (6379) publicly - firewall it explicitly even though bind already restricts it, since a config edit later can silently undo that protection
• Restart Redis after any WordPress core or PHP version upgrade, since a stale connection occasionally lingers
• If you run several WordPress installs on one VPS, give each a separate Redis database number (0-15) or a unique key salt, not both defaults
• Keep object caching as one layer, not the whole strategy - it complements a page cache and OPcache, it doesn't replace either

On a Getwebup VPS, Redis is already available as an installable service from the control panel, so most of this comes down to the wp-config constants and the plugin toggle rather than compiling anything from scratch. If you'd rather have this set up and verified for you, our support team can wire it up and confirm the connection during onboarding.