November 2026 • Guide

This page rests on WordPress documentation (developer.wordpress.org and the WordPress hosting handbook), the Redis Object Cache plugin page and installation guide, Redis and Valkey project pages, and PHP and Memcached project pages, all fetched in November 2026. Plugin versions and licence terms are given as of November 2026. We publish no benchmark numbers, because we did not measure any.

A WordPress Redis object cache is a persistent object cache: WordPress keeps the results of expensive lookups in Redis memory so that later page loads can reuse them instead of asking the database again. It helps most on pages that cannot be served from a full-page cache, such as logged-in users, carts and admin screens. It does little for pages that a page cache already serves as ready-made HTML.

This guide explains what the object cache is, when Redis changes the result and when it does not, how the Redis Object Cache plugin works, how Redis licensing changed in 2024 and 2025, how to keep Redis safe on a shared server, and how to measure the effect without inventing numbers. At the end we state what our own platform documents about this topic, including how the Managed Web Server turns an object cache on for a WordPress installation.

What the WordPress object cache is

WordPress has a built-in object cache. According to the developer documentation, it holds data in memory under a key, grouped into named sections. By default it is non-persistent: its entries disappear when the request ends. To keep entries across page loads, a persistent backend is needed. The documentation names Redis and Memcached plugins as examples.

Without a persistent backend, transients (cached values with an expiry time) are stored in the options table of the database. Some cache groups are marked non-persistent even when a persistent backend is active, so their entries last only for one script run. The WordPress caching documentation also states that cached data can be rebuilt at any time: if the cache is lost, the site keeps working and is only slower while the cache refills.

A persistent object cache is installed as a drop-in file named object-cache.php in the wp-content folder. Plugins such as Redis Object Cache place this file for you.

What a persistent WordPress Redis object cache changes

The WordPress hosting handbook says a persistent object cache keeps data between requests and so reduces PHP work and database queries. It says this is especially useful for logged-in traffic and e-commerce, where full-page caching is hard to apply. It also notes that persistent object caching is commonly included in managed WordPress hosting.

For page caching, the same handbook prefers a reverse proxy such as NGINX or Varnish, because it serves cached HTML without touching PHP or the database. A file-based page cache is an acceptable fallback but slower. The two layers do different jobs: the page cache stores the finished page, and the object cache stores pieces of data that WordPress needs to build a page.

When it helps and when it does not

Situation Expected effect Reason
Logged-in users, shop carts, checkout, member areas Can help These requests are usually excluded from the page cache, so WordPress builds them in PHP and asks the database. The handbook names this case.
WordPress admin screens Can help Admin pages are built dynamically for each request. The effect depends on how many repeated lookups the page makes.
Anonymous visitors on pages served by a page cache Little or none A page cache hit does not run PHP or touch the database, so the object cache is not consulted.
A slow plugin that runs uncached custom queries No direct help An object cache only helps for data that the code stores in it. Find the slow query first.
A small brochure site with low traffic Often not noticeable Few queries and few visitors. Measure before adding another service that uses memory and needs maintenance.
A server with little free RAM Can hurt Redis keeps its data in memory. A cache that competes with PHP and the database for RAM can slow the whole server.

The last row is our own reasoning, not a statement from a source. All other effects in the table are conditional. Whether you see a gain depends on the theme, the plugins and the traffic mix, so measure it on your own site.

The Redis Object Cache plugin

The Redis Object Cache plugin by Till Krüss is a plugin that connects WordPress to Redis. Its WordPress.org page reports more than 500,000 active installations as of November 2026. We cite this as a fact about adoption, not as a recommendation. The page shows the following details.

Item Value shown on the plugin page, November 2026
Plugin version 3.0.0
Requires WordPress 4.6 or higher
Requires PHP 7.2 or higher
Tested up to WordPress 7.1.4, as shown on the page
Redis client libraries Predis (bundled), PhpRedis (PECL extension) or Relay
Other features Replication, sentinels, clustering and WP-CLI commands
Authentication and encryption Redis 6 ACL user name and password, and TLS through a connection setting

The plugin page does not name a minimum Redis server version. The plugin documentation we read does not mention Valkey, so compatibility with Valkey is not confirmed here. Ask the plugin author or test it before you rely on it.

Alternatives to a WordPress Redis object cache: Memcached and APCu

