The SLA community RabbitMQ doesn't have

Open source RabbitMQ is licensed under the Mozilla Public License 2.0, and nothing stops you running it on as many nodes as you like. The limit is the patch policy. Once a series leaves community support, its patch releases go to Broadcom's commercial customers, except possibly for very high severity CVEs. RabbitMQ 3.13 left community support on 30 September 2024, and 4.0 to 4.2 are already past community end of life.

That leaves a production broker with three gaps. Nobody is committed to telling you when a new advisory affects your version. Nobody is committed to producing a fix for it. And when the broker misbehaves at 3am there is no contract to escalate through, only forum threads and the team's own knowledge.

Any production RabbitMQ deployment running community builds with no vendor contract: virtual machines, bare metal or Kubernetes, often several clusters owned by different application teams. The Erlang/OTP runtime underneath was usually installed with the broker and has not been revisited since, and the management plugin is often more exposed than the team thinks.

Versions vary across the estate. Some clusters are on the current 4.3 line, others on 3.12 or 3.13 because an application depends on mirrored queues or a vendor product certifies an older version.

Keep running community builds with in-house expertise. This works when the team has deep RabbitMQ and Erlang knowledge and tracks advisories itself. It does not produce fixes for series that are out of community support.

Buy Tanzu RabbitMQ from Broadcom. It adds commercial features and patch releases for older series, and suits estates large enough to absorb licensing by CPU core count with minimum commitments.

Move to a managed message broker service inside a cloud provider's platform. The provider runs the broker for you, on that platform only and on the versions it chooses to offer.

Take a third-party support contract for the community RabbitMQ you already run. The broker stays where it is, and the provider supplies patched builds, notifications and an escalation path.

OSSeva Patch is the baseline. It covers every RabbitMQ version from 3.8.x to the current 4.3.x with quarterly CVE patches, out-of-cycle patches for CVSS 9 and above, and vulnerability disclosure notifications when an advisory affects a version you run. Patches are applied to upstream community source, not a fork, and ship as signed artifacts (GPG and Sigstore) through Maven, Helm or a private OCI registry, with an Erlang/OTP compatibility matrix for each release.

OSSeva Assure adds an annual configuration and architecture audit, version upgrade planning, a reference architecture for your deployment and the SOC 2, HIPAA and PCI attestation package. Upgrade planning covers the move from classic mirrored queues to quorum queues where clusters still depend on them.

The contractual response time sits in OSSeva Operate: 24/7 proactive monitoring on your own infrastructure, a 15-minute P1 incident response SLA, a named senior engineer, runbooks written and maintained for your clusters, and an escalation path to RabbitMQ core contributors. Operate customers also get a contractual SLA on critical CVE remediation.