Set Up Redis Object Cache for WordPress on a VPS

The Problem: Your WordPress Site Is Doing Too Much Database Work

When a WordPress site starts feeling slow, most teams blame PHP, hosting, or a bloated theme first. Sometimes that is correct. But a lot of WordPress performance problems come from something more boring and more expensive: the same database queries running over and over again for data that does not change every second.

That pattern shows up everywhere. WooCommerce has to load product settings, cart fragments, and plugin options. Membership plugins check capabilities and metadata. Builders and marketing plugins pull option rows repeatedly. Admin screens get sluggish because every page load triggers another round trip to MySQL for data WordPress already asked for a moment ago.

That is exactly the problem Redis object caching is meant to solve. Instead of asking MySQL the same questions on every page view, WordPress stores frequently used objects in memory and reuses them. Done properly, that can cut database load, speed up repeat requests, and make the admin side feel much less sticky.

This guide shows how to set up Redis object cache for WordPress on a VPS, verify that it is actually working, and harden the setup so it helps rather than creating a new failure point. If your store is already struggling under load, pair this with our guide to why WooCommerce stores slow down. If you are choosing caching plugins more broadly, also see our comparison of WordPress caching plugins in 2026.

What You Will Need

For most WordPress sites using Redis for object caching, we recommend starting with a Canadian Web Hosting Cloud VPS that has at least 2 vCPUs, 4 GB RAM, and SSD storage. Redis itself is lightweight, but WordPress, PHP-FPM, MariaDB or MySQL, and your web server still need headroom. WooCommerce stores, membership sites, and multisite installs often benefit from 8 GB RAM once traffic and plugin count start growing.

You will need:

• Ubuntu 24.04 or a similar supported Linux distribution
• A working WordPress installation with shell access
• Root or sudo access to install packages and restart services
• PHP Redis extension support
• A recent backup before changing production cache behaviour

If you would rather have our team handle the OS, patching, and service monitoring, add Managed Support. For agencies or stores where downtime is expensive, that is often the cleaner choice.

Installation Steps

1. Install Redis server and the PHP Redis extension

First install the Redis service itself plus the PHP extension WordPress uses to talk to it. On Ubuntu 24.04, these packages are available directly from the default repositories.

sudo apt update
sudo apt install -y redis-server php-redis
sudo systemctl enable --now redis-server
sudo systemctl status redis-server --no-pager

What this does: it installs the Redis daemon, installs the native PHP extension, and starts Redis immediately so WordPress can use it.

Verify: the final command should show Redis as active (running). You can also test the service directly:

redis-cli ping

Expected output: PONG

Common issue: if php-redis is installed but your web server still cannot see it, you may need to restart PHP-FPM and your web server later in the process.

2. Confirm PHP can load the Redis extension

Before touching WordPress, confirm that the PHP runtime serving your site can actually load the extension. This avoids the common mistake of installing Redis successfully while WordPress still complains that the client is missing.

php -m | grep -i redis
php --ri redis | head

What this does: it checks the CLI PHP environment for the Redis extension and prints basic module information.

Verify: you should see redis in the module list. If you use PHP-FPM, reload it after package install:

sudo systemctl restart php8.3-fpm
sudo systemctl restart nginx

Common issue: if you run Apache instead of Nginx, restart Apache rather than PHP-FPM service names that do not exist on your stack.

3. Install the Redis Object Cache plugin in WordPress

The easiest production path is the Redis Object Cache plugin by Till Krüss. It is widely used, simple to enable, and exposes health information in the WordPress admin.

cd /var/www/html/your-site
wp plugin install redis-cache --activate
wp plugin status redis-cache

What this does: it installs and activates the plugin from the WordPress.org repository.

Verify: wp plugin status redis-cache should report the plugin as active.

Common issue: if WP-CLI is unavailable, install and activate the plugin through the WordPress admin instead, then continue with the configuration below.

4. Add Redis configuration to wp-config.php

For most single-server WordPress setups, Redis should listen locally and not be exposed publicly. Add the basic connection settings before the line that says /* That's all, stop editing! */.

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_CACHE_KEY_SALT', 'example.com:' );

What this does: it points WordPress at the local Redis instance and uses a unique cache key salt so multiple sites on one host do not collide.

Verify: check the syntax quickly before reloading anything:

php -l wp-config.php

Expected output: No syntax errors detected in wp-config.php

Common issue: forgetting WP_CACHE_KEY_SALT on multi-site or multi-vhost servers. That can create ugly cross-site cache contamination.

5. Enable the object cache and confirm writes reach Redis

Now enable the object cache drop-in and make WordPress talk to Redis for real.

wp redis enable
wp redis status
redis-cli INFO stats | grep -E 'keyspace_hits|keyspace_misses'

What this does: it creates the object-cache drop-in, turns on Redis object caching for WordPress, and shows whether Redis is serving cache lookups.

Verify: wp redis status should show the cache as connected. The INFO stats output should begin changing as you browse the site and admin area.

Common issue: if the plugin says the drop-in is missing or unwritable, check file permissions in wp-content/.