Backend What it is Points to consider
Redis An in-memory data store, reached over a network socket or a local port. Widely used with WordPress. Licence history changed in 2024 and 2025 (see below).
Memcached A free, open-source caching system that keeps data in memory and can distribute it across servers. Its project page describes it as meant to speed up dynamic websites by reducing database queries. The WordPress documentation names Memcached as a persistent object cache option. You need a WordPress drop-in plugin that supports it.
APCu An in-memory key-value store for PHP. The PHP manual describes it as APC without opcode caching. It lives in the memory of the PHP runtime on one host. Treat it as a local cache. It is not shared between servers, and it does not replace OPcache, which is a separate extension.

The WordPress caching documentation lists Redis, Memcached, APC and the file system as storage options and says the choice should match the needs of the application. For a single server with one or a few sites, any of these can work. Redis and Memcached become more useful when several PHP workers or several servers must share one cache.

Redis licences in 2024 and 2025, and Valkey

Licence terms matter if you install Redis yourself or if a provider offers it as a service. The history, taken from Redis and Valkey pages, is as follows.

Date Event Licence
Up to Redis 7.2 Redis describes releases up to 7.2 as Redis Open Source. BSD 3-clause
20 March 2024 Redis announced that, starting with Redis 7.4, new versions would be dual-licensed instead of BSD. Earlier releases stay under BSD. Redis states that the new licences are not OSI-approved open source. RSALv2 or SSPLv1
28 March 2024 The Linux Foundation announced the Valkey project, which continues development from Redis 7.2.4. BSD 3-clause (Valkey)
1 May 2025 Redis added AGPLv3 as an additional option, starting with Redis 8. AGPLv3, or RSALv2, or SSPLv1 (you choose one)

In its 2024 announcement, Redis said that internal use, client libraries and existing commercial customers were not affected. It said RSALv2 prohibits commercialising the software or providing it to others as a managed service. For a business that runs Redis only to cache its own websites, the licence text still needs a read by someone who is qualified to judge it. We do not give legal advice.

Valkey describes itself on valkey.io as an open source (BSD) key-value datastore backed by the Linux Foundation. Its page lists Valkey 9.1.3 as released on 26 October 2026. Both projects change quickly, so check the current licence on the project site when you install.

Security for a WordPress Redis object cache: do not expose Redis, and separate your sites

The Redis security documentation says Redis is designed for trusted clients in trusted environments and must not be exposed directly to the internet. It advises firewalling the Redis port so that only your application servers can reach it. A bind setting such as bind 127.0.0.1 limits Redis to the local machine. The documentation warns that a single command such as FLUSHALL can delete the whole dataset.

  • Network. Listen on localhost or a private network only. Do not publish the port. Protected mode helps, but we advise not to rely on it alone.
  • Authentication. Use Access Control Lists (Redis 6 or later) with a long random password. Authentication is a second line of defence. The documentation notes that commands, including AUTH, are sent unencrypted unless you use TLS.
  • Least privilege. Run Redis as an unprivileged user and restrict dangerous commands such as CONFIG with ACL rules.
  • Key prefix per site. The plugin installation guide says that when several sites share one Redis server, each site needs its own prefix or database number so that cache data does not collide. Flushing a Redis database number clears everything in it, so sites that share a database number can clear each other's cache; this is our reasoning, so test it on your own setup.
  • Separate instances for separate customers. Where sites belong to different customers, a separate Redis instance or ACL user per customer is the safer design. This is our recommendation, not a requirement of the plugin.

WordPress Redis object cache setup with wp-config.php constants

The plugin installation guide describes these steps. Follow its current version, because options change between plugin releases.

  1. Install and start a Redis server, bound to localhost or a private address, or ask your hosting provider to do so.
  2. Make sure PHP has the PhpRedis extension, or use the bundled Predis library.
  3. Install and activate the Redis Object Cache plugin, then open Settings, Redis, and enable the cache. If it connects automatically, you are done.
  4. If it does not connect, add the constants to wp-config.php above the line that loads wp-settings.php.
  5. Check the status in the plugin screen. With WP-CLI, the guide mentions wp redis enable and wp redis status.

Constants named in the installation guide, with the defaults it gives:

  • WP_REDIS_HOST: server address, default 127.0.0.1.
  • WP_REDIS_PORT: port, default 6379.
  • WP_REDIS_DATABASE: database number from 0 to 15, default 0.
  • WP_REDIS_PREFIX: key prefix. Use a unique value for each site.
  • WP_REDIS_TIMEOUT and WP_REDIS_READ_TIMEOUT: connection and read timeouts. The guide's example uses 1 second each.
  • WP_REDIS_PASSWORD and WP_REDIS_USERNAME: named in the plugin changelog for authentication, including Redis 6 ACL users.

The changelog names more constants, such as WP_REDIS_CLIENT and WP_REDIS_SSL_CONTEXT. Read the plugin's configuration documentation before you use them.

How to measure a WordPress Redis object cache honestly

