How to Set Up Redis and Valkey Caching for Magento 2

Read This First: Redis or Valkey?

If you are setting up Magento cache in 2026, the first decision is no longer how to configure Redis. It is whether you should be using Redis at all.

Adobe's own documentation now states that Redis cache is not supported on Adobe Commerce 2.4.9, nor on patch releases later than 2.4.5-p16, 2.4.6-p14, 2.4.7-p9, and 2.4.8-p4. On those versions the supported path is Valkey, and from 2.4.9-alpha2 onward Valkey officially replaced Redis in Magento's CLI tooling.

So the honest guidance splits by version:

One caution before you plan around those exact patch numbers: Adobe's Redis page says the cutoff is "later than 2.4.8-p5" while the Valkey page says "later than 2.4.8-p4". Their own docs disagree by one patch. Check your specific version against both pages rather than trusting either number, or ours.

This guide covers both. The mechanics are nearly identical, which is the whole point of Valkey.

Why Valkey Exists at All

This is licensing history, not technology, and it explains why your cache layer changed name without changing behaviour.

• March 2024: Redis dropped the BSD licence. Redis 7.4 and later moved to a dual SSPLv1 and RSALv2 model, which the Open Source Initiative does not recognise as open source.
• April 2024: The Linux Foundation launched Valkey, forked from Redis 7.2.4, the last BSD-licensed release, backed by AWS, Google Cloud, and Oracle.
• May 2025: Redis 8.0 added AGPLv3 as a third option, a partial reversal. Redis now ships under a tri-licence: AGPLv3, SSPLv1, or RSALv2.

Now look again at Magento 2.4.8's supported versions: Valkey 8 or Redis 7.2. Not Redis 7.4, not Redis 8. Adobe pinned to the last permissively licensed Redis release and then moved to the fork. That is not a coincidence, it is the licence change showing up in your env.php.

Practically: Valkey 8 is a drop-in for Redis 7.2. Same protocol, same clients, same redis-cli muscle memory (Valkey ships valkey-cli and keeps compatibility). Existing Redis installs keep working on supported versions. You are not rearchitecting anything.

What This Actually Buys You

Out of the box Magento stores cache on the filesystem and sessions in MySQL. Both become bottlenecks under load, for different reasons:

• Filesystem cache means every cache read is a syscall and a disk seek. On a busy category page that is thousands of small reads per request.
• Database sessions put write traffic on the same MySQL instance serving your catalogue queries, and session locking turns concurrent requests from one shopper into a queue.

Moving both into memory removes disk from the cache path and takes session writes off the database. The database stops being the thing that falls over first during a traffic spike, which is usually the real win, more than the raw latency number.

Prerequisites

• Magento 2.4.8 or 2.4.9 (this guide notes where they differ)
• Ubuntu 22.04 or 24.04, root or sudo access
• PHP 8.3 or 8.4 for Magento 2.4.8 (2.4.9 moves to PHP 8.4 and adds 8.5). Older guides saying PHP 8.2 are describing 2.4.6, which is now past end of support.
• The phpredis PHP extension, which works for both Redis and Valkey

Installing Valkey on Ubuntu

Ubuntu 24.04 ships Valkey in the standard repositories:

sudo apt update
sudo apt install -y valkey-server

sudo systemctl enable --now valkey-server

# Verify
valkey-cli ping
# Expected: PONG

For Redis on an older Magento version, the equivalent is unchanged:

sudo apt update
sudo apt install -y redis-server
sudo systemctl enable --now redis-server
redis-cli ping
# Expected: PONG

Everything from here is identical apart from the service name and the CLI keyword.

Sizing Memory, and the Eviction Policy That Matters

This is the step most guides get wrong by copying a number without explaining it.

# /etc/valkey/valkey.conf  (or /etc/redis/redis.conf)
maxmemory 512mb
maxmemory-policy allkeys-lru

Two things to understand:

maxmemory is not a suggestion. Without it, the cache grows until the kernel OOM killer picks a victim, and on a single-server Magento box that victim is often MySQL or PHP-FPM. Always set it. 512 MB is a reasonable starting point for a small catalogue; large catalogues with heavy full-page cache commonly need 2 GB or more. Size it by watching real usage rather than guessing, see the monitoring section below.

allkeys-lru is the right policy for a cache and the wrong one for sessions. With allkeys-lru, when memory fills, the least recently used key is evicted regardless of type. That is correct for cache entries, which are disposable by definition. It is not correct for sessions, because evicting a session logs a shopper out mid-checkout. This is the strongest argument for running sessions on a separate instance rather than just a separate database number, which we cover below.

Configure Magento: Use the CLI, Not the Editor

Most guides tell you to hand-edit app/etc/env.php. Adobe's documented method is the CLI, and it is better: it validates parameters, writes correct structure, and is repeatable in a deploy script.

For Valkey (2.4.9, or new installs):

# Default cache -> db 0
bin/magento setup:config:set --cache-backend=valkey \
  --cache-backend-valkey-server=127.0.0.1 \
  --cache-backend-valkey-db=0 \
  --cache-backend-valkey-port=6379

# Full-page cache -> db 1
bin/magento setup:config:set --page-cache=valkey \
  --page-cache-valkey-server=127.0.0.1 \
  --page-cache-valkey-db=1 \
  --page-cache-valkey-port=6379

# Sessions -> db 2
bin/magento setup:config:set --session-save=valkey \
  --session-save-valkey-host=127.0.0.1 \
  --session-save-valkey-db=2 \
  --session-save-valkey-port=6379

