Valkey and Redis
This page is for hosting companies that run Redis or Valkey and want to offer it to Exponential sites, for speed or
for sites served from several web nodes. It answers: what the sevenx_valkey_cache extension moves into Redis or
Valkey, how to set it up, how several customers can share one server without seeing each other's keys, and what the
limits are. The source is sevenx_valkey_cache: Redis and Valkey cache backend.
Contents
- What it stores
- Requirements
- Setting it up
- Settings
- Several customers on one server
- Clearing
- What it does not cover
- Checklist
What it stores
The extension replaces disk storage for:
{valkey-block ...}template blocks;- the content view cache (
content/viewfull view); - the compiled INI cache, which "removes the per-request touches of
var/cache/ini/*.phpand makes INI caches safe for clusters".
Entries have TTL-based expiry, generation locks against cache stampedes, and reverse node and subtree indexes, so publishing content purges exactly the entries it affects. The kernel calls the extension only when its classes exist, so a site without it pays nothing; on a miss or when disabled, the kernel falls back to the files as before.
Requirements
- Exponential 6.0.15 or later (its kernel calls the extension's hooks).
- The PHP
redisextension, in every PHP that serves the site (the PHP-FPM pool, or Velocity's PHP) and in the command-line PHP that runs cron jobs and cache clears. - A reachable Redis or Valkey server.
Setting it up
Install and activate the extension:
composer require se7enxweb/sevenx_valkey_cache# settings/override/site.ini.append.php [ExtensionSettings] ActiveExtensions[]=sevenx_valkey_cacheConfigure the connection in
settings/override/valkeycache.ini.append.php:[ValkeyCacheSettings] Host=127.0.0.1 Port=6379 Database=0 KeyPrefix=sevenx_valkey_cache: InstallationHash=auto DefaultTTL=3600 LockTTL=30 Persistent=disabled LocalCache=enabled IniCache=enabledRegenerate autoloads and clear the caches (and restart Velocity if it serves the site):
php bin/php/ezpgenerateautoloads.php -e php bin/php/ezcache.php --clear-all --allow-root-userCheck: request a page twice, then list the keys:
redis-cli --scan --pattern 'sevenx_valkey_cache:*'
Settings
All in valkeycache.ini, block [ValkeyCacheSettings]:
| Key | Default | Meaning |
|---|---|---|
Host, Port, Database | 127.0.0.1, 6379, 0 | the server |
KeyPrefix | sevenx_valkey_cache: | prefix of every key; keep it unique per installation when several sites share one server |
InstallationHash | auto | a hash of the database name, site name, filesystem root and host name; a fixed string shares a cache between servers |
DefaultTTL | 3600 | seconds, when no expiry is given |
LockTTL | 30 | seconds a generation lock lives if the generating process crashes |
Persistent | disabled | pconnect; "use with care when several databases share a php-fpm pool" |
LocalCache | enabled | a per-request copy of retrieved entries |
IniCache | enabled | compiled INI arrays in Redis or Valkey |
The content view cache entry is stored for 3600 seconds, a value set in
kernel/private/classes/views/content/view.php, not in an INI file.
Several customers on one server
The extension's own advice is a unique KeyPrefix per installation. For a host:
| Measure | Why |
|---|---|
a unique KeyPrefix per customer installation, for example <customer>: | keys of one site never collide with another's |
InstallationHash=auto unless the same site runs on several web nodes | separates installations that share a prefix by mistake |
a fixed InstallationHash string for one site on several web nodes | every node then reads the same entries |
Persistent=disabled where pools are shared | the setting's own caution |
| a database number or a separate server per customer, where your Redis or Valkey setup allows access control | a prefix separates keys; it does not stop one customer's code from reading another's |
Warning
A shared Redis or Valkey server is shared memory: every site on it can read every key unless the server's own access control prevents it. Treat it like a shared database server in your isolation design (Multi-tenant isolation), and check your Redis or Valkey documentation for its access control.
Size the server for the number of pages and siteaccesses and set an eviction policy; "a server outage turns into cache misses"; the extension decides how errors are reported.
Clearing
- Clearing the INI cache deletes the INI entries; publishing purges the view and block entries of the affected nodes and their ancestors.
- The extension's page names
bin/php/ezvalkeycacheclear.php(added 20 July 2026), which clears all caches through the same handlers the administration uses, flushes the keys the extension wrote, and regenerates extension autoloads. It is the fallback when Clear all caches cannot clean up after an extension is removed or a cache backend is disabled.
What it does not cover
| Cache | Where it stays |
|---|---|
| Sessions | PHP's session handler (files by default); the role-aware HTTP cache needs files |
| Velocity's response cache | APCu and var/cache/qbix-reverse |
| The SQL query cache | APCu or files (querycache.ini Storage) |
| Compiled templates, image aliases | files in var/ |
settings/file.ini mentions that a cache layer such as Memcached or Redis can be added in the cluster backend; that is
a separate, clustering topic (Clustering and shared storage).
Checklist
- To do: PHP
redisextension in web and command-line PHP. - To do: Unique
KeyPrefixper installation;InstallationHashdecided. - To do: Server sized, eviction policy set, access control between customers considered.
- To do: Keys appear after two page views; the behavior with the Redis or Valkey server stopped tested on staging.
- To do: Support knows
ezvalkeycacheclear.php.
Related pages
- Caching layers
- Several web nodes
- Cache clearing and warming
- sevenx_valkey_cache
- Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.
Become an Exponential Partner
Partners share their information, provide funding, contribute back and develop the products with us, and that is how Exponential grows. A partner website and dashboard are planned for mid-2027: please become a partner today to speed up our growth rate and land new features faster.