The Featured Authorized Partner for RabbitMQ — named by the engineers who build it
AceMQ is the Featured Authorized Partner for RabbitMQ, named by the RabbitMQ Core Engineering Team — the people who write and maintain the broker. That recognition covers RabbitMQ support, licensing and professional services, and it makes AceMQ the only RabbitMQ partner with a direct line to the core team. When an escalation needs an answer that is not in the documentation, it does not stop at a support tier.
You do not have to take our word for it — RabbitMQ lists AceMQ on its own site.
See AceMQ listed on rabbitmq.comYou probably need this if…
Where you are now, and where you end up
Concrete state changes, not deliverable counts. This is what actually differs about your RabbitMQ estate when the engagement closes.
Running an end-of-life RabbitMQ version with disclosed CVEs and no route to a security fix.
Every relevant CVE backported to your exact running version and delivered as a rolling patch bundle.
Unsupported software flagged as an audit finding, with no evidence to offer in response.
A support agreement naming your specific version, plus patch records and attestation documentation an auditor accepts.
Facing an emergency upgrade on an audit deadline, changing broker semantics without a proper test cycle.
A planned upgrade path with the Erlang/OTP dependency chain mapped and a tested rollback — executed on your schedule, not someone else's.
Outside the commercial licensing window on 3.9–3.12, told by every other provider that the answer is to upgrade.
Under active vendor security support on the version you actually run, from the only provider whose support window reaches back that far.
What's covered
How it actually runs
Every phase has a defined duration and a concrete artifact handed over at the end of it. You always know what stage you're in and what you've received.
Assessment of your current version and estate
We map what you are actually running: RabbitMQ versions, Erlang/OTP versions, cluster topology, node counts, queue types, client libraries and the exposure profile of your release series.
- Version and Erlang/OTP inventory across every environment
- CVE exposure profile for your specific release series
- Core count for pricing, across production, pre-production and DR
Written scope and SLA proposal
You get a written support scope, coverage boundaries and SLA terms, priced per core on the same basis as RabbitMQ licensing, with terms available up to 3 years.
- Line-item quote priced per core, ready for procurement
- Written SLA and coverage boundaries
- Term options up to 3 years
Onboarding with runbooks
We document your RabbitMQ environment, build the operational and failover runbooks for your specific topology and integrations, establish escalation paths, and set up the patch delivery channel.
- Operational and failover runbooks for your topology
- Named escalation path and 24/7 contact route
- Patch delivery channel configured and tested
Ongoing patching and 24/7 cover
Rolling patch bundles as CVEs land, scheduled health checks and proactive monitoring, compliance documentation, and round-the-clock incident cover against the 15-minute response SLA.
- Backported patch bundles as vulnerabilities are disclosed
- Scheduled health checks and configuration review
- Audit-ready patch and CVE response records
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.
Extended commercial support is licensed the same way a RabbitMQ licence is — per core, on the same pricing logic, counted across every environment. It is not a separate product bolted on beside licensing; it is the support entitlement, priced per core, extended to versions the standard channel will not cover. What changes on an out-of-support version is not how you buy it, only how far back the coverage reaches.
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.
Real RabbitMQ Results
See how enterprises trust AceMQ for their most critical RabbitMQ workloads.
Questions about RabbitMQ extended support
Talk to a RabbitMQ Expert
Send us a message and we'll follow up within one business day — or book a free 30-min consultation directly.
305-204-2607info@acemq.comMiami, FL 33130
Prefer to talk now? Call us directly or use the consultation tab to find a time that works.