Install Redis Object Cache for WordPress on Ubuntu

Database queries are often why logged-in WordPress pages feel “fine” in staging but sluggish in production. A page cache helps anonymous traffic. But WooCommerce carts, My Account, wp-admin, and membership pages can still hit MySQL on every request.

This tutorial shows how to install Redis for WordPress on an Ubuntu VPS. You’ll connect Redis to PHP-FPM, enable persistent object caching, and verify real cache hits (not just a “Connected” label).

We’ll use Ubuntu 24.04 LTS (the steps are very similar on 22.04). This setup assumes Nginx or Apache with PHP-FPM, and WordPress running on a VPS or dedicated server.

On shared hosting without root access, you usually need a plan that already includes Redis. Otherwise, you’ll need to move to a VPS.

What you’ll build (and what changes on your site)

• Redis server running on your VPS (via a fast UNIX socket or localhost TCP).
• PHP Redis extension enabled for your PHP version so WordPress can talk to Redis.
• Redis Object Cache plugin installed, enabled, and connected.
• Validation: CLI + WordPress checks that confirm hits, memory use, and key counts.

Expected result: snappier wp-admin navigation, fewer repeated queries during logged-in sessions, and smoother WooCommerce account/cart flows.

On busy stores, repeat loads often cut database work a lot. CPU spikes also tend to flatten during traffic bursts.

Prerequisites checklist (don’t skip these)

• Ubuntu server with sudo access.
• WordPress installed and working.
• PHP-FPM in use (typical for Nginx; also common with Apache via proxy_fcgi).
• Ability to edit wp-config.php.
• A backup/restore path (at minimum, a DB + wp-content backup) before you change caching.

If you need a VPS sized for WordPress with enough headroom for Redis and PHP-FPM, start with a HostMyCode VPS.

If you’d rather not maintain Redis and PHP packages yourself, managed VPS hosting keeps the ops work off your plate.

Optional background: if you’re already cleaning up WordPress permissions or fixing cron, these two HostMyCode guides pair well with object caching changes:

WordPress file permissions fix on a VPS and fix WordPress cron not running.

Step 1: Confirm your PHP version and service layout

Start by confirming which PHP version you’re actually running. You need the matching Redis extension package.

Don’t guess here. It wastes time.

php -v
php --ri date | head

If PHP CLI isn’t installed, add it so you can test modules reliably:

sudo apt update
sudo apt install -y php-cli

Now identify the PHP-FPM service name you’ll restart later:

systemctl list-units --type=service | grep -E 'php.*fpm'

You’ll usually see something like php8.3-fpm or php8.2-fpm. Make a note of it.

Step 2: Install and harden Redis on Ubuntu

Install Redis from Ubuntu’s repository:

sudo apt update
sudo apt install -y redis-server

Then confirm the service is up:

sudo systemctl status redis-server --no-pager
redis-cli ping

You’re looking for PONG.

Lock Redis to localhost (or use a UNIX socket)

For a single-server WordPress setup, don’t expose Redis to the public internet. Keep it local-only, or use a UNIX socket with the right permissions.

Edit the Redis config:

sudo nano /etc/redis/redis.conf

Confirm these settings:

• bind 127.0.0.1 ::1 (keeps it local)
• protected-mode yes
• Optional but recommended: enable a UNIX socket for lower overhead

To enable the socket, set:

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

Also confirm Redis uses a predictable data directory (Ubuntu usually does): dir /var/lib/redis.

Restart Redis and check status again:

sudo systemctl restart redis-server
sudo systemctl is-active redis-server
redis-cli ping

If you enabled the socket, confirm it was created:

ls -la /run/redis/

Memory policy: avoid surprise OOM events

Redis stores cached objects in RAM. On a smaller VPS, an unlimited Redis instance can crowd out MySQL and PHP-FPM.

Set a maxmemory limit and an eviction policy that matches cache behavior.

Edit /etc/redis/redis.conf again. Choose a starting point that fits your server:

• 2 GB RAM VPS: maxmemory 256mb
• 4 GB RAM VPS: maxmemory 512mb
• 8 GB RAM VPS: maxmemory 1024mb

For WordPress object caching, this eviction policy is a solid default:

maxmemory 512mb
maxmemory-policy allkeys-lru

Restart Redis:

sudo systemctl restart redis-server

Then confirm Redis picked up the values you set:

redis-cli CONFIG GET maxmemory
redis-cli CONFIG GET maxmemory-policy

Step 3: Install the PHP Redis extension (the part people miss)

