Adobe Commerce is ending Redis support for cache and sessions, and Valkey is the replacement. On Magento 2.4.9, and on any patch level past 2.4.8-p4, Redis for cache is no longer supported. Valkey is a protocol-compatible fork you can adopt without code changes, but the migration has version-specific configuration and one file-copy trap that quietly breaks stores.
Most guides treat this as an optional performance tweak. It is not. For anyone staying current on security patches, this is a forced migration with a real deadline. This is how we handle it on Magento and Adobe Commerce development work, including the version-specific env.php and the failure modes the quick tutorials skip.
Why Valkey, and why now
Two separate things happened, and it helps to keep them straight.
In March 2024, Redis Ltd. relicensed Redis starting at version 7.4 away from the permissive BSD-3-Clause license to dual source-available licenses (RSALv2 and SSPLv1), per Redis’s own licensing announcement. The stated aim was to force large cloud providers into commercial agreements. In response, the Linux Foundation forked the last BSD version, Redis 7.2.4, into Valkey, which stays BSD-3-Clause and is governed as an open project. Redis Ltd. later added an AGPLv3 option with Redis 8.0 in 2025, a partial walk-back, so the licensing story is still moving.
For a self-hosted store running Redis internally, the license change is rarely a legal problem on its own. The urgency comes from the second thing: Adobe stopped supporting Redis for cache in current Magento releases and now recommends Valkey. When your own platform vendor drops support, the calendar decides for you.
The migration deadline: which versions still allow Redis
This is the fact to lead with, because it turns a “someday” into a “before your next patch.”
Per Adobe’s Redis and Valkey service configuration guidance, Redis cache is not supported for Adobe Commerce 2.4.9, or for patch releases later than the levels below. Past those patches, you must use Valkey.
| Magento / Adobe Commerce line | Last patch that supports Redis cache |
|---|---|
| 2.4.5 | 2.4.5-p16 |
| 2.4.6 | 2.4.6-p14 |
| 2.4.7 | 2.4.7-p9 |
| 2.4.8 | 2.4.8-p4 |
| 2.4.9 and later | Not supported (Valkey only) |
The practical read: if you apply a security patch that lands above one of these levels, or you upgrade to 2.4.9, Redis for cache stops being a supported path in the same maintenance window. Teams that treat the Valkey switch as separate from patching end up doing an emergency migration under a deploy freeze. Plan it into the same Magento 2.4.8 or 2.4.9 upgrade work instead.
Valkey is protocol-compatible, but “drop-in” has caveats
Valkey speaks the same RESP protocol as Redis, so the clients Magento uses connect unmodified. The phpredis PHP extension and the Cm_RedisSession session library both talk to Valkey without changes, and there are no Magento application code changes to make. That part of the “drop-in” claim is true.
The caveats are in three places the fast tutorials gloss over:
- The
env.phpbackend class is version-specific. On 2.4.8 and earlier, the cache backend is referenced with a Zend-style class name. On 2.4.9 and later, it is a shortvalkeyalias under the Symfony cache layer. Copy the wrong one for your version and deployment throws. - Redis takes priority if both are present. If you leave Redis installed and running, you must explicitly select Valkey, or the switch can appear to do nothing.
- The L2 (second-level) cache backend changed between 2.4.8 and 2.4.9 (covered below).
The RDB 7.4 trap that breaks migrations
This is the single most common way a Valkey migration goes wrong, and almost nobody leads with it.
The obvious migration is “stop Redis, install Valkey, copy dump.rdb across, start Valkey.” That works only if your Redis is on 7.2. Redis 7.4 and later write an RDB snapshot format that Valkey will not load. If you copy a 7.4-era dump.rdb into Valkey, it fails to start or comes up empty, and if that instance held sessions, everyone is logged out.
So the first command in any migration is a version check:
redis-cli INFO server | grep redis_version
If it reports 7.2.x, a file copy is on the table. If it reports 7.4 or higher, you must migrate by replication instead of copying files. For cache data this matters less, since cache is disposable and can be flushed and rebuilt, but for sessions a bad copy is a customer-facing outage.
Configuring cache in env.php
Cache and full page cache should live in separate Valkey databases. The common convention is database 0 for the default cache, database 1 for the page cache, and database 2 for sessions, so a flush of one does not disturb the others. Adobe’s Valkey page cache configuration documents the current keys.
On 2.4.9 and later, the cache block uses the valkey alias:
'cache' => [
'frontend' => [
'default' => [
'backend' => 'valkey',
'backend_options' => ['server' => '127.0.0.1', 'port' => '6379', 'database' => '0'],
],
'page_cache' => [
'backend' => 'valkey',
'backend_options' => ['server' => '127.0.0.1', 'port' => '6379', 'database' => '1', 'compress_data' => '0'],
],
],
],
On 2.4.8 and earlier, keep the same options but reference the Zend-style class Magento\Framework\Cache\Backend\Valkey as the backend value instead of the valkey alias. That one-line difference is version-specific and is where copied-from-a-blog config fails.
The CLI equivalents on 2.4.9 are:
bin/magento setup:config:set --cache-backend=valkey --cache-backend-valkey-server=127.0.0.1 --cache-backend-valkey-db=0
bin/magento setup:config:set --page-cache=valkey --page-cache-valkey-server=127.0.0.1 --page-cache-valkey-db=1
On 2.4.8 and earlier, substitute redis for valkey in the flag names, since the older CLI still uses the Redis flag family even when pointed at a Valkey server.
Configuring sessions, and the key that trips people up
Sessions carry the gotcha worth a warning. On 2.4.9, the outer key that selects the handler is valkey, but the inner configuration array is still named redis:
'session' => [
'save' => 'valkey',
'redis' => [
'host' => '127.0.0.1',
'port' => '6379',
'database' => '2',
'disable_locking' => '1',
'max_concurrency' => '20',
'min_lifetime' => '60',
'max_lifetime' => '2592000',
],
],
It looks like a mistake and invites a “fix” that breaks sessions silently. Leave the inner key as redis. Adobe documents the exact block in the Valkey session configuration guide. The session locking settings deserve attention too: a store with heavy AJAX or a fast Hyva frontend firing several private-content requests at once can deadlock on session locks if max_concurrency is too low, which is one reason the Hyva storefront makes session tuning more visible than a slow Luma theme did.
The L2 cache backend change
Adobe Commerce runs a two-level cache: a fast local L1 and a shared L2 in Redis or Valkey. The L2 backend class changed by version. On 2.4.8 and earlier it is RemoteSynchronizedCache. On 2.4.9 and later it becomes symfony_l2, which requires ECE Tools v2002.2.13 or newer on Cloud. Point a 2.4.7 patch level at the 2.4.9 L2 backend and deployment errors follow. Match the L2 backend to your exact version, not to the newest tutorial you found.
Migration paths by hosting model
There is no single procedure, because the right one depends on your Redis version and where you host.
| Path | When to use | Method |
|---|---|---|
| A: drop-in file copy | Redis 7.2, self-hosted, short maintenance window acceptable | Stop Redis, copy dump.rdb, start Valkey on the same port |
| B: replication cutover | Redis 7.4+, or you need near-zero downtime | Run Valkey as a replica on a second port, verify sync, promote, repoint Magento |
| C: Adobe Commerce Cloud | PaaS / cloud infrastructure | Set the service type in .magento/services.yaml and the backend in .magento.env.yaml |
For Path B, the shape is: install Valkey on port 6380, run valkey-cli -p 6380 REPLICAOF 127.0.0.1 6379, confirm master_link_status:up, then in a maintenance window run REPLICAOF NO ONE and repoint Magento to 6380. For Path C, the service type becomes valkey:8.0 and the L2 backend is set through the Cloud environment variables rather than env.php directly.
A safe cutover and rollback runbook
The migration itself is minutes of work. The safety is in the preparation and the exit plan.
Pre-flight: back up env.php to a timestamped copy, run redis-cli BGSAVE and copy the resulting dump.rdb, confirm your Redis version, and note your exact Magento version so you use the right cache class and L2 backend.
Cutover (drop-in example): enable maintenance mode, bin/magento cache:flush, stop Redis, install and start Valkey, move the data if you are on 7.2, verify keys with valkey-cli INFO keyspace, update env.php, run bin/magento setup:upgrade and bin/magento cache:flush, then disable maintenance mode. Smoke-test the two things sessions touch: add to cart as a guest, and log in to the admin, which exercises session locking.
Rollback (five to ten minutes): stop Valkey, restore the Redis dump.rdb and start Redis, restore the env.php backup, flush cache, and disable maintenance mode. Keep Redis installed but stopped through the rollback window rather than uninstalling it the same day. Getting cron and indexers healthy before and after is part of the same discipline we describe in Adobe Commerce cron and indexer health, because a broken queue after a cutover looks like a cache problem and is not.
Performance: what to actually expect
Valkey’s public benchmarks are strong. The Valkey project reports roughly 37 percent higher SET throughput and lower tail latencies against a comparable Redis build on multi-core cloud instances, driven by Valkey’s multi-threaded I/O versus Redis’s single-threaded model. Treat those as Valkey project benchmarks rather than an independent result, and expect the real-world gain on a Magento store to depend on how concurrent your PHP-FPM worker pool is. The honest framing for a store owner: you are migrating because support requires it, and the performance is a genuine bonus, not the reason. If page speed is the actual goal, the bigger levers are server-level time to first byte work and full page cache and Varnish configuration on Hyva.
FAQ
Is Valkey a safe replacement for Redis on Magento?
Yes. Valkey is a Linux Foundation fork of Redis 7.2.4 and speaks the same protocol, so phpredis and the Magento session library connect without changes, and there are no application code edits. Adobe recommends Valkey for cache and sessions on current releases.
Do I have to migrate off Redis?
If you stay on security patches, effectively yes. Redis cache is unsupported on Adobe Commerce 2.4.9 and on patch levels past 2.4.5-p16, 2.4.6-p14, 2.4.7-p9, and 2.4.8-p4. You can delay only by staying below those patches, which trades a supported cache backend for missing security fixes.
Can I just copy my Redis dump file into Valkey?
Only if your Redis is version 7.2. Redis 7.4 and later write an RDB format Valkey will not load. On 7.4 or newer, migrate by replication instead of copying dump.rdb, or you risk an empty instance and logged-out customers.
Will migrating to Valkey speed up my store?
Usually a little, more under high concurrency. Valkey’s own benchmarks show meaningful throughput and latency gains from multi-threaded I/O, but the visible storefront speed win on most Magento stores is smaller than the gains from TTFB and full page cache work. Migrate for support first, performance second.
Does the same migration apply to Adobe Commerce Cloud?
The concepts are identical, but the mechanism differs. On Cloud you set the Valkey service type in .magento/services.yaml and configure the backend through the Cloud environment files rather than editing env.php directly, and the L2 backend follows the version rules above.
Where this fits
Bemeir is a Brooklyn ecommerce agency and the USA’s leading official Hyva partner, with deep Magento and Adobe Commerce experience and a large technology partner ecosystem across hosting, payments, and performance. We also build on Shopify, BigCommerce, and Shopware, so our infrastructure advice is platform-aware rather than one-size-fits-all. If you are planning a patch, an upgrade, or a Valkey cutover and want it done in one clean maintenance window, learn more about how we work or talk to the team at Bemeir.
