How to move Magento cache and sessions from Redis to Valkey

For years the standard advice for a fast Magento store was simple: put the application cache, the full-page cache and PHP sessions in Redis. That advice has changed. Adobe now lists Valkey, the open-source fork of Redis, as the tested cache service for every supported release line, and from version 2.4.9 the bin/magento tooling itself uses Valkey options instead of Redis ones.

Adobe's 2.4.9 release notes give the reason: Redis 7.2 end of support and Redis licensing changes. Its Valkey documentation adds that Valkey is required for cache configuration on 2.4.9 and on the patch releases later than 2.4.5-p16, 2.4.6-p14, 2.4.7-p9 and 2.4.8-p4. In other words, if you applied the May 2026 security patches, you are expected to be on Valkey.

This tutorial shows how to point the Magento default cache, the page cache and session storage at Valkey on an on-premises installation, how the commands differ between 2.4.9 and 2.4.8, and how to check the result. Adobe Commerce on cloud infrastructure has its own service configuration, which Adobe documents separately.

Which Valkey version you need

Adobe's system requirements (updated 18 September 2026) list these tested versions for the latest patch of each line:

Valkey speaks the same protocol as Redis and Adobe describes it as near-identical in functionality, so PHP clients such as the phpredis extension work with it. Installing Valkey itself is outside the scope of Adobe's guide and of this article; use your operating system's packages or the official Valkey releases, and pin the major version from the table.

If you are still on an older patch, such as 2.4.7-p9 or 2.4.6-p14, Redis 7.2 remains a tested option for that exact patch. Moving to Valkey at the same time as you apply the next security patch keeps the two changes aligned with Adobe's tables and avoids running an untested combination in production.

Plan the layout before you switch

Magento stores three different kinds of data, and each has different needs:

• Default cache (configuration, layouts, blocks). It can be rebuilt at any time, so it needs no persistence. Adobe suggests sizing it from your current var/cache folder: if that folder holds 5 GB, start with at least 5 GB of memory.
• Full-page cache. Also disposable. Many production stores use Varnish for this instead, which Adobe supports (Varnish 8 for current releases).
• Sessions. Losing them signs customers out and empties guest carts, so Adobe recommends persistence: RDB snapshots, an append-only file (AOF), or both.

Adobe gets the best results from a dedicated instance for each of sessions, cache and full-page cache. If you share one instance, the database numbers must differ; Adobe recommends 0 for the default cache, 1 for the page cache and 2 for sessions. The examples below use one local instance with those numbers.

Configure Valkey on Magento 2.4.9

Use setup:config:set rather than editing app/etc/env.php by hand. Adobe recommends the command line because it validates the configuration. Run the commands as the file system owner from the Magento root:

# Default (application) cache in database 0
bin/magento setup:config:set --cache-backend=valkey \
  --cache-backend-valkey-server=127.0.0.1 \
  --cache-backend-valkey-port=6379 \
  --cache-backend-valkey-db=0

# Full-page cache in database 1 (skip if Varnish handles page caching)
bin/magento setup:config:set --page-cache=valkey \
  --page-cache-valkey-server=127.0.0.1 \
  --page-cache-valkey-port=6379 \
  --page-cache-valkey-db=1

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

If Valkey requires a password, add --cache-backend-valkey-password, --page-cache-valkey-password and --session-save-valkey-password. Pass secrets from your deployment tooling rather than typing them into shell history, and remember that env.php then contains the password, so keep it out of version control.

On 2.4.9 the resulting env.php cache section uses the short backend name valkey, because 2.4.9 replaced Zend_Cache with the Symfony Cache component:

'cache' => [
    'frontend' => [
        'default' => [
            'backend' => 'valkey',
            'backend_options' => [
                'server' => '127.0.0.1',
                'database' => '0',
                'port' => '6379'
            ],
        ],
        'page_cache' => [
            'backend' => 'valkey',
            'backend_options' => [
                'server' => '127.0.0.1',
                'port' => '6379',
                'database' => '1',
                'compress_data' => '0'
            ]
        ]
    ]
],

Configure Valkey on 2.4.8 and earlier

Before 2.4.9 there are no valkey options in the CLI. Adobe's session guide explains that the Redis commands stay the same and simply point at a Valkey server, which keeps migration simple. Use the familiar Redis options with your Valkey host and port:

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

These commands write the Magento\Framework\Cache\Backend\Redis backend into env.php. Adobe's Valkey page also shows a Zend-based Magento\Framework\Cache\Backend\Valkey class for 2.4.8 and earlier. When you later upgrade to 2.4.9, rerun the configuration with the valkey options.

Session settings worth knowing

The session handler has many options. These are the ones that most often matter in production, with Adobe's documented defaults:

Sentinel options (session-save-valkey-sentinel-master and session-save-valkey-sentinel-servers) are available for highly available setups.

Tune Valkey and PHP for Magento

Adobe's Redis configuration guide recommends asynchronous deletion settings that do not change behaviour but reduce latency spikes. They apply equally to a Valkey configuration file:

# Asynchronous deletion settings from Adobe's Redis configuration guide
lazyfree-lazy-eviction yes
lazyfree-lazy-expire yes
lazyfree-lazy-server-del yes
replica-lazy-flush yes
lazyfree-lazy-user-del yes

For 2.4.9 stores, Adobe's cache guide recommends the native phpredis extension over the pure-PHP Predis client, and the igbinary serializer when you use Symfony Cache. Install the igbinary PHP extension, then set the serializer in env.php:

'cache' => [
    'frontend' => [
        'default' => [
            'backend_options' => [
                'server' => '127.0.0.1',
                'database' => '0',
                'port' => '6379',
                'serializer' => 'igbinary'
            ]
        ]
    ]
],

Leave the Lua options at their defaults unless you have a specific reason: Adobe documents use_lua as 0 and use_lua_on_gc as 1, and warns that changing them on 2.4.7 or 2.4.8 can cause cache corruption or silently failing tag-based invalidation.

Check that it works

Flush the cache, load a few storefront pages and sign in to the Admin, then confirm that keys appear in the expected databases:

bin/magento cache:flush
bin/magento cache:status
valkey-cli -n 0 dbsize
valkey-cli -n 2 dbsize

The key counts should grow as you browse. If the storefront shows errors, check var/log/exception.log for connection errors, confirm the host, port and password, and make sure the Valkey server is reachable from every web node and from the cron server.

Common mistakes and how to avoid them

Most Valkey problems in Magento come from a handful of configuration choices rather than from Valkey itself. Check this list before you go live and again after every infrastructure change.

Rolling back

Before you switch, copy app/etc/env.php. If the new setup misbehaves, restore the copy and flush the cache; Magento will reconnect to the previous backend. Expect active sessions to be lost when you move session storage in either direction, so schedule the change for a quiet period and tell your support team in advance.

Next steps

Moving to Valkey is now a supported-configuration requirement rather than an optimisation. Install the Valkey major version that matches your release, keep cache, page cache and sessions in separate databases or instances, enable persistence for sessions, and use the valkey CLI options from 2.4.9 onwards. Then add Valkey memory use and evictions to your monitoring, so that you notice before the cache outgrows its instance.