Organisation Caches

An organisation cache is a managed Valkey instance that belongs to your organisation instead of to a single application. Create it once and attach it to environments across as many applications as you need.

Valkey is a Redis-compatible drop-in, so any existing Redis client library works against it without code changes. The Managed Valkey Cache page covers the client details, the TLS and authentication requirements, cluster mode and eviction, which all apply here.

Creating one

There are two places to create a cache.

Under Cloud → Resources, choose Create Resource, select the managed cache type, and set a storage cap between 1 and 50 GB. That cap is the maximum amount of data the cache will hold.

In the Resources section of any application creation wizard, choose Create a new resource for the cache, give it a name and a cap, and it is created and attached to the new application’s production environment as part of the deployment. If your organisation already has a cache, choose Attach an existing resource instead. See About Shared Resources.

Names must start with a lowercase letter or number and contain only lowercase letters, numbers and hyphens, between 2 and 41 characters.

Attaching it to an environment

Expand the resource on Cloud → Resources, pick the application and environment, and optionally set an environment variable prefix. You can also attach from the Resources card on an application’s Environments page.

A cache attachment is a declaration rather than an immediate change, so nothing is written to the environment at the moment you attach. The cache has to be available before you can attach it. The connection details are rendered into the environment at its next deploy, which means you have to redeploy the environment before the cache becomes usable. The Redeploy action on the environment is enough; you do not need to change the container configuration. When you attach a cache while creating an application, the creation flow applies that deploy for you once the environment exists, so the first running version already has the cache.

On that deploy the environment receives:

Variable	Value
REDIS_ENABLED	true
REDIS_HOST	The cache endpoint hostname
REDIS_SERVICE_PORT	6379
REDIS_TLS	1, so connections must use TLS
REDIS_USER	Cache username, injected as a secret
REDIS_PASSWORD	Cache password, injected as a secret
CACHE_PREFIX	A per-environment key prefix

With a prefix of MEDIA these become MEDIA_REDIS_HOST, MEDIA_REDIS_USER and so on. The credentials follow the same rule as the plain variables, so a prefixed attachment never leaves an unprefixed REDIS_USER behind to mismatch the host it belongs to.

Quant’s Drupal application templates look for REDIS_ENABLED=true and configure the Redis module themselves, so an unprefixed attachment needs no further configuration.

Each environment gets its own credentials and key space

Every environment attached to a cache gets its own CACHE_PREFIX (its environment name) and, for attachments made from September 2026 onward, its own cache user. That user is restricted at the server to keys beginning with its prefix and cannot run FLUSHALL or FLUSHDB, so a staging environment cannot read, overwrite or purge production’s keys even though both use the same instance. The cache enforces this; nothing in your application is involved beyond using the prefix.

The user owns keys in both of the forms client libraries produce, so either works:

Key form	Who writes it
production:...	Libraries that prepend the prefix as-is, such as Laravel with REDIS_PREFIX or the WordPress object cache with WP_REDIS_PREFIX
{production}:...	Libraries that wrap the prefix in a hash tag so every key shares one cluster slot. The Quant Drupal templates do this, which is what lets the Drupal Redis module delete several keys in one command on a cluster-mode cache

Your application has to prefix its keys with CACHE_PREFIX for that to work. The Quant Drupal and Laravel templates do this automatically (the Laravel template applies {CACHE_PREFIX}: at the connection level, so set CACHE_STORE=redis, SESSION_DRIVER=redis or QUEUE_CONNECTION=redis to move those drivers onto the cache); WordPress does when its object-cache prefix is pointed at CACHE_PREFIX. An application that writes a key outside its prefix gets a NOPERM error from the cache straight away rather than silently colliding with another environment, so a misconfiguration shows up on the first request. A PHP session handler that writes to the same cache needs prefix= in its session.save_path for the same reason.

Attachments made before scoped users existed still use the cache’s shared credential and rely on the prefix by convention only. Detaching and reattaching such an environment moves it onto its own scoped user.

Integrations that need FLUSHDB

Because the scoped user cannot run FLUSHDB, frameworks that clear the cache that way get a permission error. Laravel’s cache:clear and Cache::flush() do; so does the WordPress Redis Object Cache plugin unless WP_REDIS_SELECTIVE_FLUSH is on. The Drupal Redis module clears with a prefixed marker key, so it is unaffected.

You have three options, in order of preference:

1. Use tag-based or prefix-based clearing in the application, or the Purge keys action described below, which deletes only that environment’s keys.
2. Attach the environment with the Admin (entire cache) access level. It then receives the cache-wide credential instead of its own user, and can read, write and flush every attached environment’s keys. Pick this only when the integration genuinely requires it; the attachment is labelled admin access so the trade-off stays visible. On the API this is accessLevel: "admin" on the attach request.
3. Retrieve the admin credential (below) for one-off maintenance from outside the environment.

Administrative access and purging

Because an environment’s own user cannot run FLUSHDB or see other environments’ keys, two operations have their own controls under Cloud → Resources:

• Admin credentials shows the cache-wide credential (every key, every command). Use it only when you genuinely need unrestricted access, for example from a maintenance script. Each time it is revealed is recorded against your user.
• Purge keys on an attachment deletes that environment’s keys only, in both prefix forms, using its CACHE_PREFIX. Nothing else in the cache is touched, and no application configuration is needed. Very large key spaces are purged in bounded passes; the API returns a cursor to continue from when a pass runs out of time.
• Flush entire cache deletes every key for every attached environment. It asks you to confirm, because it affects all of them at once.

The same operations are available on the API, so they can be scripted from CI: GET .../resources/{resource}/credentials for the admin credential and POST .../resources/{resource}/purge with scope: "environment" plus the application and environment, or scope: "all" with confirm: true.

Detaching

Detaching removes the cache variables and credentials from the environment and redeploys it so the stale references are dropped, which briefly interrupts the environment. The environment’s own cache user is removed in the background over the following minute or two; the detach itself returns straight away.

Cached data is not deleted by a detach. Because keys are namespaced per environment, reattaching the same environment later gives it the same prefix and any keys that have not expired are still there.

Applications with an older per-application cache

Before organisation caches existed, a cache could be enabled on a single application from its Environments page. That option has been removed from the dashboard, and new caches are always organisation resources. An application that still has one of those older caches keeps working unchanged. Its Environments page shows the cache as a read-only Legacy managed cache row, and the cache attach form on that page does not offer organisation caches, because an application cannot use both kinds at once. If you want to move such an application onto an organisation cache, contact support.