Redis Support Lifecycle & Release History

How Does Redis Handle Version Support?

Redis does not use a fixed EOL calendar. Instead, support is determined by the introduction of new releases -- when a new stable version ships, older versions move down the support ladder automatically. The latest stable release always receives full active support. The official list of currently supported versions is maintained on the Redis Security Policy page.

Beyond the latest stable release, Redis provides maintenance-only support to two additional versions. Maintenance means only critical bug fixes and major security patches -- no new features, no performance improvements. Everything older than those three tiers receives nothing.

Redis generally ships a new major version once per year, followed by a minor release roughly six months later. This cadence means the support window for any given release is predictable in pattern, even without fixed EOL dates. For security backporting, the Redis team generally ports fixes to a single previous major version -- though they reserve the right to skip backports when the effort is not feasible.

A Note on Licensing

Starting with the releases shown in the table above, open source Redis is no longer uniformly BSD-licensed. Versions from 7.4 onward are dual-licensed under RSALv2 or SSPLv1, and releases from 8.0 onward add AGPLv3 as a third option. This matters operationally -- teams that embed Redis or offer it as a managed service need to verify their license compliance as they upgrade. Earlier versions remain under BSD.

What Can Go Wrong Running an Unsupported Redis Version?

Running an unsupported Redis version means your cache and session store stop receiving security patches. Redis instances are frequently exposed on internal networks with minimal authentication -- a known CVE in an unpatched version can become a direct path to remote code execution or data exfiltration.

In practice, the risk is not just theoretical. The 2024 Lua scripting vulnerability (CVE-2024-46981) demonstrated exactly this pattern: an authenticated attacker could manipulate the garbage collector to achieve arbitrary code execution. Fixes were released only for supported versions. Clusters still on unsupported releases had no official patch path.

Beyond security, there are compatibility concerns specific to Redis's in-memory model. Older versions may not support newer data types -- VectorSets, JSON, TimeSeries -- that are bundled into Redis 8 and above. Applications built against the current command set will silently fail or return errors when connected to an old server. Pipeline and cluster behavior also differs across major versions in ways that do not always surface until production load.

What Actually Happens When Redis Drops Support for a Version?

When a Redis version falls off the supported list, the core team stops testing against it and stops accepting bug reports or pull requests targeting it. There are no announcements, no deprecation warnings in the server itself -- the version simply disappears from the security policy page.

Security advisories published after that point will not include that version in the affected or fixed ranges. If you report a vulnerability affecting your running version and it is unsupported, the team will close the report without action. The fix will exist -- but only for supported releases.

One nuance worth knowing: for security patches released under the newer Redis Open Source license (7.4 and later), users of older BSD-licensed versions (7.2 and earlier) may access patch code under BSD3 terms via REDISCONTRIBUTIONS.txt. This is a licensing concession, not a support commitment -- the patches are not tested or validated for older versions, and portability is not guaranteed.

Most teams running Redis in production via a managed cloud provider (AWS ElastiCache, Azure Cache, GCP Memorystore) will find that the provider EOLs their version first. That timeline is independent of -- and often shorter than -- the upstream Redis project's own support window.

How To Check Your Redis Version

The fastest way is to run the INFO server command, which outputs full server metadata including the version string.

redis-cli INFO server | grep redis_version

If you only need the version and nothing else, pass --version directly to the server binary:

redis-server --version

From within an application, use the INFO command via your client library and parse the redis_version field from the response. Most Redis clients expose this through a dedicated server info method. For example, in Java with Jedis:

RedisClient client = new RedisClient("redis://localhost:6379");
String info = client.info("server");
// parse redis_version from info string

Cross-reference the version you find against the Redis Security Policy page to confirm whether your version is currently receiving patches. Versions not listed there are unsupported.