Redis Caching Layer Setup for High-Traffic WordPress/WooCommerce on Bare Metal

Fast NVMe storage solves half the speed problem on a high-traffic WooCommerce store. The other half lives in the database layer — and that's where Redis object caching comes in. This guide covers installing and configuring Redis as a persistent object cache on a bare-metal server running WordPress/WooCommerce, including the WooCommerce-specific gotchas that trip up most setups.

Why NVMe Alone Isn't Enough

Fast disks speed up reads and writes at the storage layer. But WordPress doesn't hit the disk for most page loads — it hits MySQL, repeatedly, for the same option rows, term hierarchies, user meta, and WooCommerce cart/session data. On a WooCommerce store, a single logged-in customer browsing a category page can trigger dozens of near-identical database queries per request.

Redis object caching sits between WordPress and MySQL, storing the results of those queries in memory. Instead of re-querying the database on every page load, WordPress reads the cached result from RAM in microseconds. The two layers are complementary, not competing:

• Page cache (Varnish, LiteSpeed Cache, WP Super Cache) — caches fully rendered HTML for anonymous, logged-out visitors.
• Object cache (Redis) — caches database query results for everyone, including logged-in users, cart pages, checkout, and the admin dashboard, where page caching can't help at all.

For WooCommerce specifically, this matters because cart, checkout, "my account," and admin order screens are never anonymous — they're exactly the pages page caching skips.

Prerequisites

• A bare-metal or dedicated server running Ubuntu 22.04/24.04 or Debian 11/12
• Root or sudo access
• WordPress with WooCommerce already installed
• PHP 8.1+ with the ability to install PHP extensions
• At least 512MB–1GB of free RAM to dedicate to Redis on a WooCommerce store (plain WordPress sites can often run on 256MB)

Step 1: Install Redis Server

Update your package lists and install the Redis server:

sudo apt update
sudo apt install redis-server -y
                            

Check that it's running:

sudo systemctl status redis-server
redis-cli ping
                            

A healthy install responds with PONG.

Step 2: Configure Redis Memory and Eviction Policy

By default, Redis has no memory limit and no eviction policy — which means it will happily consume all available RAM and then start refusing new writes once it's full. For a cache (as opposed to a primary data store), that's the wrong behavior.

Edit /etc/redis/redis.conf and set the following values:

maxmemory 512mb
maxmemory-policy allkeys-lru
bind 127.0.0.1 -::1
                            

• maxmemory — set this based on available RAM and traffic. WooCommerce stores typically need 512MB–1GB; a busy catalog with heavy filtering may need more.
• maxmemory-policy allkeys-lru — evicts the least-recently-used keys once memory fills, instead of rejecting new cache writes. Never leave this on the default noeviction for a cache workload — it causes Redis to reject new entries and can serve stale data once memory is full.
• bind 127.0.0.1 — ensures Redis is bound to localhost only unless your database and web server are on separate hosts.

Restart to apply:

sudo systemctl restart redis-server
                            

Step 3: Install the PHP Redis Extension

WordPress needs a PHP client to talk to Redis. The PhpRedis (PECL) extension is the fastest and most widely supported option:

sudo apt install php-redis -y
sudo systemctl restart php8.1-fpm   # match your actual PHP-FPM version
                            

Confirm it loaded:

php -m | grep redis
                            

Step 4: Install the WordPress Object Cache Plugin

Install Redis Object Cache (by Till Krüss) — the standard, widely deployed plugin for this — from the WordPress plugin repository, or via WP-CLI:

wp plugin install redis-cache --activate
                            

Step 5: Configure the Connection in wp-config.php

Add these constants above the /* That's all, stop editing! */ line in your wp-config.php file:

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_CACHE', true );
define( 'WP_REDIS_PREFIX', 'yourstore_' );
                            

Note: If you're running multiple WordPress sites on the same Redis instance (common on a shared bare-metal box), set a unique prefix (WP_REDIS_PREFIX) per site so their cache keys don't collide.

Step 6: Enable the Object Cache

Via WP-CLI:

wp redis enable
                            

Or from Settings → Redis in the WordPress admin, click Enable Object Cache. The plugin drops an object-cache.php file into wp-content/ — this is the actual drop-in WordPress loads on every request, and its presence is what activates the cache.

Status should read Connected. If it doesn't, check:

• redis-cli ping responds.
• The PHP Redis extension is loaded for the PHP-FPM pool actually serving requests (not just CLI PHP).
• WP_REDIS_HOST and WP_REDIS_PORT match your redis.conf bind address and port.

Step 7: WooCommerce-Specific Considerations

WooCommerce leans on transients and session data more heavily than plain WordPress, so a few extra checks matter here:

• Cart and session behavior: WooCommerce stores cart contents primarily in a database session table and cookies, not through the WordPress object cache directly — so Redis won't break cart persistence. But WooCommerce does cache product data, stock counts, and shipping calculations as transients, which do go through the object cache.
• Cache invalidation on order/stock updates: If you also run a full-page cache layer, make sure it's configured to purge on order status changes, stock updates, and price changes — Redis object cache alone handles this correctly via WordPress's own cache invalidation hooks, but a separate page cache needs its own purge rules.
• Exclude WP-CLI batch operations where relevant: Bulk imports (product feeds, ERP syncs) can be faster with the object cache temporarily disabled, since writing thousands of cache entries during a one-time import adds overhead without ongoing benefit.
• REST API and checkout endpoints: WooCommerce's REST API and AJAX-driven checkout calls benefit noticeably from object caching, since these bypass page cache entirely and hit PHP/MySQL on every call.

Step 8: Verify It's Actually Working

Enabling a plugin doesn't guarantee real performance gains — confirm cache hits are actually happening:

redis-cli info stats | grep keyspace
                            

Watch keyspace_hits climb relative to keyspace_misses as you browse the site. A healthy, warmed-up cache should show a hit ratio well above the miss ratio during normal browsing.

You can also check directly from the plugin's admin screen, which shows hit/miss counts and estimated memory usage without needing shell access.

Troubleshooting Checklist

Rollback

If Redis causes instability, disable cleanly without losing the rest of your configuration:

wp redis disable
sudo systemctl stop redis-server
                            

Removing the object-cache.php drop-in (or simply disabling via WP-CLI, which removes it automatically) reverts WordPress to its default in-memory-per-request caching with no persistent layer.