Redis object cache for WordPress, managed per site from the dashboard
Persistent object cache that accelerates logged-in users, admin screens, and every uncacheable database round-trip. Per-site key prefix, TLS, ACL, and a debug header that proves the cache is working.
Full-page caching misses logged-in users, admin, and uncacheable queries
Full-page caching serves static pages fast but does nothing for a logged-in editor, a WooCommerce product page with live stock counts, or a complex WP_Query that runs on every admin screen load. An object cache stores the result of expensive database calls and serves them from memory on repeat requests, cutting database load and admin latency for the requests that need it most.
Under the hood
The steps that make it work, and what each one does.
Connect to your Redis instance
Point WPMgr at your Redis host and port. Optionally set TLS, a password, or an ACL user. WPMgr generates a unique per-site key prefix so sites sharing a Redis instance cannot overwrite each other's data.
Deploy the drop-in
WPMgr pushes an object-cache drop-in to the site via the agent. WordPress picks it up automatically with no plugin activation or manual file editing. The drop-in degrades to in-memory cache if Redis becomes unreachable.
Verify with the debug header
Every cached response carries an x-wpmgr-object-cache header showing hit, miss, or bypass for that request. The dashboard surfaces the hit ratio, memory usage, and latency history so you can confirm the cache is serving traffic.
Monitor hit ratio and memory over time
The dashboard plots hit ratio, memory consumption, and average latency over time. A low hit ratio or rising memory shows up before it affects site performance.
What's included
Every capability ships in the open-source release.
phpredis with TLS and ACL
The drop-in uses phpredis for the Redis connection and supports TLS, password auth, and ACL usernames for environments that require it.
Per-site key prefix
WPMgr generates a unique key prefix per site so multiple sites sharing a Redis instance are fully isolated without needing separate Redis databases.
Graceful Redis fallback
If Redis becomes unreachable the drop-in degrades to in-memory caching for that request. WordPress continues working and the dashboard marks the site's object cache as degraded.
Hit ratio, memory, and latency dashboard
Per-site hit ratio, memory usage, and average operation latency are tracked over time and plotted in the dashboard. Trends show up before they affect performance.
Debug header per request
The x-wpmgr-object-cache response header shows the cache state for each request: hit, miss, bypass, or error. Enabled for admin users always; opt-in for all requests via a flag.
Fleet-wide object cache overview
The fleet performance dashboard shows which sites have object caching enabled, their hit ratios, and any sites currently degraded, so you can manage Redis health across the whole portfolio from one view.
Questions answered
Common questions about this feature.
Self-host it, read the code, and run your whole fleet.
Free and open source. No per-site fee. The full release is on GitHub.