RabbitMQ End of Life Dates by Version, and Your Options on 3.x

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.

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.

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.

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.

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 organization bought years ago may not resemble what is available in 2026.

Nothing fails immediately. The exposure compounds instead:

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.

The newer line removed things older deployments depend on, which is why this is a project rather than a version bump:

These are breaking changes, not deprecations. Meeting them during a maintenance window is the common failure mode.

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.

If the answer is to upgrade, the mechanics — rolling versus blue-green, the required hop sequence, the Erlang dependency and the pre-upgrade checklist — are in upgrading RabbitMQ 3.x to 4.x without downtime. If you would rather not run it yourself, our RabbitMQ upgrade service scopes and executes the whole hop sequence inside your change window. If the answer is to stay, extended LTS support is the contract that makes staying defensible.

Which advisories your series is exposed to, and which patched versions exist for it, is set out in the RabbitMQ CVE register.

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.

Talk to a RabbitMQ expert.

If the answer is a supported commercial route, open source versus commercial RabbitMQ sets out what each gives you.

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.

Can I still get support for an outdated RabbitMQ version?

Yes. Extended commercial support backports security patches to the series you actually run, including 3.x lines that no longer receive community fixes. It exists precisely for estates that cannot upgrade this quarter — a frozen change window, a certified application, an air-gapped deployment, or a vendor who has not qualified the newer release. It converts an open-ended risk into a managed one, which is normally what an auditor wants to see. Treat it as a bridge while you plan the upgrade, not a permanent destination.

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 behavior. Erlang requirements usually shift as well.