Set Up a Redis Object Cache for WordPress on Your Server

You add a Redis object cache to WordPress in four moves: run Redis on the same server, install the free Redis Object Cache plugin, add a few constants to wp-config.php, then enable the cache and confirm it connects. The whole job takes about 30 to 60 minutes on a VPS where you have SSH and sudo access.

Here is the surprising part: WordPress already has an object cache built in. The catch, in the words of the official WordPress reference, is that "by default, the object cache is non-persistent." It is thrown away at the end of every page load, so the next visitor makes WordPress ask the database the same questions again.

By the end of this guide you will have a persistent cache that survives between page loads, a Redis server that only listens on your own machine, and a backup of wp-config.php you can roll back to in seconds.

What a Redis object cache actually is

The WordPress reference describes it in one line: "The WordPress Object Cache is used to save on trips to the database." Each time WordPress needs an option, a post, or a user, it checks the cache first and only asks MySQL (the database server) when the answer is missing.

Think of a coffee shop. The built-in WordPress cache is a jug of milk on the counter that gets poured away after each customer. Redis is a small fridge behind the counter: the milk stays ready for the next order.

Redis is an in-memory data store, which means it keeps data in RAM (the server's fast working memory). The Redis Object Cache plugin connects WordPress to it. Its plugin page calls it a "persistent object cache backend powered by Redis" and lists support for the Predis, PhpRedis and Relay clients, plus replication, sentinels, clustering and WP-CLI.

Why this matters: the reference page says cached data "will not be stored persistently across page loads unless you install a persistent caching plugin." This plugin plus Redis is that missing piece.

Heads up: an object cache is a different thing from a page cache. A page cache saves whole finished HTML pages. An object cache saves the smaller pieces WordPress uses to build pages, such as query results and options, so it can still help on requests that skip the page cache. If you also want page caching, see our guide on how to optimize WordPress load times with LiteSpeed Cache.

Before you start

First, check that Redis is possible on your hosting at all. Many shared hosting plans do not offer Redis, and you cannot install system software there yourself. If you are on shared hosting, open your host's knowledge base or ask support "Do you offer Redis for WordPress, and what host, port and database should I use?" If you are not sure what kind of plan you have, our explainer on what web hosting is covers the main types.

For the self-managed path in this guide, you need:

• A VPS or dedicated server running Ubuntu, with SSH access and a user that can run sudo.
• WordPress 4.6 or higher and PHP 7.2 or higher. Those are the minimums listed on the Redis Object Cache plugin page at the time of writing (16 October 2026).
• WP-CLI (the command line tool for WordPress) installed, or a WordPress admin login. I show both paths.
• A fresh full backup of files and database, stored off the server.
• About 30 to 60 minutes, plus a quiet time of day in case you need to roll back.
• Risk level: low to medium. A mistake in wp-config.php can take the site down, but restoring the backup copy fixes it in one command.

Install Redis and lock it to your server

Step 1: Install the Redis server package

On Ubuntu, Redis ships as the redis-server package in the universe repository. At the time of writing (16 October 2026), Ubuntu 24.04 LTS (noble) carries Redis 7.0.15 in that package.

These commands refresh the package list and install Redis from your distribution's repository:

sudo apt update
sudo apt install redis-server

If you want the newest release, the official Redis docs describe adding the packages.redis.io repository and installing the redis package instead. Pick one source and stick with it.

After installing, Redis should start on its own. The Redis install docs note that if it does not start across reboots, you can enable it manually. These commands make Redis start at boot and start it now:

sudo systemctl enable redis-server
sudo systemctl start redis-server

This command shows whether the service is running:

sudo systemctl status redis-server

You should see the word active (running) in the output. Press q to leave the status screen.

Step 2: Check that Redis answers on 127.0.0.1 port 6379

By default, redis-cli (the Redis command line client) connects to 127.0.0.1 on port 6379. Typing the address anyway shows exactly what you tested.

This command sends a PING to Redis on the local loopback address:

redis-cli -h 127.0.0.1 -p 6379 ping

The expected reply is one word:

PONG

If you get PONG, Redis is alive and listening locally. If the command reports that it could not connect, jump to the troubleshooting section before going further.

Step 3: Confirm Redis only listens locally

The bind setting in the Redis config file decides which network addresses Redis listens on. On Ubuntu the file is /etc/redis/redis.conf.

Why this matters: the Redis security docs warn that if you fail to protect the Redis port, "a single FLUSHALL command can be used by an external attacker to delete the whole data set." FLUSHALL wipes everything Redis holds, in one go.

This command shows the active bind and protected-mode lines without opening an editor:

grep -nE "^(bind|protected-mode|port) " /etc/redis/redis.conf

The sample redis.conf from the Redis project contains these lines, and Ubuntu's packaged file should look similar, though it may differ slightly:

bind 127.0.0.1 -::1
protected-mode yes
port 6379

In that sample, bind 127.0.0.1 -::1 keeps Redis on the loopback address (the machine talking to itself), and protected-mode yes is on. Protected mode, available since Redis 3.2.0, makes Redis reply only to loopback clients when it runs with the default configuration (binding all interfaces) and no password.

If the bind line is missing or commented out with #, back up the file and fix it. This command copies the config before you touch it:

sudo cp /etc/redis/redis.conf /etc/redis/redis.conf.bak

Then open the file with sudo nano /etc/redis/redis.conf, make sure this line exists and is not commented out, and save:

bind 127.0.0.1 -::1

This command restarts Redis so it reads the new setting, then tests it again:

sudo systemctl restart redis-server && redis-cli -h 127.0.0.1 -p 6379 ping

You should see PONG again.

Step 4: Block the Redis port in your firewall

The Redis security docs say that on a server directly exposed to the internet, "the Redis port should be firewalled to prevent access from the outside." Local clients can still use the loopback address. Binding to 127.0.0.1 is your first lock, the firewall is your second.

If your server uses UFW (Uncomplicated Firewall, common on Ubuntu), this rule denies outside TCP traffic to port 6379:

sudo ufw deny proto tcp to any port 6379

This command lists your active rules so you can confirm it:

sudo ufw status

Heads up: if UFW is currently inactive, do not run sudo ufw enable straight away on a remote server. UFW's default incoming policy is deny, and if you have not allowed SSH first you can lock yourself out. If your provider has a cloud firewall in its control panel, you can block port 6379 there instead.

Connect WordPress to Redis

Every step here ends with a site check, because a problem is easiest to fix right after the change that caused it.

Step 5: Back up wp-config.php

The wp-config.php file lives in the root folder of your WordPress install, the same folder that holds wp-admin and wp-includes. In the commands below, replace /var/www/example.com with your real path.

This command makes a dated copy of the file next to the original:

cd /var/www/example.com && cp wp-config.php wp-config.php.bak-redis-$(date +%F)

This command confirms the copy exists:

ls -l wp-config.php*

You should see the original and the dated .bak-redis copy.

Step 6: Add the Redis constants to wp-config.php

A constant is a fixed setting that WordPress reads every time it loads. The Redis Object Cache install guide lists the ones you need, and two details matter most.

First, placement. The plugin docs say to put the constants above the line that loads wp-settings.php, and the WordPress wp-config.php handbook's example likewise says to place such lines above any require_once or include. If you put them below, WordPress has already started and simply ignores them.

Second, the prefix. WP_REDIS_PREFIX adds a short label to every cache key. The plugin docs say to use a unique prefix and a different database number for each site to avoid cache data collisions.

Option A, with WP-CLI. The wp config set command adds a constant if it does not exist yet, and --raw writes numbers without quotes. Run these from your WordPress folder:

wp config set WP_REDIS_HOST "127.0.0.1"
wp config set WP_REDIS_PORT 6379 --raw
wp config set WP_REDIS_DATABASE 0 --raw
wp config set WP_REDIS_PREFIX "examplecom:"
wp config set WP_REDIS_TIMEOUT 1 --raw
wp config set WP_REDIS_READ_TIMEOUT 1 --raw

Each line should print a Success: message.

Quick tip: run WP-CLI as the user that owns the site files, not as root, so file ownership stays correct.

Option B, by hand. Open wp-config.php in an editor and paste this block above the line that starts /* That's all, stop editing! (the rest of the comment varies by WordPress version):

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_REDIS_PREFIX', 'examplecom:' );
define( 'WP_REDIS_TIMEOUT', 1 );
define( 'WP_REDIS_READ_TIMEOUT', 1 );

Whichever option you used, open the file and check that the new lines sit above require_once ABSPATH . 'wp-settings.php';. It takes ten seconds.

The values above match the plugin defaults for host, port and database. Database numbers run from 0 to 15, and the timeout values of 1 follow the plugin's install guide.

Made-up example: Sara runs two WordPress sites on one VPS, a shop and a blog. She sets the shop to database 0 with prefix shopexample: and the blog to database 1 with prefix blogexample:. When she clears the blog's cache, the shop's cache is untouched.

Now test the site. Load your homepage in a private browser window and log in to the admin area. Both should look exactly as before, because the cache is not switched on yet. If you see a white screen or a PHP error, restore the backup straight away:

cp wp-config.php.bak-redis-$(date +%F) wp-config.php

Step 7: Install the Redis Object Cache plugin

At the time of writing (16 October 2026), the plugin is at version 3.0.0 and is tested up to WordPress 7.1.3.

In the dashboard, open the Plugins screen, add a new plugin, search for "Redis Object Cache", then install and activate it.

With WP-CLI, this command installs and activates it in one step:

wp plugin install redis-cache --activate

You should see Plugin installed successfully. followed by a Success: line.

Test the site again: homepage in a private window, then the admin area. Installing the plugin on its own does not switch on the cache, so nothing should change yet.

Step 8: Enable the object cache

Enabling the cache copies a small file called a drop-in (object-cache.php) into wp-content. WordPress loads this file automatically and uses it in place of its default memory-only cache.

In the dashboard, go to Settings > Redis (on Multisite, Network Admin > Settings > Redis) and click the button to enable the object cache.

With WP-CLI, this command does the same thing:

wp redis enable

Test the site one more time: browse a few pages, open a post in the editor, and if you run a shop, add something to the cart.

Quick tip: run wp help redis to see every Redis command the plugin adds on your version.

How to check it worked

1. Redis is up: redis-cli -h 127.0.0.1 -p 6379 ping returns PONG.
2. The plugin sees Redis: Settings > Redis does not show Not connected. If it does, see troubleshooting below.
3. WP-CLI agrees: wp redis status shows the plugin's diagnostics, and the plugin's install guide uses it to check the connection.
4. Keys are being written. Browse a few pages on the site, then run the command below.

This command counts how many keys are stored in database 0 (use your own database number with -n):

redis-cli -h 127.0.0.1 -p 6379 -n 0 dbsize

You should see a number greater than zero, written like (integer) 245. The exact number depends on your site.

1. Redis is not reachable from outside. From your own laptop, not the server, run this command with your server's public IP:

redis-cli -h 203.0.113.25 -p 6379 ping

This should fail to connect. If it returns PONG, stop and fix bind and the firewall before doing anything else.

Troubleshooting

Problem: redis-cli cannot connect to Redis

Symptom: redis-cli ping reports a connection error (such as a refused connection) instead of PONG.

Likely cause: the Redis service is stopped or failed to start, often after a typo in redis.conf.

Fix: run sudo systemctl status redis-server and read the last lines. If you edited the config, restore it with sudo cp /etc/redis/redis.conf.bak /etc/redis/redis.conf, then sudo systemctl restart redis-server.

Problem: Settings > Redis shows "Not connected"

Symptom: Redis answers PONG in the terminal, but the plugin reports Not connected.

Likely cause: the constants are in the wrong place in wp-config.php (below wp-settings.php), have a typo, or point at a different host or port than Redis uses.

Fix: open wp-config.php and check that every WP_REDIS_ line sits above the require_once line. Compare WP_REDIS_HOST and WP_REDIS_PORT with the bind and port lines in redis.conf. The plugin's install guide also says that if you see this status, you can ask your host for help or adjust the connection settings yourself.

Problem: White screen or PHP error right after editing wp-config.php

Symptom: the site shows a blank page or a PHP error instead of your homepage.

Likely cause: a missing semicolon, a missing quote, or a smart quote pasted from a word processor.

Fix: restore the backup with cp wp-config.php.bak-redis-YYYY-MM-DD wp-config.php, replacing the date with the one on your copy. Then add the constants again with WP-CLI, which writes the syntax for you.

Problem: You need to switch the cache off fast

Symptom: something looks wrong after enabling, such as stale content or a plugin conflict, and you want the cache off while you investigate.

Likely cause: varies, so the first goal is to get back to a known good state.

Fix: toggle the object cache off in Settings > Redis (run wp help redis to find the matching command on your version). If you cannot reach the admin area, add define( 'WP_REDIS_DISABLED', true ); above the require_once line in wp-config.php. The plugin changelog says version 1.3.5 added this constant to disable the cache at runtime, and version 3.0.0 indicates when the cache is disabled via the constant.

Problem: Two sites on one server show each other's data

Symptom: a site shows the wrong title, menu, or settings, or logging in to one site behaves oddly.

Likely cause: both sites share the same WP_REDIS_DATABASE and the same WP_REDIS_PREFIX, so their cache keys collide.

Fix: give each site its own prefix and database number, as in the made-up example above. Then flush each site's cache once with wp cache flush, run from that site's folder.

Security notes and when to ask for help

Keep Redis on 127.0.0.1 with the firewall rule in place. That covers the single server setup in this guide.

If you ever need Redis on a separate server, that is a bigger project. The Redis security docs recommend Access Control Lists (named users with their own permissions) and describe requirepass as the legacy method. They also warn that AUTH, the login command, is sent unencrypted, so a password alone does not protect traffic on an untrusted network. At that point, bring in a developer or your host.

Heads up: be careful with FLUSHALL and FLUSHDB in redis-cli. They delete data with no undo. To clear the WordPress cache, use wp cache flush, which goes through WordPress and should print Success: The cache was flushed. The WP-CLI docs warn that on Multisite this typically flushes the cache for all sites.

The one message worth forwarding

If your host or a developer will do this for you, send them this:

Hi, I would like a persistent Redis object cache for my WordPress site example.com.
Could you please:
1. Install Redis on the server, bound to 127.0.0.1 port 6379 only, with the Redis port blocked in the firewall.
2. Add WP_REDIS_HOST, WP_REDIS_PORT, WP_REDIS_DATABASE (unique number for this site) and WP_REDIS_PREFIX (unique for this site) above the wp-settings.php line in wp-config.php, after taking a backup copy of the file.
3. Install and enable the Redis Object Cache plugin, then confirm the connection with wp redis status.
4. Tell me how to disable it quickly if something breaks.
Thank you!

Takeaway: Redis turns the throwaway WordPress memory cache into one that lasts between page loads, and with a wp-config.php backup and a site check after every step, you can undo it in seconds.