All about Redis on a cluster

A Cyberfusion cluster with one or more nodes in the Redis group automatically has a main Redis instance. On top of that, you can create as many additional Redis instances as you need.

This article explains the two-tier model, the per-instance settings, and the eviction policies — including which one to pick when in doubt.

What Redis is

Redis is an in-memory NoSQL data store. Most projects use it as a cache (WordPress object cache, Laravel cache backend, Symfony cache, etc.) because reads and writes against memory are much faster than reads and writes against MariaDB or PostgreSQL on disk. That's the most common use on a Cyberfusion cluster.

But Redis isn't only a cache. The same instance can hold:

Session stores — server-side login sessions for PHP, Laravel, Symfony, Rails.
Queues — job backends for Laravel Horizon, Sidekiq, Bull, RQ.
Rate-limit counters and locks — atomic INCR / SETNX operations for throttling and one-at-a-time guards.
Pub/sub channels — fan-out messaging for real-time features.
Application data — leaderboards, recent-activity feeds, presence tracking. Redis is a full key/value store with rich data types (lists, sets, sorted sets, hashes, streams).

Knowing which of these a Redis instance is for matters mainly because it changes which eviction policy you want. A cache can lose keys silently — that's the point. A queue or session store can't.

The main Redis instance

Every cluster with at least one Redis-group node has one main Redis instance, set up automatically. You configure it in 'Cluster Properties' > 'Redis':

'Redis Password' — the password for the main instance. Minimum 24 alphanumeric characters.
'Redis Memory Limit' — memory cap in MB.

The main instance is the simplest path: no extra setup, ready to use as soon as the cluster has a Redis-group node.

Additional Redis instances

When you need stronger isolation — a separate password, a dedicated memory budget, a different eviction policy — create additional Redis instances. They are independent of the main instance.

Where to find them

In Core, the top-level 'Redis Instances' page lists additional instances. Click 'Create' to add one.

Per-instance fields

'Cluster' — which cluster the instance lives on. Must have a Redis-group node.
'Name' — lowercase, digits, dash, underscore.
'Port' — the TCP port the instance listens on.
'Password' — minimum 24 alphanumeric characters.
'Memory Limit (MB)' — memory cap. Minimum 8.
'Max Databases' — how many Redis logical databases this instance exposes (the indices you SELECT between).
'Eviction Policy' — what Redis does when memory is full. See 'Eviction policies' below. If you don't know what to set: allkeys-lru.

Main vs additional — when to use which

Use the main instance when:

You want the simplest setup.
A single Redis instance shared across the cluster is fine.

Create an additional instance when:

You want a separate password for a specific app or tenant.
You want a dedicated memory budget that won't compete with other workloads.
You need a different eviction policy than the main instance uses.

Eviction policies

When a Redis instance hits its 'Memory Limit (MB)', it has to decide what to do with the next write that would push it over. The 'Eviction Policy' is that decision.

Two questions determine the choice:

What's evictable? All keys, only the ones you've given a TTL (a time-to-live with EXPIRE), or nothing?
Which key goes first? Least-recently used (LRU), least-frequently used (LFU), shortest TTL, or random?

If you're not sure: allkeys-lru

For the most common simple use case — a WordPress object cache or a Laravel/Symfony cache backend — pick allkeys-lru. It treats the whole instance as a cache, evicting the keys that haven't been touched in a while as new ones come in. You don't have to remember to set TTLs on what you write; Redis handles the pressure for you.

The same advice applies to most "I just want a fast cache" setups: WooCommerce, Craft, Magento page cache, Symfony's cache pool. Pick allkeys-lru and move on.

The eight policies

Policy	What's evictable	How it chooses	When to pick
`noeviction`	nothing	— — writes fail with an error	Queues, session stores, anything where losing a key is worse than rejecting a write
`allkeys-lru`	all keys	Least Recently Used	Default for caches. WordPress, Laravel cache, generic page cache
`allkeys-lfu`	all keys	Least Frequently Used	Caches with a clear hot/cold split where recency lies (e.g. a periodic crawler touches everything once)
`allkeys-random`	all keys	random	Rarely the right pick — only when access patterns are perfectly uniform
`volatile-lru`	only keys with a TTL	Least Recently Used	Mixed instance: cache entries get TTLs, app data doesn't, and you want only the cache to evict
`volatile-lfu`	only keys with a TTL	Least Frequently Used	Same as `volatile-lru` but for caches with hot/cold-by-frequency patterns
`volatile-random`	only keys with a TTL	random	Rarely the right pick
`volatile-ttl`	only keys with a TTL	shortest TTL first	When you want the keys closest to expiring anyway to go first

The four allkeys-* policies will evict anything if the instance fills up — handy when the whole instance is a cache, but dangerous if you also keep things in there that you can't afford to lose.

The four volatile-* policies only touch keys that have an explicit TTL. A key written without EXPIRE is untouchable. That's the right pick when one Redis instance holds both cache entries (with TTLs) and durable application data (without TTLs) and you want only the cache to feel memory pressure.

noeviction does what it says: when the instance is full, writes start failing with an OOM error. Reads are still fine. Pick this for queues and session stores where dropping a job or signing a user out is worse than the application getting an error on the write and having to retry.

Mixing caches and queues on one instance

A common mistake: running both a cache and a queue on the same Redis instance with a cache-oriented policy like allkeys-lru. The instance fills up, Redis evicts queue jobs to make room for fresh cache entries, and jobs are dropped with no error. Either split into two instances (additional Redis instances are cheap), or set the policy to noeviction and size the memory limit for the queue's worst case.

Use cases by target group

Web agencies — the main instance is almost always enough. A cache backend for a single WordPress or Craft site doesn't justify the extra setup and password management of a dedicated instance.
SaaS — one additional instance per tenant (or per environment) means one tenant's heavy cache writes can't push another tenant's cache entries out. Use a noeviction policy when the instance is the queue backend — the application gets a clear error and can retry, instead of jobs being dropped to free memory.
Tech agencies / large platforms — separate instances per role: one tuned for cache (allkeys-lru, generous memory), one tuned for queues (noeviction, smaller memory). On a shared instance, when memory fills up, Redis evicts queue jobs (because the policy is cache-oriented) and the jobs are silently gone.
Shops — a dedicated instance for the storefront's session/cart store keeps it isolated from any analytics or BI workloads sharing the cluster.