RabbitMQ 3.13 end of life
RabbitMQ 3.13 reached community end of life on 17 September 2024, when RabbitMQ 4.0 was released. The final community release on the line was 3.13.7. RabbitMQ's community support model covers only the current release series, so 3.13 stopped receiving patches the moment 4.0 shipped — a much shorter window than most teams assume.
- End of life
- 17 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.
What actually stops on 17 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, which matters because the Erlang runtime underneath has its own lifecycle and its own CVEs.
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
RabbitMQ 3.13 runs on Erlang 26. Erlang releases have their own support windows and their own CVEs, and 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.
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 | Subject to core minimums | 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?
17 September 2024, the day RabbitMQ 4.0 was released. The final community release on the line was 3.13.7. RabbitMQ's community model supports only the current release series, so the 3.13 window closed as soon as 4.0 shipped.
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.