Configuration for Production

Installing Redis is the easy part. Making it production-safe means paying attention to memory, persistence, and failure mode. Redis is in-memory by design, so you should treat it like disposable performance infrastructure, not your source of truth. WordPress content still belongs in MySQL or MariaDB. Redis is there to remove repeated database work, not replace the database.

For a straightforward WordPress deployment, the default local-only listener is usually enough. In /etc/redis/redis.conf, confirm Redis stays bound to localhost and protected mode remains enabled:

bind 127.0.0.1 ::1
protected-mode yes
port 6379

If you want tighter memory control, add an eviction policy rather than letting Redis grow unchecked. A practical starting point for small-to-medium WordPress sites is something like this:

maxmemory 256mb
maxmemory-policy allkeys-lru

Why it matters: on a busy server, an unlimited Redis instance can compete with PHP-FPM and MariaDB for RAM. That is how a performance optimization turns into swap pressure.

After changing the config, reload Redis:

sudo systemctl restart redis-server
sudo systemctl status redis-server --no-pager

If your WordPress stack is also handling HTTPS termination and reverse proxying locally, our guide to Caddy with automatic HTTPS is a practical companion for cleaning up the front end of the stack.

Verify That It Works

Do not trust a green plugin toggle alone. Verify the cache from both WordPress and Redis.

wp redis status
redis-cli monitor

In another shell, load a few frontend pages and an admin screen. In the monitor output you should see Redis commands scrolling by. Then stop the monitor with Ctrl+C and run:

redis-cli INFO memory | grep used_memory_human
redis-cli INFO stats | grep keyspace
wp option get siteurl

Expected results:

• WordPress reports an active Redis connection
• Redis shows memory usage greater than zero
• Keyspace hits start increasing as pages are revisited
• Your site loads normally with no fatal errors or blank admin screens

If the site is still slow after Redis is active, the bottleneck may be elsewhere. Use our guide to fixing a slow WordPress admin to check plugins, queries, cron load, and PHP workers before throwing more hardware at the problem.

Production Hardening

Firewall rules

Redis should almost never be open to the public internet for a single-server WordPress deployment.

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw deny 6379/tcp
sudo ufw status

Expected output: 80 and 443 allowed, 6379 denied.

HTTPS and application security

Object caching is not a substitute for WordPress security basics. Keep TLS enabled, restrict admin access where appropriate, and maintain plugin hygiene. Our WordPress security hardening guide covers the controls you should already have in place before tuning for speed.

Backup strategy

You do not need to back up Redis cache contents the same way you back up your database, but you do need working backups of WordPress files and MySQL or MariaDB. If Redis dies, the cache should rebuild. If your database dies, your site is down. For production stores, pair your VPS with CloudSafe Backup.

Log and resource monitoring

Watch for memory pressure, Redis restarts, and rising PHP worker time. A slow site with object caching enabled can still indicate overloaded CPU, insufficient PHP workers, or plugin-level query problems. For broader infrastructure diagnosis, keep our high server load troubleshooting guide handy.

Troubleshooting

WordPress says the Redis extension is missing

Cause: the PHP Redis extension is not installed for the PHP version your site is actually using, or PHP-FPM has not been restarted.

php -m | grep -i redis
php -v
sudo systemctl restart php8.3-fpm
sudo systemctl restart nginx

What you want to see: the Redis module listed in php -m and no plugin warning in wp-admin after the restart.

Redis object cache is enabled but the site gets slower

Cause: Redis memory is too constrained, the server is already overloaded, or a plugin is generating uncachable work.

redis-cli INFO memory | grep used_memory_human
free -h
top -o %MEM

What you want to see: available RAM, low swap activity, and Redis not being evicted constantly. If the host is crowded, move to a larger Cloud VPS tier or trim PHP workers and plugin bloat.

The cache will not connect after enabling the plugin

Cause: wrong host or port in wp-config.php, Redis is stopped, or the drop-in was not written correctly.

wp redis status
sudo systemctl status redis-server --no-pager
grep WP_REDIS_ wp-config.php
ls -lah wp-content/object-cache.php

What you want to see: a running Redis service, the correct local host settings, and an object-cache drop-in file in wp-content/.

Conclusion and Next Steps

Redis object caching is one of the highest-leverage WordPress performance improvements when your bottleneck is repeated database work. It will not fix every slow site, but it often makes a visible difference on WooCommerce stores, busy admin dashboards, and plugin-heavy installs where the same objects are loaded again and again.

For most production WordPress sites, a Cloud VPS is the cleanest place to run Redis because you control the web stack, PHP version, memory budget, and service restarts. If the workload is business-critical, combine that with Managed Support and CloudSafe Backup so the performance gains do not come with operational chaos.

If you are comparing analytics and performance architecture more broadly, our draft on edge computing for Canadian businesses is worth reading next. It covers the bigger latency picture beyond the database layer. And if you need to choose the right caching approach inside WordPress itself, go back to our caching plugin comparison for the page-cache side of the stack.