Set Up Redis for WordPress With Nginx and PHP-FPM

Object caching is one of the few WordPress changes you’ll feel immediately in wp-admin and for logged-in users. If the dashboard feels “sticky,” or WooCommerce takes a second to reflect cart updates, Redis often helps. It keeps expensive results in RAM instead of rebuilding them on every request.

This guide shows how to set up Redis for WordPress on a VPS running Nginx and PHP-FPM. You’ll install Redis, keep it private, add the PHP extension, enable the WordPress drop-in, and verify real cache hits. The goal is proof it’s working, not just an “enabled” badge.

What you’ll build (and what you need)

• Stack: Nginx + PHP-FPM + WordPress + Redis (local)
• Goal: Faster logged-in/admin performance and fewer repeated database reads
• Servers: Ubuntu 24.04/24.10, Debian 12, AlmaLinux 9/10, Rocky Linux 9/10 (steps include both apt and dnf)

Prerequisites

• A VPS where you can SSH as root (or a sudo user). If you’re moving off shared hosting, start with a HostMyCode VPS so Redis can run alongside WordPress without resource contention.
• WordPress already running behind Nginx + PHP-FPM.
• At least 1 GB RAM. 2 GB is more comfortable if you also run MariaDB/MySQL on the same node.

Step 1: Confirm your PHP-FPM version and pool user

Before you install PHP extensions, confirm the PHP version your site actually uses. It’s common to have PHP 8.2 installed while PHP-FPM is still running 8.1 (or the other way around).

php -v
php-fpm8.3 -v 2>/dev/null || true
php-fpm8.2 -v 2>/dev/null || true
php-fpm8.1 -v 2>/dev/null || true

Next, check your PHP-FPM pool configuration. You’re looking for the Unix user PHP runs as.

It’s usually www-data on Debian/Ubuntu. On RHEL-family systems it’s often nginx or apache.

