erlang-rpm: a zero dependency Erlang build for RabbitMQ on RPM platforms

Zero dependency means OpenSSL is your problem

The package is described as a virtually zero dependency Erlang RPM that provides just enough to run RabbitMQ, and it may or may not be suitable for running other Erlang-based software or third party RabbitMQ plugins. That caveat is the most important sentence in the readme, because it defines the scope precisely. The dependency situation is deliberate and explicit. This package intentionally does not include OpenSSL or libcrypto, and it must be provisioned separately, because recent Erlang versions require a modern OpenSSL version. Which version that is depends on the variant. The el9 and el10 variants, covering modern Fedora, RHEL 9 and later, CentOS Stream 9 and later, Rocky Linux 9.x and later, Alma Linux 9.x and later and so on, need OpenSSL 3.x, while the el8 variant for Rocky Linux 8.x and Alma Linux 8.x needs OpenSSL 1.1.x. The package targets Erlang and OTP 28.x, 27.x and 26.x, and both x86-64 and aarch64 versions can be built in containers. Matching your distribution to the right OpenSSL major version is the step that decides whether the runtime starts or refuses to.

Which distributions the binaries target

The binary builds target modern RPM-based distributions, and the readme lists them precisely rather than saying recent versions of anything. RHEL 8.10 and later is the first, described as the most recent series covered by full support. Then CentOS Stream 9 and 10, Fedora 41 or later, Rocky Linux 8.10, 9.7 and 10.0, and Alma Linux 8.10, 9.7 and 10.0, each noted as the most recent maintained releases of their 8.x, 9.x and 10.x lines. Amazon Linux 2023, VMware PhotonOS 5 and Oracle Linux 9 and 10 complete the list. There is a separate note for the RHEL and CentOS Stream 8 family, because CentOS Stream 8 reached end of life in May 2024, and the CentOS 8 versions of these packages are produced on Rocky Linux 8.10 and later from July 2024 onwards. CentOS 7 is explicitly out, since Team RabbitMQ stopped supporting it in May 2022. A handful of one-off CentOS 7 packages exist for Erlang 28.4.3, 27.3.4.11, 26.2.5.19 and 25.3.2.21, statically linked against OpenSSL 1.1.x, while regular CentOS 7 and Amazon Linux 2 builds were produced up to Erlang 23.3.4.18 and were dynamically linked against OpenSSL 1.0.

Signing keys come first, and there are two of them

The package is signed, and the readme documents the import before anything else, which is the right order. The primary RabbitMQ signing key is imported with rpm and the standard signing key URL.

## primary RabbitMQ signing key
rpm --import https://github.com/rabbitmq/signing-keys/releases/download/3.0/rabbitmq-release-signing-key.asc

If you use the Cloudsmith dnf repository, a separate Cloudsmith repository key must also be imported.

## primary RabbitMQ signing key
rpm --import https://github.com/rabbitmq/signing-keys/releases/download/3.0/rabbitmq-release-signing-key.asc
## modern Erlang repository
rpm --import 'https://github.com/rabbitmq/signing-keys/releases/download/3.0/cloudsmith.rabbitmq-erlang.E495BB49CC4BBE5B.key'

Two keys rather than one is a small detail with a practical consequence, because a repository that verifies a package signature against a key you have not imported will fail in a way that looks like a corrupt package. The key names in the URLs are versioned, with a 3.0 release directory and a key identifier suffix, so a script that pins the key import should pin those strings rather than assume a stable path.

Installing from a single RPM file

The direct download route is the simplest one and it exists because the package is distributed as a single RPM, which makes it convenient to download and install. Erlang 26 x86-64 and aarch64 releases can be provisioned on RHEL 9, CentOS Stream 9, Amazon Linux 2023 and modern Fedora this way, and the readme gives a worked example.

# This is just an example that uses an aarch64 package for Amazon Linux 2023
cd /tmp/
curl -sfL -O https://github.com/rabbitmq/erlang-rpm/releases/download/v26.2.5.3/erlang-26.2.5.3-1.amzn2023.aarch64.rpm
sudo dnf install -y ./erlang-26.2.5.3-1.amzn2023.aarch64.rpm

