Magento 2 Redis Session and Cache Configuration Guide

Redis is the natural companion to Varnish in a Magento 2 stack: Varnish serves cached pages, Redis holds everything else Magento needs fast access to. Done well, Redis removes most of the read pressure from MySQL. Done badly, it becomes a single point of failure that takes the whole store down when it fills up. This guide covers the configuration we deploy on production stores.

The Three Things Redis Should Hold

Magento 2 uses Redis for three distinct workloads, and they should be separated:

1. Default cache - config, layout, block HTML and translations
2. Page cache - only if you are not using Varnish
3. Sessions - customer and admin sessions

Separating them matters because their eviction and persistence needs are different. Sessions must survive a Redis restart; cache entries can be dropped freely.

A Sensible env.php Layout

'cache' => [
    'frontend' => [
        'default' => [
            'backend' => 'Magento\\Framework\\Cache\\Backend\\Redis',
            'backend_options' => [
                'server' => '127.0.0.1',
                'port' => '6379',
                'database' => '0',
                'compress_data' => '1',
            ],
        ],
    ],
],
'session' => [
    'save' => 'redis',
    'redis' => [
        'host' => '127.0.0.1',
        'port' => '6379',
        'database' => '1',
        'compression_threshold' => '2048',
        'compression_library' => 'snappy',
        'max_concurrency' => '6',
        'break_after_frontend' => '5',
    ],
],

Note the different database numbers. If you also put the page cache in Redis, give it database 2.

Eviction Policy and Memory

The most common production incident we see is Redis running out of memory and either refusing writes or evicting sessions, logging every customer out. Prevent it explicitly:

maxmemory 2gb
maxmemory-policy allkeys-lru

Apply allkeys-lru to the cache instance. For the session instance, prefer volatile-lru with explicit TTLs so idle session keys are evicted first, never active ones. On larger stores, run two separate Redis processes or use Redis replicas so a cache flush never blocks session writes.

Compression Matters

Magento cache entries compress extremely well. Enabling compress_data typically cuts Redis memory use by 60 to 80 percent at a negligible CPU cost. For sessions, use snappy or lzf rather than gzip; sessions are written on every request, so compression speed matters more than ratio.

Persistence Trade-offs

For the cache databases, disable RDB and AOF entirely - a cache can always be rebuilt, and persistence just adds latency. For sessions, enable AOF with appendfsync everysec so a Redis restart loses at most a second of session writes.

Health Checks

• Watch used_memory, evicted_keys and connected_clients in your monitoring. Non-zero evicted_keys on the session database is an alarm, not a curiosity.
• After any Magento upgrade, flush the cache databases rather than relying on versioned keys.

With Redis configured this way, Magento’s cache reads stay sub-millisecond, sessions survive restarts, and MySQL is left to do the work only it can do. It is one of the highest-leverage hours you can spend on a Magento 2 infrastructure.