Only the current RabbitMQ release series receives community patches. The 3.x line has reached end of life, and the 4.x major version is where security work now happens. A broker past its EOL date keeps running — nothing breaks on the day support ends — but every CVE published afterwards is one you carry unpatched.
If you are still on 3.13 or older, this covers which versions are supported, what the risk actually is, and the three ways out.
Which RabbitMQ versions are supported
| Series | Status | Notes |
|---|---|---|
| 4.3 | Current | Active development and security work; latest patch is the 4.3.4 line |
| 4.2 | Supported | Recent series |
| 4.1 | Supported | Common upgrade target from 3.13 |
| 4.0 | Older 4.x | Removed classic queue mirroring |
| 3.13 | End of life | Last of the 3.x line |
| 3.12 and older | Past EOL | Community patches ended earlier; 3.9 and 3.8 long gone |
An exact EOL date shifts, so check the official release notes and version support page rather than trusting any third-party table — including this one — for a compliance decision. The pattern is stable even when the dates move: community support follows the current series, and everything behind it is on its own.
When Each Series Reaches RabbitMQ End of Life
RabbitMQ does not run fixed calendar support windows the way some enterprise software does. A series stops receiving community patches when newer ones supersede it, so your end date depends on release cadence rather than a date you were given at purchase.
Two consequences. You cannot plan an upgrade five years out — you plan continuously. And the move from supported to unsupported is quieter than a vendor EOL announcement, so estates drift into unsupported territory without anyone filing a ticket.
What is the latest RabbitMQ version?
The 4.3 series is current as of 2026, having superseded the 2025 releases, with 4.2, 4.1 and 4.0 behind it in the same major line. The project publishes release notes and ships patches within each series frequently, and the source lives on GitHub, so "on 4.1" is not the same as "patched" — you still need the latest patch release of whichever version you run.
Is RabbitMQ owned by VMware?
Not any more. RabbitMQ began at Rabbit Technologies in 2007, passed through SpringSource, VMware and Pivotal, and now sits with Broadcom following that acquisition. The name is simply Rabbit plus MQ, for message queue — it is not an acronym.
Broadcom maintains the open source project and sells the commercial distribution, Tanzu RabbitMQ. The ownership history matters for one reason: commercial support terms have changed hands repeatedly, and what your organisation bought years ago may not resemble what is available in 2026.
Risks of Running Past RabbitMQ End of Life
Nothing fails immediately. The exposure compounds instead:
- Security advisories accumulate. Each CVE affecting your version stays open unless you backport it yourself. This is the one auditors care about.
- Compliance breaks. Regulated environments require a supported version with a documented patch path. "It still works" does not satisfy that.
- Incident response degrades. When something breaks at 2am, community answers start with "upgrade first".
- The upgrade gets more expensive. Every series you fall behind adds a hop, and crossing the major version boundary is where the real work sits.
Erlang version requirements
RabbitMQ runs on the Erlang VM, and each series requires a supported OTP range. When that runtime reaches its end of support, everything on it inherits the exposure — including a deployment whose own release looks current.
Erlang 26 reaching end of support is the forcing function currently pushing teams to RabbitMQ 4.1 and later. We have been distributing Erlang 27 binaries to customers alongside their upgrades for exactly that reason.
The question is never only "is my release supported". It is also "is the runtime underneath it supported". Check both before planning anything.
Breaking changes in the newer major version
The newer line removed things older deployments depend on, which is why this is a project rather than a version bump:
- Classic queue mirroring was removed in 4.0. Mirrored-queue redundancy no longer exists; every affected classic queue has to move to a quorum queue instead. Running RabbitMQ on the older queue type is the single biggest blocker teams hit. See classic and quorum queues for what that involves.
- Quorum queues gained a default delivery limit of 20. Messages that previously redelivered indefinitely now stop, changing behaviour for anything relying on infinite retry.
- Erlang requirements moved, so the runtime upgrade usually has to happen first.
- Khepri replaced Mnesia as the metadata store, changing how cluster state is held.
- Client libraries may need updating alongside the broker, and AMQP 1.0 support has matured since the older line.
- Deprecated features were removed outright, not merely flagged.
These are breaking changes, not deprecations. Meeting them during a maintenance window is the common failure mode.
Your Three Options at RabbitMQ End of Life
1. Upgrade to a supported series
The right answer where it is available. Roll through the cluster one node at a time so it keeps serving, and step through patch releases rather than jumping the whole gap — we routinely take customers from 3.13.10 to 3.13.15 to 3.13.18 to clear known vulnerabilities before attempting the move to 4.x.
Rehearse it outside production first, and watch the RabbitMQ management UI through the process — version upgrades are where queue type mismatches surface. Detail in upgrading RabbitMQ 3.x to 4.x without downtime.
2. Take extended commercial support on your current version
Sometimes the upgrade genuinely is not available this quarter — a frozen change window, a certified application, an air-gapped estate, or a vendor who has not qualified the new release.
Extended support beyond 3.12.x exists for that: security patches backported to the version you actually run, so the deployment stays compliant while you plan properly. It converts an open-ended risk into a managed one, which is usually what the auditor wants to see. End of commercial support dates are worth confirming in writing as part of that support lifecycle. Commercial support on an unsupported version is a bridge, not a destination.
3. Re-platform
Occasionally the honest answer is that the fit was wrong and this is a sensible moment to reconsider. Rare — most teams should upgrade — but worth naming rather than pretending.
What not to do
Do not freeze and hope. A stale deployment under critical queues is an unbounded liability.
Do not upgrade blind across the major boundary. Removed features surface during the window, which is the worst time to meet them.
Do not treat it as only a version number. Check Erlang, client libraries, the management plugin, and third-party plugins. A plugin built against an older broker refuses to load and rarely names itself in the error.
Running an end-of-life RabbitMQ and unsure which option applies? AceMQ provides
RabbitMQ support for legacy versions — security patching for out-of-support releases,
upgrade planning for clusters you cannot take offline, 24/7 escalation, and optimization work while you get current.
FAQ
Which RabbitMQ versions are currently supported?
The 4.x series, with 4.3 current as of 2026. The 3.x line including 3.13 has reached end of life. Check the official release information page for exact dates before making a compliance decision.
When did the older series reach end of life?
The 3.13 release was the last of that line and community patches for it have ended. RabbitMQ does not publish fixed multi-year support windows, so the end follows release cadence rather than a calendar commitment.
Is it safe to run a version past its EOL date?
Only with a patch path. Either take commercial support that backports security fixes to your version, or upgrade. The risk is an accumulating set of unpatched CVEs rather than an immediate failure.
What is the latest RabbitMQ version?
The 4.3 series is current. Within any series you also need the latest patch release — running 4.1 without its patches is not the same as being up to date.
Is RabbitMQ owned by VMware?
No. Ownership moved to Broadcom through that acquisition. Broadcom maintains the project and sells Tanzu RabbitMQ commercially.
How old is RabbitMQ?
It first shipped in 2007 from Rabbit Technologies, making it one of the longer-established message queue systems still in active development.
What are the Erlang version requirements?
Each series specifies its own supported OTP range, and they move with the release line. Erlang 26 reaching end of support is currently pushing teams to RabbitMQ 4.1 and later with Erlang 27. Check the compatibility matrix before scheduling an upgrade.
What breaks during major version upgrades?
Classic queue mirroring was removed in 4.0, so mirrored-queue high availability must move to quorum queues. Quorum queues also gained a default delivery limit of 20, changing redelivery behaviour. Erlang requirements usually shift as well.