Two things to note in that example. The package filename encodes the distribution and the architecture, so the amzn2023 and aarch64 parts are not decoration, and picking the wrong one for your host will not install. And the curl call uses the silent and fail flags, so a failed download produces an error rather than a zero byte file that dnf would then complain about. The same single file approach works with dnf install -y against a path to any erlang.rpm you have downloaded by hand, which is what you want in an air gapped build.

The dnf repository, and why the mirrors are the recommended path

There is a dnf repository distributing x86_64 builds of the package, and the readme is unusually insistent that you use the mirrors rather than the upstream. The package is distributed via a dnf repository that mirrors from Cloudsmith, and the upstream Cloudsmith repository is subject to traffic quotas. When the quota is reached, package installations will only be possible from the mirrors, so it is highly recommended that you use them. The examples in the readme use a mirror of the Cloudsmith repo, and the key point is that all packages in it are signed with the same signing key. The repository configuration itself is a file in /etc/yum.repos.d with a name, a baseurl pointing at a mirror host, and a set of verification settings, and the sample uses the modern-erlang name with two mirror baseurls listed so that a failed host does not break the fetch. The readme also notes that the Cloudsmith upstream itself is mirrored at a RabbitMQ owned host, and that the mirror is very unlikely to hit its traffic quota.

Building the RPM yourself, and what the tree contains

Binary packages can be produced on any host that can run Docker, including aarch64 hosts, so you are not restricted to building on the same architecture you deploy to. The repository top level shows how that is arranged, with a docker directory, a versions directory, an erlang.spec file and a Makefile. The Makefile is where the build is driven, and it names the release it builds, the upstream tarball it fetches from the Erlang OTP archive on GitHub, and the directories it uses for tarballs and temporary source. It also carries the packaging defines, which set the top directory, the temporary path, the sysconf directory under /etc and the local state directory under /var, and the build-deps target lists the packages the build host needs, among them autoconf, clang, m4, openssl-devel, ncurses-devel, rpm-build, tar, wget, zlib-devel and systemd-devel. The prepare step reuses an already downloaded tarball when it exists, which the comments explain is for faster turnaround during development and that the directory can be mounted from the host. The top level also carries two patch files applied to the OTP source, one about not formatting man pages and not installing miscellaneous files, and one dropping the HTTP server parts of inets, which is a good indication of how the trimming is done.

Maintenance state, architecture coverage and the Debian alternative

The repository is not archived and the last push was on 2026-10-15, and the recent releases are three Erlang lines built on the same day or the day before, 29.1.2, 28.5.0.8 and 27.3.4.19. x86-64 binaries are provided with every release, while aarch64 binaries are limited to new major and minor releases, and patches when resources allow, which is worth knowing before you plan a patch-level upgrade on ARM. The default branch of the repository is erlang-27, which tells you the working line even though the releases span several. For RabbitMQ version compatibility the readme points at the supported Erlang versions page in the RabbitMQ documentation for an up to date matrix, rather than embedding a table that would go stale. And if you are on a Debian based system, this package is not for you, since Team RabbitMQ also packages recent Erlang and OTP releases for Debian and provides a modern Erlang PPA for Ubuntu, with the install documentation on the RabbitMQ site.

Editorial conclusion

erlang-rpm fits a RabbitMQ operator on an RPM-based distribution who wants an Erlang runtime that does not drag in a distribution's own OTP build, or who needs a version of Erlang that their distribution stopped shipping, since the package targets OTP 26, 27 and 28 while supporting several of those on aarch64. It does not fit a Debian or Ubuntu installation, because the project points you at separate Debian packages and an Ubuntu PPA instead, and it does not fit a system where you cannot provision OpenSSL separately, since the package intentionally excludes it. Before you install, pick the el8 or el9 style variant that matches your distribution so the OpenSSL requirement lines up, import the signing keys, and check the RabbitMQ supported Erlang versions page for the compatibility matrix before you pin a version.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. rabbitmq/erlang-rpm on GitHub
4. README
5. Releases