Valkey Support Lifecycle & Release History

Valkey Release Cadence and Key/Value Store Support Windows

Valkey follows a dual-phase support model: each minor version receives 3 years of maintenance support, and the latest minor version within each major series receives an extended 5 years of security-only support. This tiered structure gives teams running Valkey as a primary cache or datastore a predictable upgrade runway without forcing annual migrations.

The community ships one stable major version per year, with minor versions introduced as needed -- at least one per year. Patch versions carry only backwards-compatible bug fixes and are safe to apply in rolling restarts across primary-replica pairs or cluster nodes. Minor version upgrades are also safe under default configurations, though new commands or data types introduced in a minor release should not be used until all cluster nodes are on the same minor version.

The minor version designated for extended security support is finalized only after the next major version launches. In practice, this means teams should track the community announcement when a new major ships -- that announcement will confirm which minor version carries the 5-year security tail for the outgoing major series.

Release dates and current end-of-life windows for all active versions are shown in the release table above. For the authoritative policy source, see the official Valkey release and versioning documentation.

Memory Safety and Cluster Integrity Risks on Unpatched Valkey Nodes

Running an unsupported Valkey version in production exposes the data plane directly -- there are no patches coming, and any memory corruption bug, command parsing flaw, or replication protocol weakness stays permanently unaddressed.

Valkey's architecture amplifies the blast radius of unpatched vulnerabilities in specific ways. Because Valkey frequently runs without TLS in internal networks (relying on perimeter security), a remote code execution or denial-of-service CVE in an old release can be exploited without authentication. A single vulnerable node in a cluster can compromise the entire keyspace through replication.

Key risk vectors on unsupported versions

Most teams find the replication consistency risk the hardest to detect -- a partially upgraded cluster can pass basic smoke tests while silently producing stale reads during leader elections. The only safe path is a full cluster upgrade before relying on any new minor-version feature.

Keyspace Freeze: Valkey Node Behavior After Maintenance Support Ends

When a Valkey minor version exits maintenance support, it stops receiving any patches -- no bug fixes, no CVE responses, no backports. The server binary continues to function, but the community treats the version as frozen.

For versions that also lack extended security support, even actively exploited vulnerabilities will not be patched. The TSC only backports security fixes to the designated extended-security minor of each major series. Running any other version past its maintenance window means absorbing 100% of undisclosed and future CVE risk with no remediation path short of upgrading.

What changes operationally after EOL

• No new patch releases -- the version number in the release table above is the final state
• Community support (Slack, GitHub issues) shifts to "please upgrade" responses rather than debugging
• Managed cloud providers (AWS ElastiCache, Google Memorystore, Azure Cache) typically deprecate and force-migrate unsupported engine versions with advance notice -- check your provider's own EOL schedule
• Valkey Module API additions from newer versions are unavailable; modules cannot be updated to use new hooks without upgrading the server

The upgrade path from an EOL version is straightforward in most deployments: patch versions within the same minor series are safe rolling upgrades. Crossing a minor or major version boundary requires reading the release notes and upgrading replicas before primaries. The community's versioning policy guarantees that replication data is always sent in a backwards-compatible format, meaning a newer replica can always sync from an older primary -- which is the safe upgrade sequence.

Querying the Running Valkey Instance: CLI and Server-Side Version Inspection

The fastest way to check a running Valkey node's version is through the valkey-cli command-line tool or the INFO server command sent directly to the server.

Using valkey-cli directly

valkey-cli --version

This returns the version of the CLI binary itself, not the connected server. Always confirm the server version separately.

Query the live server version

valkey-cli -h <host> -p <port> INFO server | grep valkey_version

The output will include a line like valkey_version:9.0.4. This reflects the actual running binary on that node, not what was originally installed.

Check version inside a Docker container

docker exec -it <container_name> valkey-cli INFO server | grep valkey_version

Full INFO server block (useful for cluster audits)

valkey-cli -h <host> INFO server

The full block includes valkey_version, os, arch_bits, tcp_port, and uptime_in_days -- useful when auditing a cluster to confirm all nodes are on the same minor version before enabling a new feature.

In a Valkey Cluster: check all nodes

valkey-cli --cluster check <host>:<port>

Cross-reference the reported versions against the release table above to determine whether each node is still within its maintenance or security support window.