WordPress Redis Object Cache 24.04 & 26.04: 8 Secure Steps

A WordPress Redis object cache keeps the answers to WordPress's most repeated database questions in fast memory, so a shop, a members area or a busy admin dashboard stops asking MariaDB the same thing dozens of times per page. This guide sets one up on Ubuntu 24.04 LTS or 26.04 LTS in eight steps, with a Unix socket instead of an open port, a memory limit, a locked-down Redis ACL user for each site, and the plugin installed with WP-CLI. On 26.04 the server can be Redis or Valkey. Pick your release with the switch below. Allow about an hour, and be comfortable in a terminal.

We ran every command twice in disposable labs, never on a live server: on Ubuntu 24.04 (Redis 7.0, PHP 8.3, MariaDB 10.11) with a small blog and a WooCommerce shop of 150 products, and on Ubuntu 26.04 (Redis 8.0 and Valkey 9.0, PHP 8.5, MariaDB 11.8) with a small blog. Both used WordPress 7.1.3 and Redis Object Cache plugin 3.0.0. Where the two releases differ, the page shows only the one you picked.

We also broke things on purpose. The main finding: with default settings, a Redis problem becomes an error page on your website, so the safety steps matter more than the speed-up. We also show when an object cache is not worth installing.

Before you start: what you need and how to back out

You need an Ubuntu 24.04 LTS or 26.04 LTS server that already runs WordPress on nginx, PHP-FPM and MariaDB. Our guide to the WordPress, nginx, PHP-FPM and MariaDB stack builds exactly that. Examples use example.com, a site account called siteuser, and alex as the administrator. Swap in your own names.

• Back up first. Nothing here changes your database, but you will edit wp-config.php and restart services. The 3-2-1 backup rule explains how many copies to keep.
• Rehearse on a copy if the site takes orders, and pick a quiet hour. Step 7 stops Redis on purpose, and restarts cut requests in flight.
• Know your way out. wp redis disable removes the object cache cleanly, and one line in wp-config.php switches it off without deleting anything (Step 7).
• Keep a firewall on. A default-deny firewall such as UFW is your second lock. Step 3 tests it.

WordPress Redis object cache: what it is and when it is worth it

Building one WordPress page takes dozens of small database questions. What is the site called? Which plugins are active? Who is this visitor? Most of them repeat on every page. By default WordPress remembers the answers only until the page is finished, then forgets them. An object cache is a notepad that stays open between page loads, so WordPress can read an answer instead of asking MariaDB again. Redis is the fast memory that holds the notepad.

A page cache also remembers things, but it does a different job. It keeps the finished page and hands it to anonymous visitors without running PHP. An object cache keeps the small answers PHP still needs while it builds a page, so it also helps the pages a page cache must never store.

Our guide to nginx FastCGI caching covers the page cache, and why is my WordPress site so slow helps you find which problem you have. The two work at different levels, so a busy shop can use both.

What we measured

On the Ubuntu 24.04 lab server we switched the object cache off and on in turn, three rounds of 21 requests per page, with the database on the same machine. The table shows medians. It is a shared test machine, so treat differences under about 10 percent as noise.

Queries fell by 80 to 90 percent everywhere, which is the object cache doing its job. Time to first byte barely moved. A database on the same machine answers a simple query in a fraction of a millisecond, so removing 60 of them saves little. With eight visitors at once, the cart served between 25 and 37 pages per second across our runs, and the cache made at most a difference of about 20 percent, because PHP, not the database, was the limit.

The picture changes when each query is slow. In the same 24.04 lab we added one millisecond of delay to every packet between PHP and MariaDB, to imitate a database on another machine. The shop pages then took about 280 ms without the cache and about 125 ms with it. That is where an object cache earns its keep: remote or busy databases, large tables, and many plugins asking many questions.

When it is worth it, and when it is not

