Run your own RabbitMQ server, sized and locked down properly

Will one server carry your queues?

For most first deployments, yes, provided that server does nothing else heavy. A message broker is a post office that holds messages between the programs sending and receiving them, and RabbitMQ's deployment guidelines ask for 4 cores plus 4 GiB of memory per production node, on a host shared with no other data store. Check these before you order:

• Memory: once the broker uses 60% of the RAM the system reports, it stops taking new messages from publishers until consumers catch up. Keep that setting between 0.4 and 0.7, the docs say, and leave the operating system 30% or more.
• Disk: the default free-space alarm is a tiny 50 MB, meant for tutorials. For real use, the docs suggest roughly the size of the memory watermark, plenty of spare room (quorum queues and streams grow large) and local SSD or NVMe rather than network storage.
• Open files: 50K or more per the checklist, 65536 per the Debian guide, or twice your busiest connection count plus your queue count.
• Network: peak messages per second times peak message size, plus 10%, times 8. The docs' example of 20,000 messages each second at 6 KB comes out at 1.056 Gbit/s.

Our own sum: with 64 GB installed, the default watermark trips near 38 GB.

The doors that stay shut

Only your application servers should reach the broker, and only on the client port. RabbitMQ's production checklist says command-line and inter-node ports belong to the machines running nodes or tools, while the Networking guide warns against exposing 25672 publicly. Below, what can be is bound to the machine itself; ufw refuses the rest.

epmd answers on all interfaces by default, and narrowing it means stopping both it and the node, so this page simply lets the firewall guard it. Plugins bring ports of their own (Prometheus on 15692): open each on purpose.

The server that fits

Since the broker wants a machine to itself, a dedicated server suits it: every core and disk is yours, you log in as root, and nobody meters the port. A ready server is yours within 30 minutes of approval. Choose x86: the Erlang packages installed here are amd64 only. The Ampere Altra servers could only use the arm64 Erlang build Team RabbitMQ publishes on Launchpad, which this guide skips; the X-Gene cartridge is limited to Ubuntu 16.04 and 18.04.

• One broker for a handful of apps: an everyday single-processor server, with a console screen and power button you open yourself.
• Thousands of connections or queues: a two-processor machine from the serious-workloads group, such as the Xeon E5-2630L v3 or Gold 6130.
• A cluster that rides out a dead machine: three matching servers in one city, because the guidelines ask for an odd number of nodes.
• A test broker on fast disk: a cartridge from the NVMe range. Of those, the m510 and m710x have their own console, while other cartridges only switch on and off.

Give your cache and database their own servers too, as in our guides to a Redis server and a PostgreSQL server. If your traffic sum passes a gigabit, faster ports are a flat monthly upgrade; see 10 Gbps servers. One catch for clusters: no private network between servers is sold, so nodes reach each other over public addresses. Open 4369 and 25672 (plus 35672-35682 if you run command-line tools from another node) to the other nodes' addresses only, 5671 to your app servers, and follow the guidelines' advice to use TLS between nodes.

Up and running in an evening

Skip Ubuntu's own package, which the RabbitMQ team's Debian guide calls many releases old. Their apt repositories cover three Ubuntu LTS releases (22.04, 24.04, 26.04) plus Debian 11, 12 and 13, and 26.04 borrows the noble repository. The first block is that quick-start script with our changes: run as root without sudo, it checks your system, refreshes apt, turns on ufw with only SSH allowed (IPv6 too) before anything listens, builds the four repository lines in a small loop with pipefail, installs Erlang and rabbitmq-server, and ends with a ping that prints broker installed or STOP.

# Run as root on Ubuntu 24.04 or 26.04 (amd64). ufw comes first, because the node starts as soon as it is installed.
set -o pipefail
KEY=/usr/share/keyrings/com.rabbitmq.team.gpg
if [ "$(dpkg --print-architecture)" != amd64 ]; then echo "STOP - Team RabbitMQ Erlang packages are amd64 only"
elif ! grep -qE '^VERSION_ID="(24|26)\.04"' /etc/os-release; then echo "STOP - written for Ubuntu 24.04 or 26.04"
else
sed -i 's/^IPV6=.*/IPV6=yes/' /etc/default/ufw && ufw allow OpenSSH && ufw --force enable &&
apt-get update -y && apt-get install -y curl gnupg apt-transport-https &&
curl -1sLf "https://keys.openpgp.org/vks/v1/by-fingerprint/0A9AF2115F4687BD29803A206B73A36E6026DFCA" | gpg --dearmor > $KEY &&
for repo in rabbitmq-erlang rabbitmq-server; do for host in deb1 deb2; do
  echo "deb [arch=amd64 signed-by=$KEY] https://$host.rabbitmq.com/$repo/ubuntu/noble noble main"
