RabbitMQ Release History & EOL Status

How Does RabbitMQ Handle Version Support?

RabbitMQ follows a rolling minor-version support model under Broadcom/VMware Tanzu stewardship. Each minor release series receives community support until the next minor series reaches general availability, at which point the older series transitions to commercial-only support for teams holding a valid Tanzu license.

There are two distinct support tiers worth knowing:

Community support windows are relatively short -- often just months after the next minor drops. Commercial support extends significantly longer, as shown in the release table above. If your team runs RabbitMQ in production without a Tanzu license, plan your upgrade cadence around the End of Community Support date, not the commercial one.

Official lifecycle dates are published on the RabbitMQ Release Information page and the Broadcom Support Portal. The commercial dates on the Broadcom portal are the authoritative source for Tanzu customers.

What Can Go Wrong When Your RabbitMQ Version Loses Support?

Running an unsupported RabbitMQ broker creates message-delivery risk, not just security risk. The broker sits between every producer and consumer in your system -- when it breaks, everything stops.

Protocol and Client Library Drift

RabbitMQ client libraries -- for Java, Python, Go, .NET -- evolve alongside the broker. Newer client versions often introduce AMQP 0-9-1 or AMQP 1.0 feature flags, connection recovery improvements, and OAuth 2 authentication changes that older broker versions do not support. Teams end up pinning client library versions to match the old broker, which then blocks unrelated dependency upgrades across the entire service.

Unpatched CVEs in the Broker and Erlang/OTP Layer

RabbitMQ runs on Erlang/OTP. Vulnerabilities in Erlang itself -- TLS stacks, distribution protocol, the epmd daemon -- flow through to every unsupported broker version. The RabbitMQ team will not backport CVE fixes to end-of-life series. You are on your own to patch, and patching Erlang without also upgrading RabbitMQ is often not sufficient.

Plugin Incompatibility

The management plugin, shovel, federation, and community plugins are versioned against the broker. As shown in the release table above, each series ships its own plugin set. An unsupported broker version will eventually be incompatible with the plugin releases your monitoring or observability tooling expects -- leading to silent metric gaps or dashboard failures.

Quorum Queue and Stream Behaviour Gaps

Quorum queues and RabbitMQ Streams received significant correctness fixes across recent minor series. Running an older, unsupported version means you may be hitting already-fixed bugs around leader election, consumer offset tracking, or replication lag that the team has no incentive to investigate on your behalf.

What Actually Happens After a RabbitMQ Series Reaches End of Community Support?

The broker keeps running -- RabbitMQ does not self-destruct -- but the support safety net disappears. Here is what changes in practice:

For teams with a Tanzu commercial license, the End of Commercial Support date (shown in the release table above) is the more relevant deadline -- Broadcom continues to issue patches for those series under contract. Without that license, the community EOL date is the line you should not cross.

In practice, most teams discover end-of-support the hard way: a new Kubernetes node image ships with a newer glibc, the old Erlang build refuses to start, and there is no patch available. Upgrading RabbitMQ under incident pressure is significantly harder than doing it on a planned maintenance window.

How To Check Your RabbitMQ Version

There are several ways to check which RabbitMQ and Erlang versions are running, depending on what access you have.

Via the Management UI

Open the management console (default port 15672), log in, and look at the bottom of the Overview tab. RabbitMQ version and Erlang/OTP version are both displayed there.

Via rabbitmqctl

rabbitmqctl status

Look for the RabbitMQ and Erlang lines in the output. This works even when the management plugin is disabled.

Via the HTTP API

curl -s -u guest:guest http://localhost:15672/api/overview | python3 -m json.tool | grep rabbitmq_version

Useful for scripting health checks or automating version audits across multiple nodes. The /api/overview endpoint returns rabbitmq_version and erlang_version in the JSON response.

Via Docker

docker exec <container_name> rabbitmqctl status | grep -E "RabbitMQ|Erlang"

Check the installed package

# Debian/Ubuntu
dpkg -l rabbitmq-server

# RHEL/CentOS/Rocky
rpm -q rabbitmq-server

Cross-reference the version you find against the release table above to determine your current support status. Pay attention to both the RabbitMQ version and the Erlang version -- an unsupported Erlang can be just as problematic as an unsupported broker.