WordPress ships its own rule of thumb. We read the code of WordPress 7.1.3 and WooCommerce 11.2.0. Site Health recommends a persistent object cache on multisite, or at more than 500 autoloaded options, more than 100,000 bytes of them, or 1,000 or more rows in the comments, options, posts, terms or users tables. WooCommerce adds a trigger at 100 or more products or orders. Our shop crossed that line and our blog did not.

• Worth it: shops, member sites and forums, where a page cache has to skip the logged-in pages.
• Worth it: a database on another machine, or one that is busy, large or slow, and admin areas with several editors.
• Probably not: a brochure site served from a page cache. Anonymous visitors never reach PHP, so little is left to cache.
• Not yet: a site nobody monitors. Step 7 shows that the plugin treats Redis as essential.

Why this way and not the other ways

A Redis object cache is not the only way to remember things, and for some sites it is not the right one. The rest of this guide builds the Redis row, because that is the one that needs care.

Three ideas behind every step

1. Cache, not database. Redis holds copies. If it loses everything, WordPress rebuilds the answers from MariaDB, so we spend no effort on durability.
2. A hard dependency. Once the plugin is on, WordPress expects Redis to answer. In our lab a stopped Redis, a full Redis and a Redis that could not save a snapshot each produced an error page, not a slower site.
3. A door and a key. Redis trusts every connection it accepts. So security means controlling who can connect (the Unix socket's file permissions are the door) and what a connection may do (the Redis ACL is the key).

Step 1: Measure first, so you know what you are fixing

Count how much work one page costs today. MariaDB keeps a running total in its Queries counter, so the difference across a few requests gives queries per page. Do it on a quiet server or a staging copy, because every visitor adds to the count. Use a page that matters to you in place of /shop/.

q() { sudo mariadb -N -e "SHOW GLOBAL STATUS LIKE 'Queries'" | cut -f2; }
curl -s -o /dev/null https://example.com/shop/
before=$(q)
for i in $(seq 20); do curl -s -o /dev/null https://example.com/shop/; done
after=$(q)
awk -v a="$after" -v b="$before" 'BEGIN { printf "about %.0f database queries per page\n", (a - b - 2) / 20 }'
curl -s -o /dev/null -w 'first byte after %{time_starttransfer} seconds\n' https://example.com/shop/

The first curl is a warm-up that is not counted, and the - 2 removes the cost of reading the counter twice, which we measured on an idle server. Our settled 24.04 lab shop printed about 70 queries per page, and our 26.04 lab blog about 32. Right after we installed WooCommerce it printed 109, because a new shop runs one-off background jobs for a while, so measure a site that has been in use. Write your number down.

Carts and admin screens need a login, so for those use the free Query Monitor plugin, which lists the queries behind the page you are viewing.

Step 2: Install Redis and the PHP extension from Ubuntu's repository

You need two pieces. redis-server is the notepad service, and php8.38.5-redis (phpredis) is the extension that lets PHP talk to it. Both come from Ubuntu, so automatic security updates cover them. On Ubuntu 26.04 you can use valkey-server instead of redis-server; read the box below before you copy the commands.

sudo apt update
sudo apt install -y redis-server php8.38.5-redis
sudo systemctl restart php8.38.5-fpm
redis-server --version
systemctl is-enabled redis-server && systemctl is-active redis-server
sudo ss -tlnp | grep 6379
php --ri redis | grep -E '^Redis Version'

In our lab that printed Redis 7.0.158.0.5, enabled, active, listeners on 127.0.0.1:6379 and [::1]:6379, and phpredis 5.3.76.2.0. Ubuntu's Redis listens on the loopback addresses only and starts in protected mode, so the internet cannot reach it. It has no password, though, so every program and user account on the server can read, change and wipe the object cache. The next steps fix that with a Unix socket and a Redis ACL.

Step 3: Use a Unix socket and close the network port

A Unix socket is a file that programs on one machine use to talk to each other instead of a network port. Files have owners and permissions, so Linux itself decides who may knock. Append three lines to the Redis configuration, then let the site's PHP account into the redis group.

sudo tee -a /etc/redis/redis.conf >/dev/null <<'EOF'

# --- local settings: when a directive appears twice, the last one wins ---
port 0
unixsocket /run/redis/redis-server.sock
unixsocketperm 770
EOF
sudo usermod -aG redis siteuser
sudo systemctl restart redis-server php8.38.5-fpm

port 0 turns the network listener off, and unixsocketperm 770 lets the owner and the redis group use the Unix socket. If your pool runs as www-data rather than its own account, add that user instead. Group membership is read when a process starts, which is why PHP-FPM restarts too. Now test it.

sudo ss -tlnp | grep 6379 || echo "nothing listens on port 6379"
ls -l /run/redis/redis-server.sock
sudo -u siteuser redis-cli -s /run/redis/redis-server.sock ping
sudo -u nobody redis-cli -s /run/redis/redis-server.sock ping

You should see no listener, a socket owned by redis:redis with mode srwxrwx---, PONG for siteuser, and Permission denied for nobody. The last line is the point: an account outside the group cannot even connect.

Step 4: Cap the memory and decide what happens when it is full

Out of the box Redis has no memory limit. If you add one, the default policy, noeviction, answers every new write with an error. WordPress writes to the object cache on almost every request, so a full Redis means errors, and the plugin turns errors into error pages. We reproduced it: with the limit below the data size, both lab sites returned HTTP 500 (OOM command not allowed when used memory > 'maxmemory'). With allkeys-lru they stayed at 200 while Redis discarded old entries.

sudo tee -a /etc/redis/redis.conf >/dev/null <<'EOF'
maxmemory 256mb
maxmemory-policy allkeys-lru
save ""
EOF
sudo systemctl restart redis-server

maxmemory 256mb is a ceiling, not a reservation. Our 150-product shop used about 1 MB of cache after we visited every page and admin screen, so 256 MB is generous. A large catalog, many plugins or a multisite network needs more. Start at 128 to 256 MB and watch the eviction counter in Step 8.

allkeys-lru makes Redis discard the least recently used entries when it is full, and Redis's documentation calls it a good default. Why not volatile-lru? It only discards entries that have an expiry time, and in our lab 224 of 235 keys had none. save "" switches snapshots off. Redis may log a warning about vm.overcommit_memory; the message ties it to background saves and replication, which this setup does not use.

Step 5: Give each site its own locked-down Redis ACL user

Redis 6 and later hold named users, each with a password, a list of allowed commands and a pattern of key names it may touch. This is the Access Control List, or Redis ACL. Think of a hotel key card: it opens your room and the lift, not the master cupboard. We create a full-power user for you and a limited user for the site, and switch off the built-in user that needs no password.

First make two long random passwords. The ACL file holds only their SHA-256 hashes, so the file itself contains nothing usable. Keep SITE_PASS in this shell until Step 6, because it goes into wp-config.php.

ADMIN_PASS=$(openssl rand -hex 32)
SITE_PASS=$(openssl rand -hex 32)
echo "$ADMIN_PASS" | sudo tee /root/redis-admin.pass >/dev/null
sudo chmod 600 /root/redis-admin.pass
sha256hex() { printf %s "$1" | sha256sum | cut -d' ' -f1; }
sudo tee /etc/redis/users.acl >/dev/null <<ACL_FILE
user default off
user admin on #$(sha256hex "$ADMIN_PASS") ~* &* +@all
user siteuser on #$(sha256hex "$SITE_PASS") ~example.com:* resetchannels +select|0 +ping +info +get +mget +set +setex +del +incrby +decrby +flushdb +eval +scan +zadd +zcount +zrangebyscore +zremrangebyscore
ACL_FILE
sudo chown redis:redis /etc/redis/users.acl
sudo chmod 640 /etc/redis/users.acl
echo 'aclfile /etc/redis/users.acl' | sudo tee -a /etc/redis/redis.conf >/dev/null
sudo systemctl restart redis-server

We did not guess that list. We ran the plugin as a user with almost no rights and read Redis's ACL LOG after each round of visitors, admin screens, publishing, comments, transients and flushes, adding only what was refused, until nothing was. Now look around as the admin, and prove the limits from the site's side.

rcli() { REDISCLI_AUTH="$(sudo cat /root/redis-admin.pass)" sudo --preserve-env=REDISCLI_AUTH redis-cli -s /run/redis/redis-server.sock --user admin "$@"; }
rcli acl whoami
rcli acl list
site() { REDISCLI_AUTH="$SITE_PASS" sudo --preserve-env=REDISCLI_AUTH -u siteuser redis-cli -s /run/redis/redis-server.sock --user siteuser "$@"; }
site set example.com:test 1
site set other:test 1
site flushall
site config get dir

ACL WHOAMI prints admin, and ACL LIST shows the default user off. The site user's first write works. The next three each answer NOPERM: a key outside its prefix, FLUSHALL, and CONFIG. Both functions pass the password through the environment, so it never appears in a process list.

Step 6: Install the plugin and connect WordPress to Redis

The Redis Object Cache plugin supplies a file called object-cache.php, which WordPress loads in place of its built-in cache. WP-CLI installs the plugin and writes the connection settings, including the Unix socket path, into wp-config.php. The helper below runs WP-CLI as the site account, never as root, from a folder that account can enter. It is the same one our stack guide uses.

wps() { ( cd /tmp && sudo -u siteuser -- wp --path=/var/www/example.com/public "$@" ); }
wps plugin install redis-cache --activate
wps config set WP_REDIS_SCHEME unix
wps config set WP_REDIS_PATH /run/redis/redis-server.sock
wps config set WP_REDIS_PREFIX 'example.com:'
wps config set WP_REDIS_PASSWORD "['siteuser', '$SITE_PASS']" --raw
wps redis enable
wps redis status | head -6

The status should begin with Status: Connected, Client: PhpRedis (v5.3.76.2.0), Drop-in: Valid, Disabled: No, Ping: 1 and Errors: []. PHP-FPM re-reads wp-config.php every couple of seconds, so a page may need a moment to notice. If it says Not connected, read the error line, then rcli acl log 5, which names any command or key Redis refused. As an optional tidy-up, the plugin's FAQ suggests deleting the transients that sat in the database before the cache existed: wps transient delete --all.

Step 7: Prove it works, then prove it fails safely

Start with evidence that it works. Redis counts every lookup it answers. A hit means WordPress found the answer in Redis, and a miss means it had to ask MariaDB and store the result. Compare the counters before and after a few page loads.

curl -s -o /dev/null https://example.com/
rcli info stats | grep -E 'keyspace_(hits|misses)'
for i in $(seq 5); do curl -s -o /dev/null https://example.com/; done
rcli info stats | grep -E 'keyspace_(hits|misses)'
curl -s https://example.com/ | grep -A3 'Performance optimized'

Now the part most guides skip. On a staging copy, or in a quiet moment, stop Redis and load the site.

sudo systemctl stop redis-server
curl -s -o /dev/null -w '%{http_code}\n' https://example.com/
wps config set WP_REDIS_DISABLED true --raw
sleep 3
curl -s -o /dev/null -w '%{http_code}\n' https://example.com/
wps config delete WP_REDIS_DISABLED
sudo systemctl start redis-server

The first request returned HTTP 500 with a page saying the Redis connection failed, and the nginx error log showed RedisException: No such file or directory, because the socket file disappears when Redis stops. After we set WP_REDIS_DISABLED and waited a few seconds for PHP to notice the file change, the same page returned 200 with Redis still stopped. That constant is your emergency switch, so remove it once Redis is back.

The plugin's README lists a WP_REDIS_GRACEFUL setting that suppresses the errors, but the vendor marks it unsupported and warns that it can corrupt data, so we leave it alone.

Real failures often repair themselves. Ubuntu's service unit tells systemd to restart Redis whenever it dies. We killed the process with kill -9: a few test requests failed, and the site answered normally about half a second later. A package update restarts Redis the same way, so expect a moment of error pages when redis-server is upgraded.

Step 8: Flush, update and watch it without surprises

wp cache flush and the Flush Cache button empty the object cache, but what they empty surprised us. The plugin runs FLUSHDB, which erases the whole Redis database number, prefix or no prefix. We put two sites in one database with different prefixes and flushed one: the other lost all 105 of its keys. Only WP_REDIS_SELECTIVE_FLUSH limits a flush to one prefix, and the vendor lists it as unsupported because it scans the whole key space with a Lua script.

A flush is safe for visitors. Afterward the administrator session still worked and a shopper's cart still held its item, because logins and WooCommerce sessions live in the database. What disappears are the cached answers, which cost the next visitor a slower page, and transients, which live only in Redis once the object cache is on.

For day-to-day watching, two numbers matter: how full the cache is, and how often Redis has to throw entries away.

rcli info memory | grep -E '^(used_memory_human|maxmemory_human)'
rcli info stats | awk -F: '/^keyspace_hits/{h=$2} /^keyspace_misses/{m=$2} /^evicted_keys/{e=$2} END { r = (h + m) ? 100 * h / (h + m) : 0; printf "hit ratio %.0f%%, evicted keys %d\n", r, e }'

The counters start at zero whenever Redis restarts. A hit ratio that climbs afterward and settles high is healthy, and a few evictions are normal for a cache. Evictions that keep rising while the hit ratio falls mean the cache is too small, so raise maxmemory. Zero evictions with memory far below the cap means you can lower it.

Several sites on one server: database numbers are not walls

Many guides give every site its own Redis database number, from 0 to 15, and call the sites separated. The number is only a namespace. We tested it three ways. On a default Redis, a script running as the shop's account read the blog's cached options: all 116 autoloaded settings on our small blog, including the site address and the admin email. An unrelated account, nobody, could count the keys in and flush every database.

Next we tried the half-fix that most tutorials stop at: a Redis ACL user for the blog with a key pattern, but free to switch databases. It could no longer read the shop's keys. It could still select the shop's database and run FLUSHDB there, and the shop's 39 keys became zero. Key patterns guard only commands that name a key, and flushing a database names none. The accidental version is two sites sharing one database and one prefix: the shop then showed the blog's title and 52 links to the wrong domain.

For pinned databases, add one line to users.acl for each extra site, give its wp-config.php a WP_REDIS_DATABASE, and run rcli acl load. The second site's line has its own hash, prefix and number:

user shopuser on #<sha256 of the shop's password> ~shop.example.com:* resetchannels +select|1 +ping +info +get +mget +set +setex +del +incrby +decrby +flushdb +eval +scan +zadd +zcount +zrangebyscore +zremrangebyscore

With that in place, the blog's user got NOPERM when it tried to select the shop's database, and for FLUSHALL and CONFIG, and Lua scripts that tried to switch databases or touch another prefix were refused as well. Its own FLUSHDB worked and left the shop's 39 keys alone. A default Redis has 16 databases, and the next box explains why only 15 of them can be used.

The cleanest answer is a separate Redis for each site. Ubuntu ships a template unit, redis-server@.service, that reads /etc/redis/redis-NAME.conf. A small drop-in makes the instance run under the site's own group, so only that site's PHP can open its Unix socket. Each site also gets its own memory limit and its own FLUSHALL.

SHOP_PASS=$(openssl rand -hex 32)
sudo install -d -o redis -g redis -m 750 /var/lib/redis/shopuser
sudo tee /etc/redis/redis-shopuser.conf >/dev/null <<EOF
port 0
unixsocket /run/redis-shopuser/redis-server.sock
unixsocketperm 660
dir /var/lib/redis/shopuser
maxmemory 128mb
maxmemory-policy allkeys-lru
save ""
requirepass $SHOP_PASS
EOF
sudo chown redis:redis /etc/redis/redis-shopuser.conf
sudo chmod 640 /etc/redis/redis-shopuser.conf
sudo mkdir -p /etc/systemd/system/[email address].d
printf '[Service]\nGroup=shopuser\n' | sudo tee /etc/systemd/system/[email address].d/group.conf >/dev/null
sudo systemctl daemon-reload
sudo systemctl enable --now redis-server@shopuser
ls -l /run/redis-shopuser/

The shop then uses WP_REDIS_PATH /run/redis-shopuser/redis-server.sock and WP_REDIS_PASSWORD set to the plain password, and its account does not need the redis group at all. In our lab the other site got Permission denied on that Unix socket, and a FLUSHALL there left the shared instance's keys untouched. The price is one more service per site to restart, update and monitor.

Check your WordPress Redis object cache in five minutes

Run these and compare the results with what you intended.

sudo ss -tlnp | grep 6379 || echo "OK: no network listener"
ls -l /run/redis/redis-server.sock
rcli config get maxmemory-policy
rcli config get save
rcli acl list
site set other:test 1
wps redis status | head -6
rcli info stats | grep -E 'keyspace_(hits|misses)|evicted_keys'

You are looking for: no listener on 6379; a Unix socket owned by redis:redis (valkey:valkey on Valkey) with mode srwxrwx---; policy allkeys-lru and an empty save value; the default user off and each site user limited to its own prefix; NOPERM for a key outside that prefix; Status: Connected; and hits that grow much faster than misses. From another machine, nc -vz your-server-address 6379 should fail. That is the test that matters.

Common Redis object cache mistakes

• Opening port 6379, or binding to every address, "so another server can use it". If you truly need that, use TLS, a Redis ACL and a firewall rule for one address.
• Setting a memory limit but leaving the policy at noeviction. The first time the object cache fills, the site returns errors.
• Trusting database numbers to keep sites apart, or giving two sites the same database and the same prefix.
• Editing the database with SQL, restoring a dump or running wp search-replace without flushing the cache afterward.
• Running redis-cli FLUSHALL on a Redis shared with other sites or applications.
• Putting a comment line in users.acl, or restarting Redis before testing the file with ACL LOAD.
• Forgetting to add the PHP account to the redis group (valkey on Valkey), or to restart PHP-FPM afterward. The result is Permission denied and an error page.
• Deleting the plugin before running wp redis disable, which leaves a drop-in with no plugin behind it.
• Sharing this Redis with locks or queues that must not be evicted, or pointing a monitoring tool that expects no password at a Redis whose default user is off. Give such tools their own limited user.

Keep it healthy: a monthly 10-minute routine

• Run systemctl is-active redis-server (valkey-server on Valkey) and check that your uptime monitor still loads a real page.
• Read the memory and eviction numbers from Step 8, and change maxmemory if the trend says so.
• Run wps redis status for every site. After a plugin update, run wps redis update-dropin if it reports an outdated drop-in.
• Compare rcli acl list with your list of sites, and remove users for sites that no longer exist.
• Rotate a site's Redis password when someone who knew it leaves. Add a second hash to the user's line in users.acl and run rcli acl load, change wp-config.php, then delete the old hash and load again. Both passwords work in between, so there is no outage.
• Skim sudo journalctl -u redis-server --since "30 days ago" for warnings, and make sure your WordPress maintenance routine flushes the cache after migrations.

Getting help

If you would rather have someone tune the stack for you, MEI's WordPress Engineering & Plugin Development service starts at $1,200, with fixed scope or hourly work, and covers performance, security hardening and migrations. Our Infrastructure & Private Cloud service starts at $2,500, scoped by systems and scale, and covers provisioning, Linux administration, performance tuning and monitoring. No setup is perfectly secure; we focus on the highest-impact, most likely risks.

For the bigger picture, read our 12-step guide to harden Ubuntu Server, or start with a Business Tech Rescue Audit from $497.