The plugin alone isn’t enough. PHP needs the Redis client module.

Without it, WordPress can’t talk to Redis.

Install the extension:

sudo apt install -y php-redis

Confirm it loads:

php -m | grep -i redis
php --ri redis | sed -n '1,80p'

You should see a Redis section with version details.

If php -m doesn’t show Redis, verify which PHP binary you’re running:

which php
php -v

Restart PHP-FPM (use your actual version):

sudo systemctl restart php8.3-fpm

If you run Apache with PHP-FPM, reload Apache too:

sudo systemctl reload apache2

A common slip is restarting only Nginx/Apache and forgetting PHP-FPM.

If Redis won’t connect later, come back here and confirm PHP-FPM restarted.

Step 4: Install the Redis Object Cache plugin and enable it

There are several Redis-related plugins. For persistent object caching, the widely used choice is “Redis Object Cache” by Till Krüss.

Install it from wp-admin or use WP-CLI.

Option A: wp-admin

1. Plugins → Add New
2. Search: Redis Object Cache
3. Install → Activate

Option B: WP-CLI (faster and scriptable)

From your WordPress directory (often /var/www/html or a vhost path):

cd /path/to/wordpress
wp plugin install redis-cache --activate

Enable object caching:

wp redis enable

If WP-CLI complains about permissions, fix ownership first. On many Ubuntu Nginx/PHP-FPM setups, WordPress files are owned by your deploy user and readable by the web server.

Avoid blanket 777.

If you want a sane baseline, follow: WordPress file permissions fix on a VPS.

Step 5: Set connection details in wp-config.php (socket recommended)

The plugin often defaults to localhost, which can work. Still, it’s better to set the connection explicitly.

That way, migrations and service changes don’t turn into guesswork.

Edit wp-config.php:

sudo nano /path/to/wordpress/wp-config.php

Add these lines above /* That's all, stop editing! */.

Preferred: UNIX socket

define('WP_REDIS_PATH', '/run/redis/redis-server.sock');
define('WP_REDIS_SCHEME', 'unix');
define('WP_REDIS_DATABASE', 0);

Alternative: TCP localhost

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

If you run multiple WordPress sites on the same server, separate them with different Redis databases or prefixes.

This simple pattern works well:

define('WP_REDIS_DATABASE', 1);
define('WP_REDIS_PREFIX', 'site1:');

Then set the next site to DB 2 with prefix site2:. That keeps keys from colliding.

Socket permissions (the usual gotcha)

If you use a socket and the plugin can’t connect, it’s usually permissions.

Check which user your PHP-FPM pools run as:

ps -eo user,cmd | grep 'php-fpm: pool' | head

On Ubuntu, it’s often www-data. Redis typically creates the socket owned by the Redis user/group.

Make sure www-data can access it.

Add www-data to the redis group:

sudo usermod -aG redis www-data

Restart services so group membership is applied:

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

Then confirm the socket group and permissions:

stat /run/redis/redis-server.sock
getent group redis

Step 6: Verify object caching is actually working (3 checks)

Don’t stop at a green “Connected” badge. Confirm keys are being created.

Also confirm hits are increasing.

Check 1: WordPress admin plugin status

Go to Settings → Redis (or Tools → Redis depending on plugin version). You should see:

• Status: Connected
• Client: phpredis
• Drop-in: object-cache.php present

Check 2: Redis key count increases

Run:

redis-cli DBSIZE
redis-cli INFO keyspace

Open a few wp-admin pages and refresh them. Run the commands again.

You should see db0:keys=... increase (or your chosen DB number).

Check 3: Confirm hits/misses and memory use

redis-cli INFO stats | egrep 'keyspace_hits|keyspace_misses'
redis-cli INFO memory | egrep 'used_memory_human|maxmemory_human|mem_fragmentation_ratio'

After a few refreshes, keyspace_hits should climb. Misses will happen, especially on first load.

What you want is repeat loads producing repeat hits.

If hits never increase, it’s usually one of these issues: connection problems, constant flushes, or a missing drop-in.

Re-check with:

cd /path/to/wordpress
wp redis status
wp redis enable

Step 7: Make Redis play nicely with WooCommerce and logged-in users

Persistent object caching helps WooCommerce, but it doesn’t replace page-cache rules. Redis Object Cache stores expensive computed objects (options, queries, transients).

It does not cache full HTML pages.

