WordPress Redis Object Cache Setup Tutorial (2026): Install Redis, Enable PHP Cache, and Verify Real Hits on a VPS

Most “speed fixes” miss the real bottleneck. WordPress often re-runs the same database queries for options, menus, and transient data on every request. This WordPress Redis object cache setup tutorial shows how to install Redis on an Ubuntu VPS, connect it to PHP-FPM, tighten security, and then prove it works by watching real cache hits climb.

The outcome is simple: fewer queries per page load, lower PHP CPU, and steadier response times during traffic spikes. You’ll set it up so Redis stays off the public internet, doesn’t break WooCommerce sessions, and can be rolled back quickly.

What you’ll build (and what you need first)

You’ll end with WordPress using Redis as an object cache (not a full-page cache). Object caching stores reusable query results and computed objects that WordPress and plugins request repeatedly.

• Server: Ubuntu 24.04 LTS (works similarly on 22.04)
• Web stack: Nginx or Apache + PHP-FPM (PHP 8.2 or PHP 8.3)
• Access: SSH as a sudo user
• WordPress: any current 2026 release

If you run WordPress on a VPS and you want predictable performance, size the box for PHP-FPM and Redis. Give both enough CPU and RAM so neither starves under load.

A properly sized HostMyCode VPS gives you dedicated resources. That keeps Redis from competing with noisy neighbors on the same node.

Step 1: Install Redis Server on Ubuntu

Ubuntu’s Redis package is a strong fit for WordPress object caching. Install it, then confirm the service is running.

sudo apt update
sudo apt install -y redis-server

sudo systemctl enable --now redis-server
sudo systemctl status redis-server --no-pager

Quick sanity check:

redis-cli ping

You should see:

PONG

Step 2: Bind Redis to localhost and set safe defaults

For WordPress object caching, Redis should only listen locally. Don’t bind it to a public interface.

Edit:

sudo nano /etc/redis/redis.conf

Confirm these settings (or update them to match):

bind 127.0.0.1 ::1
protected-mode yes
port 6379

Restart Redis:

sudo systemctl restart redis-server

Pitfall: Don’t open port 6379 in your firewall “just to test.” If you ever need remote access, use SSH port forwarding instead.

Step 3: Add a Redis password (recommended on multi-user servers)

If more than one system user can execute code on the box, add Redis authentication. This is common in reseller, agency, or multi-site setups.

A password won’t stop a full server compromise. It does reduce easy abuse from other local users.

In /etc/redis/redis.conf, set:

requirepass YOUR_LONG_RANDOM_PASSWORD

Generate a strong one:

openssl rand -base64 48

Restart Redis:

sudo systemctl restart redis-server

Test authentication:

redis-cli
AUTH YOUR_LONG_RANDOM_PASSWORD
PING

Step 4: Install the PHP Redis extension (php-redis)

WordPress talks to Redis through PHP. On Ubuntu, the common choice is the php-redis extension.

For PHP 8.3:

sudo apt install -y php8.3-redis

If you’re on PHP 8.2:

sudo apt install -y php8.2-redis

Restart PHP-FPM so it actually loads the extension:

sudo systemctl restart php8.3-fpm

Confirm it’s loaded:

php -m | grep -i redis

If you’re still dialing in Nginx and PHP performance, do that alongside Redis. Don’t use caching as a band-aid for a slow baseline.

This setup pairs well with our Nginx performance optimization tutorial.

Step 5: Install and enable a WordPress Redis object cache plugin

You have two common routes:

• Redis Object Cache (simple and popular)
• Object Cache Pro (paid, advanced metrics and features)

This guide uses the free Redis Object Cache plugin. It’s easy to validate and capable enough for most sites.

1. In WordPress Admin → Plugins → Add New
2. Search for Redis Object Cache
3. Install and activate

Then go to: Tools → Redis and click Enable Object Cache. That step usually creates wp-content/object-cache.php.

Step 6: Configure WordPress to connect to Redis (clean and explicit)

Many sites connect with plugin defaults. Even so, explicit constants in wp-config.php make behavior predictable after restores, migrations, or environment changes.

Edit wp-config.php (usually in your WordPress root):

sudo nano /var/www/your-site/public/wp-config.php

Add (above the “That’s all” line):

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);

define('WP_REDIS_DATABASE', 0);

define('WP_REDIS_PASSWORD', 'YOUR_LONG_RANDOM_PASSWORD');

define('WP_CACHE_KEY_SALT', 'your-site.example:');

Notes:

• WP_CACHE_KEY_SALT prevents key collisions if you run multiple sites against one Redis instance.
• If you don’t set a Redis password, omit WP_REDIS_PASSWORD.

Step 7: Verify cache hits (don’t trust a green “Connected” badge)

“Connected” only means WordPress can reach Redis. You also want proof that repeat requests turn into cache hits.

Start by checking Redis stats:

redis-cli -a YOUR_LONG_RANDOM_PASSWORD info stats | egrep 'keyspace_hits|keyspace_misses'

Now open your site in a private window and refresh a few times. Run the command again.

After the first couple of page loads, keyspace_hits should climb faster than keyspace_misses.

You can also sanity-check memory usage and key count:

redis-cli -a YOUR_LONG_RANDOM_PASSWORD info memory | egrep 'used_memory_human|maxmemory_human'
redis-cli -a YOUR_LONG_RANDOM_PASSWORD dbsize

Step 8: Set sane Redis memory limits and eviction policy for WordPress

