Install RabbitMQ with Docker Compose, Durable Queues, and the Management UI

If you need a simple way to run background jobs, process tasks, or connect services, RabbitMQ is a strong option. In this guide, RabbitMQ durable queues with Docker Compose is the setup you will build, and it gives you a practical RabbitMQ install with persistent data, a web dashboard, and a real producer-consumer test.

RabbitMQ is a message broker that lets one app send work and another app process it later. This helps when you do not want your web app to wait for slow jobs like sending emails, processing uploads, or running reports. A producer sends the message, RabbitMQ stores it in a queue, and a consumer reads it when ready. That is why RabbitMQ durable queues with Docker Compose are useful for real apps, not just test labs.

A durable queue means the queue definition survives a RabbitMQ restart. A persistent message means the message is written to disk so it can survive a restart, too.

A durable queue alone does not fully protect messages. To make RabbitMQ durable queues with Docker Compose work correctly, you need a durable queue and persistent messages together.

Before you start RabbitMQ durable queues with Docker Compose setup, make sure you have these packages installed on your server:

• Docker version 20 or newer.
• Docker Compose v2, which is included as the modern Docker Compose plugin.
• Python 3 and pip for the test scripts.

Check them with:

If you want to run this on a cloud server, an SSD Linux VPS plan is a good option for RabbitMQ workloads.

First, you must create a project folder and switch to it with the commands below:

This keeps Docker files and Python test files in one place.

Now inside the setup project directory, create the Docker Compose YAML file for RabbitMQ:

Add the following content to the file:

This setup uses the RabbitMQ image with the management plugin included. The named volume stores RabbitMQ data under /var/lib/rabbitmq, which is needed if you want data to survive container recreation.

The hostname is helpful because RabbitMQ uses node names tied to hostnames, and that keeps the node identity stable in Docker setups. This is one reason RabbitMQ durable queues with Docker Compose work better with a fixed hostname than with random container names.

Then, create the .env file:

Add the following lines to the file and use a strong password for it:

Docker Compose reads this file and passes the values into the container at startup.

To start RabbitMQ, bring up the container:

Check the container:

If needed, you can watch the logs:

When the service is up, open the management UI in your browser:

Log in with the username and password from the .env file.

The management UI is included in the management image tag and lets you inspect queues, exchanges, and connections from the browser.

At this point, you can use Python and Pika, the Python RabbitMQ client, to test the setup. This is the part that makes RabbitMQ durable queues with Docker Compose practical for real workers.

First, move into the app folder inside the setup directory:

Create a virtual environment and activate it with:

Install pika inside the environment:

Using python3 -m pip helps ensure pika is installed in the same Python environment you use to run the scripts. This fixes common errors like ModuleNotFoundError: No module named 'pika'.

Check that it worked:

Inside the environment, create the producer.py:

Add the following content with your credentials:

This sends a single persistent message to a durable queue. This is the core of RabbitMQ durable queues with Docker Compose in a real app flow.

Then, create the consumer.py:

Add the following content with your credentials:

basic_qos(prefetch_count=1) helps RabbitMQ send one unacked message at a time to this worker, which is useful for fair dispatch in work queue patterns. The basic_ack call tells RabbitMQ to remove the message only after the consumer finishes processing it.

To run the test, open another terminal and run the commands below:

In your output, you should see:

Again, open another terminal, and run these commands:

In the output, you should see:

Back in the consumer terminal, you should now see:

This confirms that the producer and consumer both worked correctly. It also confirms RabbitMQ durable queues with Docker Compose are not just installed, but are working as a real message flow.

Also, you can verify it from the management UI:

The Type classic and State is running means the queue is active.

To test durability, first run the producer while the consumer is not running:

Now restart RabbitMQ:

Then start the consumer again:

If the message is still processed after the restart, the setup worked as expected. This proves the value of RabbitMQ durable queues with Docker Compose when the queue is durable, and the message is published as persistent.

These commands are enough for most basic RabbitMQ management in Docker:

RabbitMQ uses different ports for different jobs. In a real server setup, not all of them should be public:

For production, keep 15672, 25672, and 4369 private. Even 5672 should not be open to the whole internet unless you really need that, and protect it properly.

If you expect high throughput or heavy worker traffic, an enterprise dedicated server gives you more control over CPU, RAM, disk, and firewall rules.

RabbitMQ durable queues with Docker Compose give you a practical setup for real apps that need background work, async jobs, or message-based communication. The important part is not just running RabbitMQ, but understanding that durable queues keep the queue definition, persistent messages protect the data, and the management UI helps you verify everything in one place.

We hope you enjoy this guide. For the official details on how RabbitMQ stores persistent and transient messages, read the RabbitMQ persistence documentation.