Organisation Caches
An organisation cache is a managed Valkey instance that belongs to your organisation instead of to a single application. Create it once under Cloud → Resources 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, TLS and authentication requirements, which are the same here.
Choosing between an application cache and an organisation cache
Section titled “Choosing between an application cache and an organisation cache”Both give you the same Valkey engine and the same connection variables, and they differ in what owns the cache.
| Application cache | Organisation cache | |
|---|---|---|
| Created from | The application’s Environments page | Cloud → Resources |
| Shared by | Every environment of that one application | Any environment you attach it to, across applications |
| Survives | For the life of the application | Until you delete the resource |
Use an application cache when only one application needs it. Use an organisation cache when several applications share a cache, or when you want the cache to outlive any particular application.
Creating one
Section titled “Creating one”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.
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
Section titled “Attaching it to an environment”Expand the resource, pick the application and environment, and optionally set an environment variable prefix.
A cache attachment is a declaration rather than an immediate change, so nothing is written to the environment at the moment you attach. This is also why you can attach a cache that is still provisioning. 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.
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.
Keys stay separate per environment
Section titled “Keys stay separate per environment”Every environment attached to a cache gets its own CACHE_PREFIX, so a staging environment cannot read or evict production’s keys even though both use the same instance. Use CACHE_PREFIX in your own cache keys if your framework does not apply it for you.
Detaching
Section titled “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.
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.