done; done > /etc/apt/sources.list.d/rabbitmq.list &&
apt-get update -y &&
apt-get install -y erlang-base erlang-asn1 erlang-crypto erlang-eldap erlang-ftp erlang-inets \
  erlang-mnesia erlang-os-mon erlang-parsetools erlang-public-key erlang-runtime-tools erlang-snmp \
  erlang-ssl erlang-syntax-tools erlang-tftp erlang-tools erlang-xmerl &&
apt-get install -y rabbitmq-server --fix-missing &&
rabbitmq-diagnostics -q ping && echo "broker installed" || echo "STOP - something above went wrong, read it before going on"
fi

Running it twice does no harm; on 22.04, write jammy for both noble and set the version test's (24|26) to 22. A guest account (password guest) now exists, but guest can only sign in from the machine itself.

Lock the doors before your apps arrive

Block two writes /etc/rabbitmq/rabbitmq.conf: plain AMQP and the management page stay on the machine, anonymous logins are switched off as the checklist recommends, the 60% memory watermark stays, and the free-disk alarm becomes 60% of your RAM rounded up, which is our reading of the advice to match the two. It also lifts the open-file limit to 65536, the minimum the Debian guide asks for in production, then prints the listeners so you can see none faces outward.

# Run as root after "broker installed". It will not touch a config file that is already there.
CONF=/etc/rabbitmq/rabbitmq.conf; DROP=/etc/systemd/system/rabbitmq-server.service.d
if [ -e $CONF ]; then echo "STOP - $CONF is already there, add these lines yourself"
else
GB=$(awk '/^MemTotal/ {printf "%d", $(NF-1) * 1024 * 0.6 / 1000000000 + 1}' /proc/meminfo) && [ "$GB" -gt 1 ] &&
rabbitmq-plugins enable rabbitmq_management &&
cat > $CONF <<EOF &&
listeners.tcp.1 = 127.0.0.1:5672
listeners.tcp.2 = ::1:5672
management.tcp.ip = 127.0.0.1
auth_mechanisms.1 = PLAIN
auth_mechanisms.2 = AMQPLAIN
anonymous_login_user = none
vm_memory_high_watermark.relative = 0.6
disk_free_limit.absolute = ${GB}GB
EOF
mkdir -p $DROP && printf '[Service]\nLimitNOFILE=65536\n' > $DROP/limits.conf &&
systemctl daemon-reload && systemctl restart rabbitmq-server &&
rabbitmq-diagnostics -q check_running && OUT=$(rabbitmq-diagnostics -s listeners) && echo "$OUT" &&
echo "$OUT" | grep -q 'Interface: 127.0.0.1, port: 15672' &&
! echo "$OUT" | grep -Eq '(\[::\]|0\.0\.0\.0), port: (5672|15672),' &&
echo "only reachable from this machine" || echo "STOP - look at the listeners printed above"
fi

Keep more free disk than that limit, or the broker pauses every publisher the moment it restarts. If the block halts once the file exists, deal with the error shown, rename the half-done file (mv /etc/rabbitmq/rabbitmq.conf /root/rabbitmq.conf.partial) and start the block over.

For apps on other servers, use TLS. Store the certificate, private key and CA bundle in /etc/rabbitmq/tls/ where the rabbitmq user can read them, add listeners.ssl.default = 5671 along with the cacertfile, certfile and keyfile settings the TLS guide describes; after a restart, admit each app server by address, for example ufw allow proto tcp from 198.51.100.7 to any port 5671.

Accounts, and a nightly copy of your setup

Each app deserves its own login, never guest, as the checklist suggests. Block three creates an admin plus a shop-app user in a shop virtual host (rename to taste), keeps the generated passwords in a file only root can read, removes guest last, and schedules a nightly export of your definitions with a copy of the config. Older copies go only once a newer one checks out.

# As root, once only: admin + app user, guest removed, nightly copy scheduled.
SECRETS=/root/rabbitmq-credentials.txt; BK=/srv/rabbitmq-copies
if [ -e $SECRETS ]; then echo "STOP - $SECRETS exists, so this already ran"
else
PA=$(openssl rand -hex 24) && PS=$(openssl rand -hex 24) && [ -n "$PA" ] && [ -n "$PS" ] &&
install -m 600 /dev/null $SECRETS && printf 'admin %s\nshop-app %s\n' "$PA" "$PS" > $SECRETS &&
rabbitmqctl add_vhost shop &&
echo "$PA" | rabbitmqctl add_user admin && rabbitmqctl set_user_tags admin administrator &&
rabbitmqctl set_permissions -p / admin ".*" ".*" ".*" &&
rabbitmqctl set_permissions -p shop admin ".*" ".*" ".*" &&
echo "$PS" | rabbitmqctl add_user shop-app &&
rabbitmqctl set_permissions -p shop shop-app ".*" ".*" ".*" &&
rabbitmqctl delete_user guest &&
install -d -m 700 -o rabbitmq -g rabbitmq $BK &&
printf '%s\n' 'SHELL=/bin/bash' 'PATH=/usr/sbin:/usr/bin:/sbin:/bin' \
 '40 2 * * * root umask 077; K=/srv/rabbitmq-copies; S=$(date +\%F-\%H\%M\%S); rabbitmqctl -q export_definitions $K/defs-$S.json && python3 -m json.tool $K/defs-$S.json > /dev/null && tar -czf $K/etc-$S.tgz -C / etc/rabbitmq etc/systemd/system/rabbitmq-server.service.d etc/cron.d/rabbitmq-backup && tar -tzf $K/etc-$S.tgz > /dev/null && find $K -name "defs-*" -mtime +30 -delete && find $K -name "etc-*" -mtime +30 -delete || echo "$S copy FAILED" >> $K/errors.log' \
 > /etc/cron.d/rabbitmq-backup &&