For Redis (2.4.8 and earlier supported patches), swap the keyword:

bin/magento setup:config:set --cache-backend=redis \
  --cache-backend-redis-server=127.0.0.1 --cache-backend-redis-db=0

bin/magento setup:config:set --page-cache=redis \
  --page-cache-redis-server=127.0.0.1 --page-cache-redis-db=1

bin/magento setup:config:set --session-save=redis \
  --session-save-redis-host=127.0.0.1 --session-save-redis-db=2

Adobe's recommended database assignment is db 0 for default cache, db 1 for page cache, db 2 for sessions. Keeping them separate means bin/magento cache:flush on one type does not blow away the others, and it makes INFO keyspace readable.

The CLI writes this into app/etc/env.php for you. It is worth knowing what it produced:

'cache' => [
    'frontend' => [
        'default' => [
            'backend' => 'Magento\\Framework\\Cache\\Backend\\Redis',
            'backend_options' => [
                'server' => '127.0.0.1',
                'port' => '6379',
                'database' => '0',
                'compress_data' => '1',
            ],
        ],
        'page_cache' => [
            'backend' => 'Magento\\Framework\\Cache\\Backend\\Redis',
            'backend_options' => [
                'server' => '127.0.0.1',
                'port' => '6379',
                'database' => '1',
                'compress_data' => '0',
            ],
        ],
    ],
],

Note compress_data: 1 for default cache, 0 for full-page cache. That asymmetry is deliberate. Default-cache entries (config, layouts) are large and compress well, and they are read less often. Full-page cache entries are served hot on every request, and the CPU spent decompressing on each hit costs more than the RAM it saves. Compress the cold one, not the hot one.

Then flush and confirm:

bin/magento cache:flush
bin/magento cache:status

Sessions Deserve Their Own Instance

The default advice puts sessions in db 2 of the same server. That works, and it is what the commands above do, but understand the tradeoff you just accepted: the eviction policy is global to the instance, not per database. With allkeys-lru and a full instance, Valkey will happily evict a session key to make room for a category page.

For a production store, run two instances:

# Instance 1: cache (db 0, db 1) - eviction is fine here
maxmemory 1gb
maxmemory-policy allkeys-lru

# Instance 2: sessions (port 6380) - eviction is data loss
maxmemory 512mb
maxmemory-policy noeviction
save ""
appendonly no

noeviction on the session instance means it returns an error instead of silently logging shoppers out. An error you can alert on beats a checkout abandonment you cannot explain.

Also note save "" and appendonly no: do not persist a cache to disk. Cache is regenerable by definition, and RDB snapshots on a busy instance cause fork pauses that show up as latency spikes. Sessions are a judgement call; persisting them means surviving a restart without logging everyone out, at the cost of those same fork pauses.

Verify It Is Actually Working

Configuration that looks right and does nothing is the normal failure mode. Check for keys:

# Should show db0, db1, db2 with non-zero key counts
valkey-cli info keyspace

# Watch cache writes land in real time (Ctrl+C to stop)
valkey-cli monitor

monitor is a debugging tool, not a production one. It streams every command and costs real throughput on a busy instance. Use it to confirm the wiring, then get out.

The number that tells you if your sizing is right:

valkey-cli info stats | grep evicted_keys
valkey-cli info memory | grep -E 'used_memory_human|maxmemory_human'

evicted_keys climbing steadily means maxmemory is too low. Your cache is thrashing: entries get evicted before they are reused, so you pay the cost of caching without the benefit. A small, stable eviction count is fine. A number that grows every minute means give it more RAM.

Hit rate is the other half:

valkey-cli info stats | grep -E 'keyspace_hits|keyspace_misses'

Compute hits / (hits + misses). A healthy Magento full-page cache sits high, well above 80 percent, once warm. A low ratio usually means either the cache is being flushed too often (a deploy or a cron job doing cache:flush) or it is too small and evicting.

Troubleshooting the Usual Suspects

Nothing appears in the keyspace. The config did not take. Confirm with bin/magento setup:config:set output and check app/etc/env.php actually contains the block. Then flush.

Site works, but the cache never seems to hit. Check whether something is flushing on every deploy or cron run. Also confirm full-page cache is actually enabled in Magento, not just pointed at Valkey.

Shoppers randomly logged out. Classic eviction-of-sessions symptom. Check evicted_keys and whether sessions share an instance with allkeys-lru. Split them.

Redis works locally but Magento 2.4.9 rejects the config. Expected. That is the version cutoff described at the top. Move to Valkey.

Latency spikes every few minutes. Look for RDB snapshots (save directives) on a cache instance. Turn persistence off for cache.

For more on storefront speed beyond the cache layer, read our guide on boosting Magento 2 performance. If you would rather have this reviewed and tuned against your real traffic, that is what our Magento 2 speed optimization work does.

The Short Version

Move cache and sessions into memory, but do it with the version-correct tool: Valkey for 2.4.9 and new installs, Redis only if you are on 2.4.8 or an earlier supported patch. Set maxmemory and never skip it. Compress the default cache, not the full-page cache. Give sessions their own instance with noeviction. Then watch evicted_keys and your hit ratio, because those two numbers tell you whether the cache is doing its job or just occupying RAM.

Sources

• Adobe Commerce: configure Valkey for default and page cache
• Adobe Commerce: configure Valkey for session storage
• Adobe Commerce: configure Redis for default and page cache
• Adobe Commerce: best practices for Valkey and Redis service configuration
• Redis: now available under the AGPLv3 licence
• Valkey project