# Debian/Ubuntu common path
ls -1 /etc/php/*/fpm/pool.d/www.conf 2>/dev/null

# RHEL/Alma/Rocky common path
ls -1 /etc/php-fpm.d/www.conf 2>/dev/null

Open that file and note user, group, and listen.

You’ll need those values later for permissions and restarts.

Step 2: Install Redis server and enable it at boot

For WordPress object caching, run Redis on the same box as WordPress. That keeps latency low.

You also don’t need to expose Redis to the internet. WordPress can talk to it locally.

Ubuntu / Debian

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

AlmaLinux / Rocky

On RHEL-family systems, the package name is still typically redis.

sudo dnf install -y redis
sudo systemctl enable --now redis

Verify Redis is running:

sudo systemctl status redis-server 2>/dev/null || sudo systemctl status redis

And check that it responds:

redis-cli ping

You should see:

PONG

Step 3: Lock Redis to localhost (and set a sane memory policy)

Your WordPress site should connect to Redis over 127.0.0.1 or a Unix socket. Don’t bind Redis to all interfaces.

Exposing Redis is one of the fastest ways to turn “cache” into “incident response.”

Edit redis.conf

Common paths:

• Debian/Ubuntu: /etc/redis/redis.conf
• Alma/Rocky: /etc/redis.conf

sudo nano /etc/redis/redis.conf 2>/dev/null || sudo nano /etc/redis.conf

Make sure these settings exist (adjust as needed for your file). The goal is local-only access, with protected mode enabled.

bind 127.0.0.1 ::1
protected-mode yes
port 6379

Memory policy: For WordPress object caching, Redis should evict older keys instead of refusing writes.

Add or tune the following:

# Pick a cap that fits your VPS. Start conservative.
maxmemory 256mb
maxmemory-policy allkeys-lru

Quick sizing guidance:

• 1 GB RAM VPS: try maxmemory 128mb to 256mb.
• 2–4 GB RAM VPS: 256mb to 512mb is typical for single-site WordPress.

Restart Redis and confirm it still responds:

sudo systemctl restart redis-server 2>/dev/null || sudo systemctl restart redis
redis-cli ping

Optional but recommended: double-check you’re not opening 6379 at the firewall.

Even with local binds, it’s good hygiene to verify.

sudo ss -lntp | grep 6379 || true

You want to see it listening on 127.0.0.1:6379, not 0.0.0.0:6379.

Step 4: Install the PHP Redis extension (for your exact PHP version)

Some WordPress plugins can use Redis via pure PHP. The php-redis extension is faster and usually behaves better under load.

Install it for the same PHP version your PHP-FPM service is running.

Ubuntu / Debian (PHP 8.x typical)

# Installs the extension for the distro's PHP version
sudo apt install -y php-redis

If you keep multiple PHP versions around, you may need a version-specific package (example):

# Example only; use the version you confirmed earlier
sudo apt install -y php8.3-redis

AlmaLinux / Rocky

On many builds, the package is php-pecl-redis (or php-redis depending on your repository).

sudo dnf install -y php-pecl-redis || sudo dnf install -y php-redis

Verify the extension loads

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

You should see Redis in the module list. php --ri redis should also print module details.

Restart PHP-FPM so WordPress can pick up the extension:

# Debian/Ubuntu (adjust version if needed)
sudo systemctl restart php8.3-fpm 2>/dev/null || sudo systemctl restart php8.2-fpm 2>/dev/null || sudo systemctl restart php8.1-fpm

# RHEL-family
sudo systemctl restart php-fpm

Step 5: Install and enable a WordPress Redis object cache plugin

On a VPS running Nginx, you have two realistic plugin paths:

• Redis Object Cache (Till Krüss): simple setup, widely used, and has useful diagnostics.
• LiteSpeed Cache: only if you run LiteSpeed/OpenLiteSpeed; it doesn’t apply to an Nginx stack.

This tutorial uses “Redis Object Cache.” Install it from wp-admin, or use WP-CLI if you have it available.

Option A: WP-CLI (recommended)

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

Option B: WordPress admin

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

Now enable object caching (this writes the object-cache.php drop-in):

cd /var/www/your-site
wp redis enable

If you don’t use WP-CLI, go to Settings → Redis and click Enable Object Cache.

Common mistake: the plugin is active, but the object cache isn’t enabled.

The deciding piece is the drop-in at wp-content/object-cache.php.

ls -l wp-content/object-cache.php

If you’re comparing setups or migrating an existing configuration, this related guide can help: Install Redis Object Cache for WordPress on Ubuntu.

Step 6: Configure WordPress to connect to Redis (TCP or socket)

Most sites should use TCP on localhost and move on. It’s simple and reliable.

A Unix socket can shave a little overhead. It can also create permission and ownership issues.

Start with TCP unless you have a specific reason to switch.

Option 1 (simple): TCP localhost

In wp-config.php, add these settings above the “stop editing” line:

define('WP_CACHE_KEY_SALT', 'example.com:');

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

Why the salt matters: it avoids key collisions if you later point multiple WordPress sites at the same Redis instance.

Option 2 (advanced): Unix socket

If your Redis package supports sockets (most do), set this in redis.conf:

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

Then make sure your PHP-FPM pool user belongs to the redis group (or whichever group owns the socket).

Example for Debian/Ubuntu where PHP runs as www-data:

sudo usermod -aG redis www-data
sudo systemctl restart php8.3-fpm 2>/dev/null || sudo systemctl restart php8.2-fpm 2>/dev/null || sudo systemctl restart php8.1-fpm

Finally, set these in wp-config.php:

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

Quick diagnostic if it fails: this is almost always socket permissions.

Check ownership and mode here:

ls -l /run/redis

Step 7: Verify Redis is actually caching (not just connected)

A “Connected” status is a start. It does not prove you’re getting cache hits.

You want visible key growth and rising hit counters while you use wp-admin.

Check plugin status

From WP-CLI:

cd /var/www/your-site
wp redis status

From wp-admin: Settings → Redis, confirm it shows “Connected” and “Drop-in: Valid”.

Watch Redis live while you browse

Open two SSH sessions.

Session 1: watch the counters:

watch -n 1 'redis-cli info stats | egrep "keyspace_hits|keyspace_misses|evicted_keys|instantaneous_ops_per_sec"'

Session 2: log into WordPress admin and click around (Posts, Plugins, WooCommerce orders, and so on).

You want keyspace_hits to climb steadily. Misses will rise too, especially after a flush or deploy.

Once the cache warms, hits should start to outpace misses.

Confirm keys exist and are expiring

redis-cli info keyspace
redis-cli dbsize

Tip: If dbsize stays near 0 while you browse, the drop-in isn’t active or WordPress can’t write to Redis.

Common failure modes (fast checks)

• PHP extension not loaded: php -m | grep redis shows nothing → install the correct package and restart PHP-FPM.
• Wrong Redis host: some systems resolve localhost to IPv6 first → use 127.0.0.1 explicitly.
• Socket permission denied: switch back to TCP first, or fix group membership and socket permissions.

Step 8: Tune Redis memory without starving MySQL/MariaDB

Redis will use memory aggressively until it reaches maxmemory. Without a cap, the OS can push you into swap.

On a single VPS running Nginx, PHP, and a database, swap thrash is the failure mode to avoid.

Check current memory usage:

redis-cli info memory | egrep 'used_memory_human|maxmemory_human|mem_fragmentation_ratio'
free -h

If swap usage climbs while traffic stays steady, reduce Redis maxmemory.

Then restart Redis:

sudo systemctl restart redis-server 2>/dev/null || sudo systemctl restart redis

If you’re also tightening up your database reliability, keep this guide around: Set Up PostgreSQL Backups With pg_dump + Restore Test. It’s PostgreSQL-specific, but the “restore test” habit applies just as well to MySQL/MariaDB.

Step 9: Add safe Nginx + PHP-FPM headers (so you can measure)

Redis can make the admin area feel snappier. You still need a way to confirm what changed.

The Redis plugin can emit debug headers while you test.

In wp-config.php (temporary, for testing):

define('WP_REDIS_DEBUG', true);

Then inspect headers on a logged-in request:

curl -I https://example.com/wp-admin/ | egrep -i 'x-redis|x-cache|server|x-powered-by'

Not every stack exposes a Redis-specific header. Debug mode often adds useful cache metadata anyway.

Disable it again once you’ve confirmed behavior:

# remove or set to false
# define('WP_REDIS_DEBUG', false);

Step 10: Backup and restore test (because cache changes are still changes)

Redis is a cache, so you typically don’t back it up for WordPress object caching. What you protect is your database and your WordPress files.

After a week of system-level changes, validate restores.

On a VPS, the practical combo is a snapshot plus an app-level backup. Snapshots save you from bad upgrades.

App backups save you from data corruption and accidental deletes.

• Snapshot your VPS (provider-side)
• Export DB: mysqldump or mariadb-dump
• Archive wp-content and wp-config.php

HostMyCode customers who want fewer moving parts often choose managed VPS hosting so core services, backups, and security updates get reviewed instead of drifting into “set it once and hope.”

Troubleshooting: quick fixes for the issues you’ll actually hit

Redis is running, but WordPress says “Not connected”

• Confirm Redis listens on localhost: ss -lntp | grep 6379
• Confirm WordPress connects to 127.0.0.1 (not localhost).
• Check PHP-FPM logs. On Ubuntu/Debian, start with: /var/log/php8.x-fpm.log and Nginx error log.

Redis connects, but dbsize stays near 0

• Object cache drop-in missing: ls -l wp-content/object-cache.php
• File permissions issue. This is common after migrations; see WordPress file permissions fix on a VPS.
• Plugin conflict with another caching plugin trying to own the drop-in.

High CPU on Redis after enabling cache

• Disable debug mode (WP_REDIS_DEBUG).
• Reduce maxmemory and keep allkeys-lru.
• Watch ops: redis-cli info stats | grep instantaneous_ops_per_sec. If it’s extreme, a plugin may be generating unbounded cache keys.

Nginx starts throwing 502 after PHP restart

This isn’t caused by Redis directly. It often shows up after you install PHP extensions and restart services.

Check the PHP-FPM service status. Then confirm Nginx still points at the correct socket or upstream.

Use this checklist-style fix: Nginx 502 Bad Gateway fix on Ubuntu VPS.

Performance expectations: what Redis helps (and what it doesn’t)

Redis object caching helps with repeated, read-heavy work. That includes options loads, user meta, WooCommerce session reads, and query results reused across requests.

You’ll notice the difference most with logged-in traffic and PHP-heavy pages.

Redis will not fix:

• Slow TTFB caused by overloaded CPU or disk I/O
• Unoptimized images and front-end JavaScript bloat
• Bad database indexes or a database server hitting its own limits

If you’re consistently CPU-bound, moving to a larger VPS (or isolating the database on its own node) usually beats micro-tuning.

For busy WooCommerce stores, a dedicated server can make Redis, PHP workers, and database performance far more predictable.

Summary: a clean Redis object cache setup you can trust

You’ve installed Redis, kept it local-only, set an eviction policy, added the PHP Redis extension, enabled the WordPress drop-in, and confirmed real cache hits.

That’s the difference between “it’s installed” and “it’s working.”

If you want infrastructure with enough headroom for this kind of tuning, start with a HostMyCode VPS so Redis, PHP-FPM, and your database live on fast NVMe storage.

When you’re migrating an existing site, HostMyCode migrations can handle the cutover while you focus on testing and validation.

FAQ

Do I need to open port 6379 in my firewall?

No. For WordPress object caching on a single VPS, keep Redis bound to 127.0.0.1 (or a Unix socket) and do not expose it publicly.

Should I use Redis page caching instead of object caching?

For Nginx-based WordPress, start with object caching. Full page caching can be great too, but it’s a separate layer with different rules (cookies, logged-in users, cart pages).

How much memory should I give Redis for WordPress?

On a 1 GB VPS, start at 128mb to 256mb. On a 2–4 GB VPS, 256mb to 512mb is common for a single busy site. Watch swap and adjust.

Why do I see a lot of cache misses right after enabling Redis?

That’s normal. The cache starts cold. After a few minutes of real traffic (especially logged-in sessions), hits should climb faster than misses.

Can Redis break my site?

If configured correctly, Redis typically fails “soft” (cache misses fall back to the database). Problems usually come from exposing Redis publicly, using a Unix socket with wrong permissions, or installing the PHP extension for the wrong PHP-FPM version.