How To Install and Secure RabbitMQ on Ubuntu 22.04
Tricknowtech Team 14 min read
Goal
Reach a state where RabbitMQ is installed from official Ubuntu packages with the management UI enabled, authentication handled by a dedicated administrator account (with the default guest account removed), a virtual host provisioned for application use, and the AMQP (5672) and management (15672) ports reachable only from explicitly trusted source addresses via ufw.
Prerequisites
An Ubuntu 22.04 server with a non-root sudo user, set up per a standard Initial Server Setup guide
ufw installed and enabled, with SSH already allowed so you don't lock yourself out
The IP address(es) or CIDR range(s) of the hosts that will need to reach RabbitMQ
Let an AI agent do this for you
Copy a ready-made prompt for an AI coding assistant with terminal access to your server (Claude Code, Cursor, or similar) — it can carry out the steps below for you. Review what it plans to run before it executes anything.
RabbitMQ is an open source message broker that implements the Advanced Message Queuing Protocol (AMQP), with support for MQTT, STOMP, and other protocols available through plugins. It sits between the components of a distributed application and lets them exchange messages asynchronously through queues instead of calling each other directly, which makes it easier to absorb traffic spikes, decouple services from one another, and scale producers and consumers independently.
A default RabbitMQ installation is tuned for local development, not for a broker sitting on a network-reachable server. The built-in guest account has a well-known password, and the management web UI, once enabled, listens on all interfaces without any access restriction of its own.
In this tutorial you will install Erlang and RabbitMQ from Ubuntu's package repositories, enable the rabbitmq_management plugin to get a browser-based dashboard, create a dedicated administrative user, remove the default guest user so it can't be used for remote authentication, create a virtual host to scope permissions, and configure ufw so only trusted source addresses can reach the AMQP and management ports.
Prerequisites
One Ubuntu 22.04 server set up with a non-root user with sudo privileges and a basic firewall, as described in a standard Initial Server Setup guide for Ubuntu 22.04.
ufw installed and active, with at least SSH (port 22) already allowed, so you don't lock yourself out once you start restricting other ports.
The IP address or CIDR range of the client machines or application servers that will need to reach RabbitMQ. You'll scope firewall rules to those addresses rather than opening the ports to the whole internet.
Step 1 — Installing Erlang
RabbitMQ is written in Erlang and requires an Erlang/OTP runtime with a specific set of standard applications available (crypto, ssl, public_key, and others). Ubuntu 22.04's default repositories include a packaged Erlang release that satisfies RabbitMQ's requirements, so you can install it directly with apt instead of adding a third-party repository.
bash
sudo apt update
sudo apt install -y erlang
This pulls in the erlang metapackage, which brings the core runtime and the standard library applications RabbitMQ depends on. Confirm the runtime is on your PATH:
Tricknowtech VPS Hosting
Dedicated KVM resources and full root access — deployed in under 60 seconds, no ticket required.
“erl -version prints the Erlang Run-Time System (ERTS) version and exits immediately — it doesn't start an interactive shell. A non-empty version string confirms the runtime installed correctly.”
Step 2 — Installing RabbitMQ
With Erlang in place, install the broker package from the same repositories.
bash
sudo apt install -y rabbitmq-server
This installs the broker, its default configuration, and a systemd unit. apt starts and enables the service automatically on most Ubuntu installs, but verify that explicitly in the next step rather than assuming it.
Step 3 — Starting and Verifying the RabbitMQ Service
bash
sudo systemctl enable --now rabbitmq-server
sudo systemctl status rabbitmq-server
The status output should show active (running). You can also query the broker itself, which reports the node name, running listeners, and enabled plugins (none yet, at this point):
bash
sudo rabbitmqctl status
If the service fails to start, check its logs before continuing:
RabbitMQ ships with a management plugin that adds an HTTP API and a browser-based dashboard for inspecting queues, exchanges, connections, and users. It's bundled with the server but disabled by default. Enable it with rabbitmq-plugins:
bash
sudo rabbitmq-plugins enable rabbitmq_management
Restart the service so the new listener comes up cleanly:
bash
sudo systemctl restart rabbitmq-server
Once enabled, the management interface listens on TCP port 15672 on every interface by default. You won't be able to reach it yet — the firewall rules added later in this tutorial block it, and you don't have a non-default account to log in with regardless.
Step 5 — Creating an Administrative User
Create a named administrator account rather than relying on the default guest account, which you'll remove in the next step. Replace admin_user and the password with your own values.
add_user creates the account. set_user_tags administrator grants full access, including logging into the management UI and managing users, vhosts, and policies. set_permissions grants configure, write, and read permissions (in that order) on the default / virtual host, using ".*" to match any resource name.
“Command-line arguments — including the password passed to add_user — are visible to other local users via ps and are recorded in your shell history. Recent versions of rabbitmqctl will prompt for the password interactively if you omit it from the command line; use that form on a shared or multi-user system, and clear the relevant shell history entry either way.”
Step 6 — Removing the Default guest User
The guest account ships with a well-known default password. Since RabbitMQ 3.3.0, the server already refuses guest logins over any connection that isn't from localhost, which blocks casual remote use — but relying on that implicit restriction is weaker than removing the account outright, especially if you ever run a client or admin tool directly on this server. Delete it now that you have a replacement administrative account:
bash
sudo rabbitmqctl delete_user guest
Confirm only your new user remains:
bash
sudo rabbitmqctl list_users
“If any application or local tooling is still configured to authenticate as guest/guest, update it to use admin_user (or a separate, least-privilege user, as shown in the next step) before you delete the account, or that client will start failing to connect.”
Step 7 — Creating a Virtual Host
RabbitMQ groups queues, exchanges, and bindings under virtual hosts (vhosts), which provide logical separation between applications or environments sharing one broker. Create a dedicated vhost instead of putting everything on the default /:
For an application that only needs to publish and consume messages — not administer the broker — create a separate, scoped-down user rather than handing out the administrator account:
app_user has no user tag, so it can authenticate over AMQP and use app_vhost, but it can't log into the management UI or see other vhosts. Grant the management tag only to accounts that genuinely need dashboard access.
Step 8 — Restricting Access with ufw
RabbitMQ's AMQP listener runs on TCP 5672 and the management UI on TCP 15672, both unencrypted by default and bound to every interface. Rather than opening these to the entire internet, scope ufw rules to the specific hosts that need access — application servers for 5672, and your own administrative workstation (or a jump host) for 15672.
First confirm ufw is active and that SSH is allowed, so you don't cut off your own access:
Then add scoped rules for the RabbitMQ ports. The examples below use documentation ranges — replace them with your actual application server and admin workstation addresses:
bash
sudo ufw allow from 203.0.113.0/24 to any port 5672 proto tcp comment 'RabbitMQ AMQP - app servers'
sudo ufw allow from 198.51.100.10 to any port 15672 proto tcp comment 'RabbitMQ management UI - admin workstation'
bash
sudo ufw status numbered
“Never run sudo ufw allow 5672 or sudo ufw allow 15672 without a from clause on a server reachable from the internet — that opens the broker, and the management login page, to every address on the internet rather than just yours. Always scope the rule with from <ip-or-cidr>.”
If a trusted address changes later, remove the corresponding rule by its number and re-add it:
bash
sudo ufw delete numbered <RULE_NUMBER>
Step 9 — Verifying Access
From an allowed host, confirm the AMQP port is reachable:
bash
nc -zv server_ip 5672
From your admin workstation's browser, open http://server_ip:15672 and log in with admin_user and the password you set. You should reach the Overview tab showing zero connections, the app_vhost you created, and no guest account listed under Admin > Users.
From a host that is not in your ufw allow list, the same connection attempts should time out rather than being refused outright, since ufw's default policy silently drops disallowed incoming traffic — that behavior confirms the rules are actually scoping access rather than merely existing.
“This tutorial covers unencrypted listeners scoped by source address, which is a reasonable baseline for a broker reached only from a small, known set of servers. Before handling production traffic over an untrusted network, add TLS to both the AMQP (5671) and management (15671) listeners using RabbitMQ's native TLS configuration, or terminate TLS at a reverse proxy in front of the management UI.”
Conclusion
You installed Erlang and RabbitMQ from Ubuntu's package repositories, enabled the management plugin for a browser-based dashboard, replaced the default guest account with a dedicated administrator user, created a virtual host with permissions scoped to it, and used ufw to expose the AMQP and management ports only to trusted source addresses instead of the whole internet. The broker is now reachable only by the clients and administrators you intended, which is a reasonable baseline to build on before adding TLS or handing the broker production traffic.
