How to Set Up Redis Object Cache for WordPress Without Running Out of Memory

Redis object caching is one of the highest-impact things you can add to a WordPress site — it stops WordPress from re-running the same database queries for menus, options, and transients on every single page load, and the difference in TTFB and database CPU is real. But there's a gap in almost every setup guide out there: they walk you through installing Redis and flipping it on, and never mention that Redis with no memory ceiling will happily eat every megabyte of RAM your VPS has, especially right after you've already sized your MySQL buffer pool and PHP-FPM workers to fit a small box.

If you followed our guide on fixing VPS out-of-memory issues, you already know the shape of this problem — MySQL wasn't the villain, an unbounded config was. Redis defaults to exactly the same trap: maxmemory 0, meaning unlimited, is the out-of-the-box setting, confirmed in Redis's own documentation on key eviction. Here's how to add Redis without undoing the memory work you already did.

Budget the memory before you install anything

On a small VPS, every service is competing for the same RAM — including, if you're running one, a Supervisor-managed queue worker, which is easy to forget about when sizing everything else. Before touching Redis, decide what share of memory it's actually allowed, using the same VPS tiers from our cloud cost breakdown:

Here's what that split actually looks like on the smallest, tightest tier — the one where getting this wrong hurts most:

These are starting points, not fixed rules — but the principle is what most guides skip: Redis isn't a free add-on to an already-tuned server, it's a new claim on the same finite RAM. On a 1 GB VPS especially, a generously-sized Redis instance can be the thing that tips you back into the exact OOM situation you may have just fixed.

Step 1: Install Redis and the PHP extension

sudo apt update
sudo apt install redis-server php-redis

Confirm the PHP extension loaded:

php -m | grep redis

Step 2: Configure Redis with an actual memory ceiling

sudo nano /etc/redis/redis.conf

Set these three directives — using the 1 GB VPS row from the table above as an example:

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

bind 127.0.0.1 keeps Redis reachable only from the local machine — port 6379 is one of the most commonly scanned ports on the internet, and Redis has no authentication by default, so this line isn't optional. maxmemory-policy allkeys-lru tells Redis to evict the least-recently-used cache entries once it hits the ceiling, rather than the default noeviction policy, which instead starts rejecting new writes — quietly breaking your cache instead of just trimming it. Redis's own eviction documentation, linked above, is worth a skim if you want the full list of available policies beyond LRU.

Restart to apply:

sudo systemctl restart redis-server

Step 3: Connect WordPress

Install the Redis Object Cache plugin — maintained by Till Krüss, whose plugin (and its commercial sibling, Object Cache Pro) is the de facto standard here, running on well over a million WordPress sites — then add these lines to wp-config.php above the /* That's all, stop editing! */ line:

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_CACHE', true );

In WordPress admin, go to Settings → Redis and click Enable Object Cache.

Step 4: Verify it's actually caching, and that the ceiling holds

Don't just trust the plugin's green checkmark. Watch Redis directly under real traffic:

redis-cli info memory

Look at used_memory_human against the maxmemory you set. Then check hit rate:

redis-cli info stats | grep keyspace

A healthy cache shows keyspace_hits climbing much faster than keyspace_misses as pages get requested repeatedly. If evicted_keys (from the same info stats output) is climbing quickly while your hit rate stays low, your ceiling is too small for your dataset — that's the signal to raise maxmemory a step, not to remove the limit entirely.

One thing that quietly breaks this setup later

The Redis Object Cache plugin works by writing a file, wp-content/object-cache.php, directly into your WordPress install — it's not a normal plugin file tracked the usual way. If you deploy via git, a CI pipeline, or an rsync-based deploy script, that file can silently get wiped on the next deploy, and object caching quietly stops working with no error — the site just gets slower again. If you're deploying this way, add an exception for that file in your deploy process, or re-run the plugin's "Enable Object Cache" step as part of deployment.

Frequently asked questions

Does Redis need to be backed up like the database does? No — treat it as disposable. Unlike the MySQL backups in our database backup guide, Redis here holds nothing that doesn't already exist in MySQL; it's purely a cache of query results. If it's wiped or restarted, WordPress just rebuilds the cache from the database as pages are requested again — slower for a few minutes, never data loss.

Redis or Memcached — does it matter? For a standard WordPress setup, Redis is the more common recommendation today, mainly because of its richer data structures and the maturity of the plugin ecosystem around it — the Redis Object Cache plugin used in this guide is built specifically around Redis, not Memcached.

Will this help a low-traffic personal blog? Not much. Object caching earns its keep on sites with heavy dynamic content — WooCommerce, membership logins, anything that can't be fully page-cached. If you're running the kind of small personal project from our cost breakdown's first scenario, page caching alone likely covers you, and adding Redis is one more thing to maintain for little gain.

What if I'm also offloading media to object storage? They solve different problems and stack fine together — Redis speeds up database queries, while our guide on offloading WordPress media to Cloudflare R2 takes image storage off your VPS's disk entirely. Neither competes with the other for the RAM budget in the table above.

When Redis isn't worth adding yet

If your site is a low-traffic blog or brochure site already comfortably served by page caching, object caching solves a problem you may not have. On a 1 GB VPS specifically, weigh it against what else is competing for that same RAM; sometimes the better next step is upgrading the VPS tier rather than squeezing one more service onto it.

Configuration values in this guide reflect current Redis and Redis Object Cache plugin practice as of August 2026.