Redis End of Life: Supported Versions and EOL Dates

Redis end of life depends on which Redis you run. For Redis Open Source, Redis 6.2 reaches end of life on 1 April 2027, Redis 8.0 on 1 December 2026, and Redis 7.2 and 7.4 on 1 December 2029. Anything older than 6.2, including Redis 5 and 6.0, is already out of support. Redis Software (the enterprise product) and the cloud services each keep their own schedule. The dates below are from Redis's published version and product lifecycle pages, checked on 21 September 2026.

Redis Open Source: supported versions and EOL dates

Redis uses MAJOR.MINOR.PATCH versioning and two kinds of release. A standard release gets security updates and critical bug fixes for six months after the next minor version ships. An extended release, which is the second minor release of a major version and the last minor release of the series, gets them for five years from its release date. That is the closest thing Redis has to long-term support.

Source: Redis Open Source version management. Two practical readings. If you are on Redis 6.2, you have until April 2027 and should be planning now, because you cannot upgrade directly across every major version without testing client and module compatibility. If you are on Redis 8.0, the support date is closer than it looks: it is a standard release, so move to 8.2 or later.

Redis Software (Redis Enterprise) end-of-life schedule

For Redis Software cluster versions 6.2 and later, the EOL policy is that each major release reaches end of life 24 months after the formal release of the subsequent major version, which gives a lead time of at least 24 months to upgrade to the new release. Monthly maintenance is provided on the last minor release of each major1.major2 series.

Source: Redis Software product lifecycle. Redis Software 7.2 and everything before it have reached end of life, and 7.4 follows on 30 November 2026.

Managed Redis: the cloud providers keep their own dates

Redis Cloud, Amazon ElastiCache, Google Memorystore and Azure each publish a separate list of supported versions, and the provider, not you, decides when an engine version is retired. The biggest change is on Azure: Microsoft is retiring Azure Cache for Redis. Enterprise and Enterprise Flash tiers are retired on 31 March 2027, and Basic, Standard and Premium caches must be migrated to Azure Managed Redis by 30 September 2028, after which remaining instances are disabled.

What happens when a Redis version reaches end of life

Nothing stops. The server keeps running, which is exactly why estates drift past the date. What ends is the supply of security updates and bug fixes. From then on every new Redis CVE stays open on your version, auditors record unsupported software as a finding, and any incident starts with the advice to upgrade first. Client libraries and modules also move on, so the longer you wait the wider the gap you have to cross.

Your options for a Redis version past EOL

• Upgrade to a supported extended release. For most estates that means 7.2, 7.4 or 8.2. Test client libraries, Lua scripts, persistence format and any modules before production.
• Move to Valkey. The Linux Foundation fork is a realistic path for teams affected by the Redis licence change; see the Redis to Valkey decision.
• Stay where you are, with support. If a certified application or a change freeze blocks the upgrade, independent support keeps the estate covered while you plan. AceMQ provides 24/7 Redis support for the version you actually run, with a 15-minute emergency SLA, and plans the upgrade with you.

Whichever you choose, start with an inventory: run INFO server on every instance and record redis_version. Most teams find more versions in production than they expected. A Redis health check covers this along with persistence, memory and failover.

How to upgrade off an end-of-life Redis version

Redis upgrades are easier than most databases, which is one reason there is little excuse to stay on an unsupported version. The standard approach avoids downtime. Add a replica running the new version, let it synchronise, then fail over to it and retire the old primary. With Sentinel the failover is one command. With Redis Cluster the same is done shard by shard, replicas first. Data files are forward compatible, so a newer Redis reads an older RDB file, but not the reverse, which means rollback needs a plan that does not depend on the new data file.

What breaks is usually at the edges. Client libraries old enough to predate RESP3 or ACLs may need updating. Lua scripts that relied on undeclared keys or on behaviour changed in Redis 7 need testing. Configuration directives are renamed or removed between majors, and a config file carried forward for years will contain some of them. Modules have their own version requirements, and from Redis 8 several former modules are part of the core distribution.

Licensing is the other decision hidden inside the upgrade. Redis moved from BSD to source-available licences at 7.4 and added AGPLv3 as an option from Redis 8. Valkey continues from Redis 7.2 under the BSD licence, and the cloud providers have largely standardised on it. For most self-managed users the licences change nothing in practice, but it is a question your legal team should answer once, before you pick the target version. Whichever you choose, Redis support that covers both Redis and Valkey keeps the decision reversible.