Skip to content

All about Redis

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, and so on) 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 and 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 is allowed to drop keys without telling you, since a dropped key just means the next read goes to the database. A queue or session store isn't: a dropped key there means a lost job or a user who gets signed out.

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 needs no extra setup. It's ready to use as soon as the cluster has a Redis-group node.

Additional Redis instances

Create additional Redis instances when you need stronger isolation, such as a separate password, a dedicated memory budget, or a different eviction policy. 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, use 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:

  1. What's evictable? All keys, only the ones you've given a TTL (a time-to-live with EXPIRE), or nothing?
  2. 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 or 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. Redis handles the memory pressure whether or not you set TTLs on what you write.

The same advice applies to most "I just want a fast cache" setups: WooCommerce, Craft, Magento page cache, Symfony's cache pool.

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 The 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, for example when 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. That's 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 is 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 (you can create as many additional Redis instances as you need), 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, so the application gets a clear error and can retry instead of jobs being dropped to free memory.
  • Tech agencies and 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 and cart store keeps it isolated from any analytics or BI workloads sharing the cluster.