RabbitMQ 3.13 end of life
RabbitMQ 3.13 reached end of community support on 30 September 2024, days after RabbitMQ 4.0 shipped. The last public release was 3.13.7; later 3.13 patch releases exist only for Broadcom's commercial customers, whose support runs to 31 December 2029. Public 3.13 builds also run only on Erlang/OTP 26, which left support in May 2026.
- End of life
- 30 September 2024
- Released
- Feb 2024
- Final release
- 3.13.7
- Successor
- RabbitMQ 4.2 or 4.3
Date published by RabbitMQ release information. We do not publish a lifecycle date we cannot source.
Last reviewed
What actually stops on 30 September 2024
- Community patch releases on the 3.13.x line. 3.13.7 was the last.
- Security fixes for the broker, the management plugin and the shipped plugin set.
- Compatibility updates for newer Erlang/OTP releases. Public 3.13.x is capped at Erlang 26, and OTP 26 no longer receives patches either.
- Public fixes for newer advisories. CVE-2025-50200 and CVE-2026-57213 were fixed on the 3.13 line only in commercial releases (3.13.8 and 3.13.14).
What actually breaks in the upgrade
3.13 is the required stepping stone to 4.x, and that is deliberate
RabbitMQ requires an upgrade to 3.13 before moving to 4.0 or later. Clusters still on 3.12 or earlier therefore face a two-hop migration. If you are on 3.13 you are, awkwardly, in exactly the right place to move — and out of support while you stand there.
Classic mirrored queues are removed in 4.x
This is the change that stops most 3.x to 4.x migrations. Classic queue mirroring was deprecated and is gone in 4.0; the replacement is quorum queues, which have different semantics around ordering, memory behaviour and poison-message handling. This is an application-level migration, not a broker configuration change, and it is why estates stay on 3.13.
The Erlang/OTP version is a second, independent lifecycle
Public RabbitMQ 3.13 releases support Erlang/OTP 26 only. OTP 26 left Erlang's supported window when OTP 29 shipped in May 2026, and its final patch was 26.2.5.21. The TLS and crypto code the broker relies on belongs to OTP, so a patched broker on an unpatched runtime is not a patched system. Any extended-support arrangement should say explicitly whether the Erlang layer is included.
Khepri and feature flags gate the upgrade
RabbitMQ requires all stable feature flags to be enabled on the latest 3.13 patch before moving to 4.0. Clusters that enabled the experimental Khepri metadata store on 3.13 have no in-place upgrade path at all; the release notes direct them to a blue-green deployment.
Why estates are stuck, in practice
In our own engagements the pattern is consistent: it is rarely the broker team that blocks the upgrade. It is an ISV product that embeds RabbitMQ and has not certified 4.x, or a set of applications whose queue semantics depend on mirrored-queue behaviour. Both take quarters to resolve, not weeks.
Your options, costed honestly
Including the ones that do not involve buying anything from us.
| Option | What it is | Effort | Cost | Our view |
|---|---|---|---|---|
| Upgrade to RabbitMQ 4.2 or 4.3 | Requires the move from classic mirrored queues to quorum queues, which is application work. | Weeks to quarters depending on queue semantics | Engineering time | The right destination. Scope the quorum queue migration first; it is the whole project. |
| Extended support on 3.13 | Backported CVE fixes for the broker, the plugin set and the Erlang layer beneath it. | Days to onboard | Subscription per cluster or estate | The common answer, because the quorum queue migration is genuinely large and the support window was genuinely short. |
| Commercial Tanzu RabbitMQ | Broadcom's commercial distribution. | Procurement | Commercial subscription | Workable at scale. The core minimums make it expensive for the small and mid-size clusters that are typical of RabbitMQ deployments. |
| Stay unpatched | Two years of unpatched broker and Erlang CVEs. | None | Zero now | RabbitMQ usually sits inside the trust boundary, which tempts teams to accept this. The management plugin is frequently more exposed than people think. |
What OSSeva does for RabbitMQ 3.13
OSSeva patches this line
OSSeva backports CVE fixes to RabbitMQ 3.13 and to the Erlang/OTP runtime beneath it, delivered as signed packages and container images through your repository manager. RabbitMQ is the technology we know best, and we will tell you plainly when the right advice is to migrate to quorum queues rather than to buy support.
RabbitMQ extended supportWhat your auditor will say
Requirement 6.3.3. Message brokers are in scope as system components wherever they carry cardholder data or sit inside the CDE.
CC7.1, plus availability criteria: an unpatched broker is an availability risk as much as a security one.
Devices and supporting infrastructure embedding RabbitMQ carry it in the software bill of materials. An unsupported broker version appears directly in a 524B submission.
RabbitMQ 3.13: common questions
When did RabbitMQ 3.13 reach end of life?
Community support ended on 30 September 2024, shortly after RabbitMQ 4.0 was released. The last public release on the line was 3.13.7. Broadcom sells commercial 3.13 support to Tanzu licence holders until 31 December 2029.
Which Erlang version does RabbitMQ 3.13 need?
Public RabbitMQ 3.13.x releases support Erlang/OTP 26 only, from 26.0 to 26.2.x. There is no public 3.13 build for Erlang 27, and OTP 26 itself left support in May 2026.
Is RabbitMQ 3.13 still supported?
Not by the community. Commercial support from Broadcom and third-party extended support are the remaining patch sources.
What breaks when upgrading RabbitMQ 3.13 to 4.x?
Classic mirrored queues are removed in 4.0. The replacement, quorum queues, has different semantics for ordering, memory behaviour and poison-message handling, so this is application work rather than a broker configuration change. It is the single reason most estates are still on 3.13.
Do I have to upgrade to 3.13 before RabbitMQ 4?
Yes. RabbitMQ requires an upgrade through 3.13 before moving to 4.0 or later, so clusters on 3.12 or earlier face a two-hop migration.
Can I get security patches for RabbitMQ 3.13?
Yes, from a third-party provider. OSSeva backports CVE fixes to 3.13 and to the Erlang/OTP runtime underneath. Ask any provider whether the Erlang layer is included; a patched broker on an unpatched runtime is not a patched system.
Does OSSeva patch the Erlang runtime as well as RabbitMQ?
Yes. Erlang/OTP has its own release lifecycle and its own CVEs, and covering the broker alone would leave a gap. Both are inside the agreement.
Still running RabbitMQ 3.13?
Tell us the versions and the estate size. We will tell you honestly whether to upgrade or to buy cover — and we say 'upgrade' more often than you would expect.