RabbitMQ Erlang Version Compatibility: Version, Erlang and Patch-Owner Matrix

This is a lookup table for a planning meeting: find your series, read off the Erlang you need, the patch level you should be on, and who is on the hook for the next CVE. For the long-form explanation of RabbitMQ end-of-life dates and what end of support means for an audit, read the end-of-life article; for the Erlang 26 background, read the Erlang 26 article. This page does not repeat either.

Read across your row. The patch-owner column is computed from rabbitmq.com's community and commercial end dates as of 29 October 2026; rabbitmq.com calls its commercial dates indicative and treats the Broadcom support portal as the contractual record, so plan with this table and commit against your subscription terms.

Once a series leaves community support, its public patch number stops moving while commercial patching carries on, so reading the public number as "latest" can leave you several patches behind while you believe you are current.

The advisories show it directly. The 18 August 2026 batch (for example GHSA-6gmw-wxch-cvvc) fixes issues in 3.13.19, 4.0.24 and 4.1.15, when the last public patches of those series are 3.13.7, 4.0.9 and 4.1.8. The 25 October 2026 batch (for example GHSA-9h6g-46wc-m2f5) cites 4.3.7, 4.2.12, 4.1.17 and 3.13.21. 4.2 is a useful edge case: it left community support on 31 July 2026, two more public patches followed (4.2.10 and 4.2.11), and the advisories already cite 4.2.12.

Only state a patch number you can source. A subscriber's exact current patch comes from the Broadcom portal; the advisory column above is the floor, not the ceiling.

The Erlang you can run is set by the RabbitMQ patch, not the series, so check the exact patch against the matrix before you touch either.

• Erlang 29 is supported from 4.4.0 and 4.3.7. The docs list 4.3.7 with Erlang 29 although the public release page tops out at 4.3.6.
• Erlang 28 is fully supported from 4.4.0 and 4.3.6. On earlier 4.2 and 4.3 patches the docs allow Erlang 28 for brand-new clusters only, because upgrading a Khepri cluster from Erlang 27 to 28 can hit a known issue in mixed-version clusters, which is what a rolling upgrade is.
• Erlang 27 is the floor from 4.2.9 and 4.3.3. A 3.13 cluster cannot reach those patches in one move, because 3.13 tops out at Erlang 26.2.x.
• Erlang 26 is end of life. 3.13 and 4.0.1 to 4.0.3 run only on it.
• Keep one major Erlang version across the cluster. The docs highly recommend it, RabbitMQ refuses to cluster nodes with a potentially incompatible combination, and they recommend identical versions outside a reasonably long upgrade window.

In our upgrade work we sequence every step so that each node runs an Erlang version supported by both the RabbitMQ version it is leaving and the one it is moving to. That keeps the move rolling instead of turning it into a full stop.

RabbitMQ is written in Erlang and runs on Erlang/OTP, which is why every release series carries an Erlang range and why an Erlang upgrade is a broker change, not an operating system patch. The protocol listeners run in that same runtime: AMQP 0-9-1 (the Advanced Message Queuing Protocol) and, since 4.0, AMQP 1.0 are core protocols, while MQTT (3.1, 3.1.1 and 5.0), STOMP and RabbitMQ Streams ship as plugins, and the management plugin adds the HTTP API. One Erlang version therefore sits under every client connection to the node, whatever protocol it uses.

When a node joins a cluster, RabbitMQ checks Erlang's internal protocol versions and distributed libraries, and it refuses to cluster a potentially incompatible combination.

Erlang 25 appears only in the older rows of the compatibility table, all of them outside community support.

• 3.11: Erlang 25.0 to 25.3.x, so Erlang 25 is its newest runtime.
• 3.12: Erlang 25.0 as the minimum, running up to 26.2.x on 3.12.10 and later as listed in the matrix.
• 3.10.19 and later: 24.3.4.8 to 25.3.x.
• No 4.x release: the lowest Erlang any 4.x release accepts is 26.2 (4.0, 4.1, and the earlier 4.2 and 4.3 patches); 4.2.9 and later, 4.3.3 and later, and 4.4 need 27.0.

A RabbitMQ 3.11 user cannot reach Erlang 26 without leaving 3.11, because its maximum is 25.3.x. If you still run Erlang 25, check the exact build: the RabbitMQ docs note that Erlang 25 before 25.0.2 is affected by CVE-2022-37026, a critical-severity issue (CVSS 9.8).

The Erlang version on a node is whatever package was installed, so ask where it came from before you plan an upgrade. Team RabbitMQ provides Debian and Ubuntu repositories, and for RPM-based systems its zero-dependency Erlang package, which follows the Erlang/OTP patch release schedule closely. Erlang is also bundled in the RabbitMQ Docker image. Distribution repositories often carry heavily split packages and older Erlang versions unless backports are enabled, which is a common reason a node is on a different Erlang from its peers.

Most version arguments come from treating three separate windows as one. They overlap, they end on different dates, and only one of them reaches the 3.8 to 3.12 range.

1. Community support (the RabbitMQ project). Public bug fixes and security patches, best effort, with no response commitment. Each series gets it for months, not years: 4.1 left it on 31 January 2026, 4.2 on 31 July 2026, and 4.3 leaves it on 31 January 2027.
2. Commercial support (Tanzu RabbitMQ, from Broadcom). Patches and fixes on a contracted response time through the Broadcom portal, until the commercial end date in the matrix. The dates do not run in version order: 3.13 is covered to 31 December 2029 while 4.0 closed on 30 September 2026.
3. AceMQ extended support. CVE patches backported to the build you are running, on open-source or Tanzu RabbitMQ, with a 15-minute P1 response. AceMQ extended support covers RabbitMQ back to 3.8.x, which includes series that sit outside the commercial window entirely.

Run two commands on any node and you have everything the matrix needs.

rabbitmq-diagnostics status
rabbitmqctl cluster_status

• Exact RabbitMQ patch and Erlang version on every node. Mixed patches are normal mid-upgrade and a finding if they have been there for weeks.
• Compare your patch with both patch columns. Below the public patch means you are missing public fixes; between the public and advisory columns means you depend on a commercial build to close the gap.
• Check the patch-owner column against your contract. If it says commercial and you have no subscription, nobody is patching you.
• Check the Erlang column against what is installed. An Erlang outside the listed range is unsupported even when the broker runs.

Staying put is a valid decision when it is a managed one. Frozen change windows, certified applications, air-gapped estates and vendors who have not qualified a newer release are the usual reasons we see. What turns it into a risk is having no one contracted to ship the next fix.

For 3.13, 4.1 and 4.2 that can be a Broadcom subscription; for 4.0 and 3.12 back to 3.8 the commercial window has closed and the route is extended support. If you are ready to move instead, the upgrade runbook covers the hop sequence, and the upgrade service runs it with you.