On a small VPS, “unlimited” Redis becomes a slow-motion outage. Set hard limits so Redis can’t eat RAM and push the kernel into swap.

Edit /etc/redis/redis.conf:

sudo nano /etc/redis/redis.conf

Add or adjust these values (example for a 2–4 GB RAM VPS; tune to your server):

maxmemory 256mb
maxmemory-policy allkeys-lru

Why allkeys-lru: WordPress cache entries are disposable. LRU eviction keeps frequently used keys and drops older, colder ones as memory fills.

Restart Redis:

sudo systemctl restart redis-server

Quick sizing guidance:

• Small brochure site: 128–256 MB
• WooCommerce with several plugins: 256–512 MB
• Busy content site with logged-in users: 512 MB–1 GB (watch RAM carefully)

Step 9: Make it survive deployments and keep permissions correct

The plugin writes wp-content/object-cache.php as a “drop-in.” If you deploy via Git, CI, rsync, or a build pipeline, that file can disappear or get overwritten.

Checklist:

• Ensure object-cache.php stays present after deploys
• Keep ownership consistent with your web user (often www-data)

Example:

sudo chown www-data:www-data /var/www/your-site/public/wp-content/object-cache.php
sudo chmod 644 /var/www/your-site/public/wp-content/object-cache.php

Step 10: Add monitoring so Redis failures don’t silently slow your site

If Redis goes down, WordPress usually falls back to the database. The site may not crash. It will just get slower.

That delay often shows up as complaints, higher bounce, or a conversion dip.

Two practical options:

• Service monitoring: alert if redis-server stops
• Resource monitoring: alert on RAM pressure and swap usage

If you already monitor uptime and resources, add Redis to that baseline.

Our VPS monitoring tutorial covers CPU, memory, disk, and service checks that fit this setup.

Step 11: Hardening checklist (fast, practical)

• Keep Redis local: bind 127.0.0.1 ::1
• Set a password: requirepass (recommended for multi-user servers)
• Firewall remains closed: no public inbound 6379
• Limit memory: maxmemory + allkeys-lru
• Patch cadence: apply security updates weekly

If you’re building a hardened baseline for the whole server (SSH, firewall rules, brute-force protection), do that first. Start with this VPS hardening tutorial, then layer in performance features like Redis.

Troubleshooting: common Redis object cache problems on WordPress

“Status: Not connected” in WordPress

• Confirm Redis is running: sudo systemctl status redis-server
• Verify host/port in wp-config.php
• Check you installed php-redis and restarted PHP-FPM

Connected, but no hits (misses keep rising)

• Warm-up effect is normal: the first request set will miss
• Confirm the object cache drop-in exists: wp-content/object-cache.php
• Disable conflicting caching plugins temporarily and retest
• Check for aggressive cache flushing from a plugin or cron

High RAM usage or Redis evictions

• Check memory: redis-cli -a PASS info memory
• Look for evictions: redis-cli -a PASS info stats | grep evicted_keys
• Increase maxmemory slightly or reduce plugin bloat

Admin pages feel faster, but checkout/session issues appear

This is rare with object caching alone. It can show up with misconfigured persistent caching and certain plugin combinations.

Steps:

• Update the Redis plugin and your caching plugins
• Confirm you’re not caching logged-in pages at the reverse proxy or page cache layer
• Temporarily disable object cache to isolate the problem

Operational notes for resellers and multi-site VPS setups

If you run multiple WordPress sites on one VPS, a single Redis instance can work well. The key is keeping each site’s keys separate.

Use unique salts, and optionally assign different Redis databases.

• Use WP_CACHE_KEY_SALT per site (must be unique)
• Optionally set WP_REDIS_DATABASE per site (0, 1, 2, ...)

For shared environments and client isolation, tighten file access too. The SFTP setup guide tutorial walks through a chroot approach. It helps prevent accidental cross-site edits when clients upload themes or plugins.

Summary: what to check after you’re done

• Redis responds locally: redis-cli -a PASS ping
• WordPress object cache enabled: wp-content/object-cache.php exists
• Hits rising on refresh: keyspace_hits grows steadily
• Memory bounded: maxmemory set and policy is allkeys-lru
• Redis is not publicly exposed: no inbound 6379

If your WordPress site is outgrowing shared hosting, Redis object caching is often where a VPS starts to make financial sense.

For hands-off updates and maintenance, consider managed VPS hosting. If you’d rather tune everything yourself, a standard HostMyCode VPS gives you headroom for Redis, PHP-FPM, and monitoring.

FAQ

Do I still need a page cache if I use Redis object caching?

Usually, yes. Redis reduces WordPress’s internal overhead. A page cache (or Nginx microcaching) avoids PHP work entirely for anonymous traffic. Used together, they cover different bottlenecks.

Can Redis object caching break plugins?

It’s uncommon, but it can happen if a plugin stores non-serializable objects or triggers constant cache flushes. If you see odd behavior, disable the object cache drop-in and test again.

Should Redis run on the same VPS as WordPress?

For most single-site and small multi-site setups, yes. Keeping Redis on-box avoids network latency. Move it off-server only after you’ve outgrown the VPS and have a clear reason to centralize Redis.

How do I safely disable Redis if I need to roll back?

In WordPress → Tools → Redis, disable object cache, then remove wp-content/object-cache.php. After that, you can stop Redis: sudo systemctl stop redis-server.

What’s the simplest way to confirm Redis isn’t exposed publicly?

From the server, check the listening address: sudo ss -lntp | grep 6379. You should only see 127.0.0.1:6379 (and possibly [::1]:6379).