Keep the RabbitMQ Version You Run — Without the Security Gap

What actually happens when your RabbitMQ version goes end of life

When a RabbitMQ release series passes its end of commercial support date, the project stops publishing security fixes for it — including CVEs. A vulnerability disclosed against RabbitMQ and its dependencies, or against the Erlang/OTP runtime the broker is written in, gets patched in the latest RabbitMQ and never lands in yours.

Three things follow, usually in this order.

• The security gap opens quietly — nothing breaks on the day the series goes EOL. The exposure accumulates. By the time a CVE is publicly disclosed and weaponised, you have no upstream patch and no supported route to one. Community support only ever covers current release series; it was never a lifecycle guarantee.
• Auditors flag unsupported software — running software with no vendor security support is a finding in essentially every enterprise control framework. It surfaces in vulnerability scans, vendor risk questionnaires and compliance audit work. The finding is not “RabbitMQ is insecure” — it is “this component has no route to a security fix.”
• You get pushed into an emergency upgrade — this is where the real cost lands. An unplanned upgrade executed under audit deadline or incident pressure is far more expensive and far riskier than planned extended support. You are changing broker behaviour, queue semantics and AMQP client library compatibility on someone else's timeline, without a proper test cycle.

The Erlang/OTP coupling nobody budgets for

RabbitMQ does not upgrade in isolation. It is written in Erlang, and each release series is coupled to a supported range of Erlang/OTP versions. Moving RabbitMQ forward frequently forces an Erlang upgrade — which in turn touches operating system packages, the TLS stack and sometimes the host OS or Kubernetes base image. What was scoped as “upgrade the message broker” becomes a coordinated platform upgrade across every node in the cluster, plus regression testing of every AMQP and MQTT client that touches it.

RabbitMQ's release cadence is not the problem — the coupling is. That is exactly why teams stall on old versions, and exactly why extended support is usually the cheaper path. Across AceMQ's own customer conversations, more than 85% of organisations running RabbitMQ are on a version that is out of support.

How extended support and RabbitMQ licensing relate

These are two things people routinely conflate, so it is worth being explicit about both the pricing and the coverage boundary.

Where the coverage boundary falls

• RabbitMQ commercial licensing — covers back to version 3.13.x.
• AceMQ support — covers customers back to 3.8.x.

If you are on 3.9, 3.10, 3.11 or 3.12, commercial licensing does not reach you. AceMQ support does. That five-series gap is where most stranded enterprise RabbitMQ deployments actually sit — and it is the reason a Broadcom support portal entitlement check is not the end of the conversation.

AceMQ is also the only provider globally able to license commercial RabbitMQ below Broadcom's standard 72-core minimum, which is what makes a commercially supported broker reachable at all for smaller on-premises and cloud environments.

Where extended support sits alongside community and commercial editions

There are three ways to run RabbitMQ in production, and mixing them up is where most lifecycle risk comes from.

• Community Edition on community support — RabbitMQ is an open-source message broker, free under the Mozilla Public License 2.0. You never pay for the broker. But the community only supports current release series — the moment yours goes EOL there is no security patch path, and a version upgrade becomes the only remedy on offer.
• Tanzu RabbitMQ under Broadcom commercial support — adds enterprise features on top of the open-source core: warm standby with schema and data replication, advanced security including FIPS 140-2 compliance, OAuth 2.0 and forward proxy support, and the same entitlement on Kubernetes. Commercial licensing reaches back to 3.13.x.
• AceMQ extended support — long-term support beyond both, covering versions back to 3.8.x with backported security patches, SLA-backed 24/7 cover and end-to-end RabbitMQ services across legacy and modern estates. This layer exists specifically because the other two do not cover an out-of-support deployment.

Proof from a real engagement

US federal-sector integrator: disaster recovery and message replay

A US federal-sector systems integrator engaged AceMQ to harden its RabbitMQ environment against outage and audit risk. The work included:

• Manual failover runbooks — documented, tested high-availability procedures so an operator can bring the secondary cluster up under pressure without improvising.
• Converting queues to streams — changing queue type to enable message replay for both operational recovery and SOX compliance evidence, where a classic queue's destructive read leaves no trail.
• A buffering layer for outages — so upstream producers keep accepting workload when downstream consumers or the broker are unavailable.
• An operational runbook plus training programme — transferring the procedures to the client's own engineering team rather than leaving them dependent on a vendor for every event.

That is the pattern most end-of-life estates need: make the existing deployment resilient and evidenced, rather than betting the recovery plan on a version upgrade.