How to Set Up Redis Object Caching for WordPress

Your WordPress site has a page cache, yet wp-admin drags, logged-in pages crawl, and WooCommerce checkout feels slow. That is the gap a persistent object cache fills, and this DevAnswers guide sets one up with Redis on your own server: what object caching actually does, the install, connecting WordPress, verification, and the instant recovery path if anything misbehaves.

Quick Answer: Redis Object Caching in Four Steps #

On an Ubuntu or Debian VPS running WordPress, the whole setup is four moves:

1. Install the Redis server: sudo apt install redis-server
2. Install the PHP extension, then restart PHP-FPM: sudo apt install php-redis followed by sudo systemctl restart php8.3-fpm (match your PHP version)
3. Install and activate the Redis Object Cache plugin, then click Enable Object Cache (Settings › Redis).
4. Verify: the plugin status reads Connected, or wp redis status says so from the shell.

The plugin talks to Redis at 127.0.0.1:6379 out of the box, which matches a default same-server install, so most setups need no configuration at all. The rest of this guide explains each step, what it does to your site, and how to back out safely.

Object Cache vs Page Cache: What Redis Actually Speeds Up #

Page caching saves the entire rendered HTML of a page; when a cached page is served, WordPress does not run at all. That is why it is spectacular for anonymous traffic and useless for everything else: logged-in users, carts, checkouts, personalized content, and every wp-admin screen skip the page cache, and for those requests WordPress runs in full.

Running in full means database work. A typical page load executes on the order of 50 to 200 database queries, pulling options, post content, and user data. An object cache stores those query results in memory, so when the same data is needed again WordPress reads it from RAM instead of asking MySQL. Memory access is dramatically faster than database queries, and the effect compounds on query-heavy sites. The two caches are complements, not rivals: page cache for visitors, object cache for the dynamic requests the page cache cannot touch.

Install and Secure the Redis Server #

Ubuntu and Debian ship Redis in their repositories, so the install is one package (Redis also publishes its own APT repository with newer builds, but the distro package is exactly right for cache duty). It starts automatically and should restart at boot; the enable line makes sure of it:

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

Confirm it answers:

redis-cli ping

PONG

One security note before moving on. Redis is designed to be accessed by trusted clients inside trusted environments; it should never be exposed directly to the internet. The Ubuntu and Debian packages bind it to 127.0.0.1 (localhost only) by default, which is exactly right for WordPress on the same box; you can confirm the bind line in /etc/redis/redis.conf. Leave it that way unless your database of cached objects genuinely lives on another host.

Install the PHP Redis Extension #

WordPress needs a PHP client to talk to Redis. The plugin supports two: PhpRedis, a compiled C extension, and Predis, a pure-PHP library bundled as a fallback. PhpRedis is the one you want when you control the server, and on Ubuntu/Debian it is a package install away:

sudo apt install php-redis
sudo systemctl restart php8.3-fpm

Swap php8.3-fpm for your PHP version (check with php -v), and if you run Apache with mod_php, restart apache2 instead. The restart matters: PHP only loads extensions at startup, so until it happens WordPress cannot see the extension. Verify with:

php -m | grep redis

redis

Connect WordPress with the Redis Object Cache Plugin #

Install the free Redis Object Cache plugin from Plugins › Add New (or wp plugin install redis-cache --activate). It works by placing an object-cache.php drop-in file into wp-content/; enabling it from Settings › Redis › Enable Object Cache (or wp redis enable) is what actually switches persistent caching on.

By default the drop-in connects to 127.0.0.1:6379 and selects database 0. For a same-server Redis you are done. If your Redis lives elsewhere or listens differently, open the file with sudo nano wp-config.php from your site root and define the connection constants above the “That’s all, stop editing!” line:

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

On managed WordPress hosting this whole section may already be done for you: Cloudways, for example, ships Redis and the commercial Object Cache Pro plugin as part of the stack, so there the job reduces to flipping it on per application.

Verify It’s Working #

Three checks, any one of which settles it:

• The plugin settings page shows Status: Connected and names the client (PhpRedis).
• From the shell, run inside your WordPress directory (e.g. cd /var/www/yoursite), wp redis status reports the connection, and wp help redis lists the rest of its commands.
• Watch it think: redis-cli monitor prints live traffic while you click around wp-admin. Ctrl+C to stop. It streams every command the server handles, so run it only briefly, and avoid it on a busy or shared Redis: it adds load and prints live keys and values.

The practical difference shows up where the page cache cannot help: wp-admin screens, logged-in browsing, and cart or checkout flows on busy dynamic sites feel snappier because repeat queries stop hitting MySQL.

Troubleshooting and Instant Recovery #

• Status: Not connected / connection refused. Redis is not running (sudo systemctl status redis-server), or the host/port constants point somewhere Redis is not listening. Confirm with redis-cli ping first, then re-check WP_REDIS_HOST and WP_REDIS_PORT.
• Plugin says PhpRedis is missing. The extension is not loaded for the PHP that serves your site: re-run php -m | grep redis and restart PHP-FPM (or Apache). On shared hosting, ask your host to enable the extension.
• Site misbehaves or shows stale content after enabling. Flush the cache first: wp cache flush or the Flush Cache button. If that does not settle it, disable via the drop-in delete above and investigate calmly.
• Multiple WordPress sites on one Redis. Give each site its own database index with WP_REDIS_DATABASE (Redis has 16, numbered 0-15). Sharing one database with key prefixes is discouraged: a cache flush from any one site clears them all.

If Redis caching caused a wp-admin update loop for you, that specific failure has its own fix: see the WordPress database update loop guide, which is usually a persistent-object-cache symptom.

When Redis Helps (and When It Won’t) #

The rule from the last row: for small, mostly-static sites, page caching alone often provides sufficient performance, and adding an object cache mostly adds a service to maintain. Put your effort where your traffic is dynamic.

Next Steps #

You now have query results served from memory and a one-file exit if you ever need it. One setting worth making deliberate: out of the box Redis has no memory cap and evicts nothing, which is fine for a small site but worth bounding on a busy one. Set maxmemory 256mb and maxmemory-policy allkeys-lru in /etc/redis/redis.conf (then restart Redis) and it behaves like a proper cache, discarding the least-recently-used entries at the cap. Use allkeys-lru only when this Redis instance is dedicated to caching; if the same Redis also holds sessions, queues, or other non-cache data, that policy can evict those too, so give WordPress its own Redis (or at least its own database) first. After that, an occasional glance at the plugin’s Metrics tab tells you the hit-ratio story.

For a deeper dive into performance, our guide on tuning a VPS for WordPress covers Nginx caching and MariaDB optimizations.

• Pair it with page caching if you have not already; the two attack different halves of the load.
• Running WooCommerce? The checkout and cart flows are where you should feel this most; test them logged-in before and after.