Jabali Cache

Jabali Cache makes WordPress fast by keeping its object cache in Redis instead of rebuilding it on every request. WordPress normally throws away its internal cache at the end of each request, so the same expensive database queries run again and again. This plugin makes that cache persistent — backed by the Redis instance the Jabali hosting panel already runs — so pages assemble from memory instead of hammering MySQL.

It is purpose-built for shared hosting, where many sites share one Redis server. That shapes every design decision: strict per-site isolation, safe behaviour under memory pressure, and a hard rule that a caching layer must never take a site down.

Why you might want it

• Fewer database queries, faster pages. Options, post meta, terms, user data and transients come from Redis on repeat requests instead of MySQL.
• Lighter database load. Especially noticeable on WooCommerce, membership, and query-heavy sites under traffic.
• Drop-in. Activate it and WordPress’s standard object-cache API (wp_cache_*, transients) starts using Redis. No theme or plugin changes.

Built for the way Jabali hosts sites

• Zero-config on Jabali. Connects to the panel Redis over the unix socket /run/redis/redis.sock, logical database 1. Nothing to type — no host, port, or password.
• Strict per-site isolation. Every install gets its own key prefix. Sites share one Redis database but can never read or flush each other’s cache. A site’s flush only clears that site’s keys.
• No phpredis required. If the redis PHP extension is present it is used automatically; if not (the Jabali default), the plugin falls back to a dependency-free, pure-PHP RESP client over the same socket. Either way it just works.
• Safe under memory pressure. The panel Redis runs an allkeys-lru policy, so it may evict keys at any time. Every read is best-effort — an evicted or missing key simply falls through to the database. An eviction is never an error.
• Fails safe, always. If Redis is unreachable for any reason, WordPress keeps running with its normal per-request cache. Nothing breaks; caching just stops accelerating until the connection is back. The admin screen tells you exactly what is wrong and how to fix it.
• Multisite-aware. On a network, per-blog data is namespaced per site while genuinely global groups (network, site meta) are shared correctly.

Object cache vs. page cache

The persistent object cache is the main event and is on as soon as you activate the plugin.

A full page cache is also included, but it is off by default. Jabali already serves a faster page cache at the edge via nginx (FastCGI microcache), so turning on the WordPress page cache as well would just cache the same HTML twice. Enable the in-WordPress page cache only on hosts where the nginx one is not available.

Privacy

Jabali Cache stores WordPress’s own cache data in your Redis server and nowhere else. It does not collect analytics, contact any external service, or send data off your server.

Support

Development happens on GitHub. Found a bug, or have a feature request? Please open an issue:

https://github.com/shukiv/jabali-panel/issues