• Keep your page cache rules correct (don’t cache cart/checkout pages for logged-in sessions).
• Use persistent object caching even if you disable page cache for logged-in users.
• Watch transients: WooCommerce uses transients heavily. Redis speeds them up, but memory use can grow.

If you want a quick read on database load, compare queries per request before/after with Query Monitor.

Once Redis warms up, repeated admin page loads should run fewer identical queries.

Step 8: Add a safe maintenance workflow (updates, cache flushes, and restores)

Redis is a cache, so flushing it won’t delete posts or orders. It can still ruin an afternoon if you flush at peak time.

A flush can force a thundering herd back onto the database.

Controlled flush

Use the plugin’s “Flush Cache” button during low traffic, or run it via WP-CLI:

cd /path/to/wordpress
wp redis flush

Avoid cache stampedes after flush

• Flush off-peak.
• Warm key pages manually (home, shop, a product page, cart, checkout, my account, wp-admin dashboard).
• Monitor MySQL CPU for 5–10 minutes after flushing.

Backups and restore testing (don’t mix cache into your backups)

You don’t need to back up Redis for WordPress object caching. Back up WordPress files and your database.

Then practice a restore.

For a solid restore-first approach, see: set up backups with a restore test (the workflow mindset still applies if you run MySQL/MariaDB).

Step 9: Basic security guardrails (so Redis doesn’t become a liability)

Redis should not be reachable from the public internet. If you bind to localhost or use a UNIX socket, you’ve already handled the biggest risk.

• Confirm Redis is local-only:

sudo ss -ltnp | grep 6379 || true

If Redis is listening on 0.0.0.0:6379, fix bind in /etc/redis/redis.conf and restart.

Then check again.

Keep the OS patched as well. If you haven’t enabled unattended security updates yet, use: set up automated security updates on Ubuntu.

Step 10: Troubleshooting (fast fixes for common breakages)

“Status: Not connected” in the plugin

• Check Redis service: sudo systemctl status redis-server
• Check PHP module: php -m | grep -i redis
• Restart PHP-FPM: sudo systemctl restart php8.3-fpm
• If using socket: check perms: stat /run/redis/redis-server.sock

High memory usage or swapping after enabling Redis

• Set maxmemory and allkeys-lru eviction in /etc/redis/redis.conf.
• Reduce the maxmemory value on smaller VPS plans.
• Check memory fragmentation: redis-cli INFO memory | grep mem_fragmentation_ratio

Cache hits never rise

• Confirm you’re testing repeat requests (hits show up on the second/third load).
• Verify the WordPress drop-in exists: wp-content/object-cache.php.
• Check that another object cache plugin isn’t conflicting.

After a migration, Redis works but the site behaves oddly

Flush the cache once after a migration or major URL change:

cd /path/to/wordpress
wp redis flush

If you’re planning a bigger move (new VPS, new disk, new region), a migration service can reduce downtime surprises: HostMyCode migrations.

Summary: what to keep an eye on after you enable Redis

• Redis stats: hits should rise; memory should remain under your max.
• MySQL load: average CPU and query latency should stabilize during logged-in traffic.
• Plugin conflicts: only one persistent object cache drop-in should be active.
• Security: Redis stays local-only (localhost or socket).

If your site is outgrowing shared hosting, learning to install Redis for WordPress is one of the most noticeable server upgrades you can make.

It improves day-to-day admin and logged-in performance.

A right-sized HostMyCode VPS gives you the RAM headroom to run Redis alongside PHP-FPM and a database.

That keeps services from fighting for memory.

FAQ

Will Redis break my WooCommerce cart or checkout?

Object caching won’t cache full HTML pages, so it won’t “freeze” carts the way page caching can. You still must exclude cart/checkout from any page cache or CDN rules.

Should I run Redis on the same VPS as WordPress?

For most sites, yes. Local Redis (socket or localhost) is fast and simple. Split Redis to another server only when you have clear capacity reasons and a private network plan.

How do I confirm Redis is helping, not just enabled?

Watch redis-cli INFO stats for rising keyspace_hits, and compare repeated page loads in wp-admin with Query Monitor. Lower repeat-query counts and steadier CPU are good signs.

What’s a sensible Redis maxmemory on a small WordPress VPS?

On a 2 GB RAM VPS, start at 256 MB. On a 4 GB VPS, 512 MB is usually safe. Adjust after you check MySQL + PHP-FPM memory consumption and confirm the server isn’t swapping.

Do I need to back up Redis data?

Not for object caching. Redis is a cache layer here. Back up your database and wp-content, and focus on tested restores.