rabbitmqctl list_users && echo "accounts ready" || echo "STOP - see above"
fi

For the management page, tunnel in with ssh -N -L 15672:127.0.0.1:15672 you@your-server and visit http://localhost:15672. If block three stopped halfway, rabbitmqctl list_users shows what got made; complete it yourself using the passwords in the file, or remove those users and the credentials file and run it fresh. Exports include password hashes, so guard them. You manage the server; we keep the hardware and the network running, so moving /srv/rabbitmq-copies to another machine is up to you, plus the credentials file in /root, missing from the archive (a password manager works too).

Getting it back after a bad day

The nightly file brings back users, virtual hosts, permissions and policies, plus your queues, exchanges and bindings, yet not the messages that were waiting. RabbitMQ's backup guide says message folders copied from a running node make an inconsistent snapshot; a stopped node's copy, from version 3.8 on, works only on a node carrying exactly the same name. Rebuilding from the file, as root:

1. Run only the install block on the new server. Make the folder with install -d -o rabbitmq -g rabbitmq -m 700 /srv/rabbitmq-copies and put one night's defs and etc files in it; S below stands for that night's stamp.
2. Test, unpack and apply the config in one go: F=/srv/rabbitmq-copies/etc-S.tgz; tar -tzf $F > /dev/null && tar -xzf $F -C / && systemctl daemon-reload && systemctl stop rabbitmq-server && systemctl start rabbitmq-server. The nightly schedule returns with it.
3. Loading into a node whose current setup matters? Export that setup to its own file first, so you can go back.
4. Validate the JSON and load it only if it is clean: J=/srv/rabbitmq-copies/defs-S.json; python3 -m json.tool $J > /dev/null && rabbitmqctl import_definitions $J.
5. Delete the new guest account and place the credentials file you kept elsewhere under /root (mode 600).
6. The archive holds no firewall rules, so let each app server back in, for example ufw allow proto tcp from 198.51.100.7 to any port 5671, plus the other nodes of a cluster.

Upgrading without surprises

Read the release notes and check the path before anything else: RabbitMQ 4.4.0 came out on 20 October 2026, a rolling upgrade to it works only from 4.2.x or 4.3.x, and it runs on Erlang 27.0 up to 29.x. The upgrade guide says one node follows the same steps as a cluster.

• Switch on every stable feature flag with rabbitmqctl enable_feature_flag all, because the guide warns an upgrade may fail otherwise.
• Check that no alarm is active (rabbitmq-diagnostics check_local_alarms) and take a fresh export.
• Stop the broker, then upgrade Erlang alongside it: apt-get update && systemctl stop rabbitmq-server.service && apt-get upgrade, which updates other packages as well. Start it if the package did not, and repeat the checks.
• Prefer to choose when a new series lands? The Debian guide explains apt pinning.

What the licence lets you do, and when to look elsewhere

The rabbitmq-server repository's LICENSE file says the server and its core (tier 1) plugins use MPL 2.0, the Mozilla licence, and some OCF files use Apache 2.0. This is how we read it, and it is no legal advice: you may run it for any purpose, commercial included, and MPL 2.0 says nothing about offering software over a network. The duty starts when you distribute copies, changed or not: then the MPL-covered files, with any edits you made to them, must be released as source code under MPL terms, while code in your own separate files can stay under your licence.

Be honest about one server: the guidelines see single-node setups as fine for development, testing and some QA work; surviving a failed machine takes three.

Questions people ask

What happens when memory or disk runs low?

The broker raises a resource alarm and blocks connections that publish, while connections that only consume keep receiving messages. Normal service resumes once the alarm clears. With default settings that happens at 60% of RAM or 50 MB of free disk, which is why the setup raises the disk limit.

Do I have to open port 15672 to use the management page?

No. Keep it bound to 127.0.0.1 and reach it through an SSH tunnel from your own computer. That page and its HTTP API can create users and change permissions, which is why it should never face the internet.

Is RabbitMQ free to use in a commercial product?

Running it is free under the MPL 2.0, commercial use included. If you ship RabbitMQ itself to customers, you owe them the source of the MPL-covered files, including any changes you made to them. Broadcom sells paid support separately; the release page calls its dates indicative and points to Broadcom's support portal for the official lifecycle.