Do not trust a gain you have not measured on your own site. Use the same page, the same state (logged in or not) and the same time of day, and change one thing.

  1. Install the Query Monitor plugin. Its page says it reports slow, duplicate and erroneous database queries and groups queries by component and by calling function. Version 4.1.1 is shown with a date of 27 October 2026. Note the number of queries for a few typical pages before the change.
  2. Measure time to first byte (TTFB) from the command line, for example with curl -s -o /dev/null -w '%{time_starttransfer}\n' https://example.com/. Run it at least 20 times per page and compare medians, not single runs.
  3. Measure the logged-in case separately from the anonymous case, since a page cache hides the object cache for anonymous visitors.
  4. Enable the object cache, let it warm up with a few visits, and repeat the same measurements.
  5. Check the plugin's status screen for hits and misses. A low hit rate means the cache is not helping.
  6. Keep the result only if it is clearly better than the run-to-run variation. Otherwise switch it off and save the memory.

Query count shows what the cache removed. TTFB shows what the visitor notices.

WordPress NGINX hosting: what the server must provide

The WordPress documentation for NGINX says that NGINX needs a PHP backend such as PHP-FPM, that its sample configuration uses a try_files rule for permalinks, and that NGINX has no .htaccess support, so all rules are set by a server administrator at server level. For WordPress NGINX hosting with a Redis object cache, the server therefore has to provide:

  • A Redis or compatible service, listening only on localhost or a private network, with memory limits that leave room for PHP and the database.
  • The PhpRedis extension for the PHP version your site uses, or permission to use Predis.
  • Edit access to wp-config.php and to the wp-content folder, so the drop-in can be installed.
  • A way to give every site its own prefix, database number or ACL user.
  • A page cache for anonymous traffic, with rules that exclude logged-in users, carts and checkout.
  • OPcache enabled and sized, which the hosting handbook recommends for production.

Where PFHW fits, and where it does not

The PFHW panel can turn on a WordPress object cache that uses Redis, one Redis instance per WordPress installation. It is a switch on the Site cache page of a site. When you turn it on, the panel starts the Redis instance and changes wp-config.php after making a backup of that file. It refuses to proceed if another plugin already supplies an object-cache.php drop-in.

The object cache is available only when the plan's object-cache allowance is above zero, so ask which allowance your plan has before you rely on it. The same Site cache page also controls a page cache per site, with a time to live of 1, 5, 10, 30 or 60 minutes, a purge button, and figures for the last 24 hours. In our reasoning, a page cache and an object cache work at different layers and are often used together. We do not publish benchmark numbers, because we did not measure any for this page.

  • Good fit: several WordPress sites on one dedicated server, where each site needs its own isolated object cache without you installing or patching Redis yourself.
  • Check first: the plan's object-cache allowance, and whether your site already uses another object-cache plugin. The panel refuses an existing object-cache.php drop-in from another plugin.
  • Server resources: plans range from 4 GB RAM (Starter) to 32 GB RAM (Max) with dedicated vCPU and RAM. Each cache uses memory, so size the plan for your sites and their caches together.
  • Self-managed option: the PFHW panel can be downloaded free for your own server, without support. Whatever you install beside it is your responsibility.

Frequently asked questions

What is the difference between a page cache and an object cache?

A page cache stores the finished page so that PHP and the database are not used for repeated visits. An object cache stores pieces of data that WordPress needs to build a page. The two work at different layers and are often used together.

Will a WordPress Redis object cache make my site faster?

It can reduce database queries, mainly for logged-in and dynamic pages. For pages served from a page cache it makes little difference. Measure query counts and TTFB before and after on your own site.

Is it safe to run Redis on a shared server?

Only if it listens on localhost or a private network, uses authentication, and each site has its own key prefix or database. Never expose the Redis port to the internet.

Is Redis still free to use?

Redis 7.4 and later are offered under source-available licences, and Redis 8 added AGPLv3 as an open-source option, according to Redis. Versions up to 7.2 are BSD licensed, and Valkey is BSD licensed. Read the licence that applies to the version you install.

Does WordPress NGINX hosting need a Redis object cache?

No. NGINX serves requests and can act as a page cache in front of PHP. A Redis object cache is a separate layer that WordPress uses inside PHP. It is optional and mostly useful for logged-in and dynamic traffic.

Do you offer Redis on the Managed Web Server?

Yes, as a WordPress object cache. The panel's Site cache page can turn on a Redis-backed object cache for a WordPress installation, with one Redis instance per installation. It depends on the object-cache allowance set on the plan, so ask us which allowance your plan has.

Related resources

Sources

Request a demo