RabbitMQ

The most-deployed open-source message broker.

Service #message-broker#amqp#queue#messaging#pubsub

RabbitMQ is a feature-rich open-source message broker implementing AMQP 0-9-1, MQTT, STOMP, and the RabbitMQ Streams protocol. It's the go-to choice for decoupling microservices, reliable background jobs, fanout pub/sub, and complex routing topologies. Pier deploys the official Docker image with the management UI enabled.

Deploy with Pier

1 Open the Pier dashboard and click Add service.
2 Pick RabbitMQ from the template list.
3 Choose the version, set a service name, and Pier provisions the container, storage, and ports automatically.
4 Attach a domain if you want HTTPS. Traefik auto-provisions the Let's Encrypt certificate.

What is RabbitMQ?

RabbitMQ is the most-deployed open-source message broker. Started in 2007 at Rabbit Technologies (later acquired by Pivotal, now part of Broadcom), it implements AMQP 0-9-1 as its primary protocol and adds MQTT, STOMP, and RabbitMQ Streams via plugins. Mozilla, Reddit, Cisco, NASA, AT&T, and tens of thousands of other organizations run it in production.

The “smart broker” model means RabbitMQ handles routing, fanout, retries, TTLs, dead-lettering, priority — features that are server-side in RabbitMQ vs client-side in Kafka. For task queues, microservice decoupling, webhook delivery, and IoT MQTT bridging, RabbitMQ usually beats Kafka on simplicity and ergonomics.

How Pier deploys it

Pier uses the official rabbitmq Docker image with the :management tag that includes the web UI plugin. Default ports are 5672 (AMQP) and 15672 (management UI). The data volume mounts at /var/lib/rabbitmq — queue state, definitions, message storage all live there.

Pier auto-generates the admin user password. For the management UI, attach a domain in Pier’s Domains tab and Traefik routes traffic to port 15672.

Connection string for client apps: amqp://admin:password@host:5672/.

When NOT to use RabbitMQ

For high-throughput event streaming with replay needs — Apache Kafka. For ephemeral pub/sub with no durability requirement — Redis pub/sub. For ultra-light cloud-native messaging — NATS. RabbitMQ is the default choice when you need a feature-rich broker with rich routing, retries, and operational maturity.

Key features

Multi-protocol

AMQP 0-9-1 (primary), MQTT (IoT), STOMP (web messaging), and RabbitMQ Streams (Kafka-like log). One broker, many clients.

Rich exchange types

Direct, fanout, topic, headers, consistent-hash exchanges. Build any routing pattern from simple pub/sub to per-tenant sharding.

Management UI + HTTP API

Web UI for queues, exchanges, bindings, connections, channels, users, vhosts. Every UI action has an HTTP API equivalent — great for automation.

Quorum queues

Raft-based replicated queues for high-availability scenarios. Survives node failures without manual mirror policy.

Per-message TTL & dead-letter exchanges

Built-in support for expiring messages, retry queues, and dead-letter routing. No external retry-with-backoff plumbing needed.

Flexible consumer patterns

Competing consumers, exclusive consumers, priority queues, lazy queues (for huge backlogs), consumer cancel notifications.

Use cases

Background job processing

Decouple HTTP request handling from slow work. Workers in any language pull from RabbitMQ — Celery (Python), Sidekiq (Ruby), Bull (Node), Hangfire (.NET).

Microservice decoupling

Service A publishes events; services B and C consume independently. Topic exchanges + per-service queues let you add subscribers without changing publishers.

Reliable fanout / event broadcasting

Domain events broadcast to multiple subscribers — analytics, audit log, notification service, cache invalidator — each with its own queue.

IoT MQTT broker

Devices publish telemetry via MQTT; backend services consume via AMQP. RabbitMQ bridges both protocols seamlessly.

Webhook delivery with retries

Inbound webhooks → RabbitMQ queue → worker delivers to user-defined URL with exponential backoff (via dead-letter retry queues).

Code examples

Connect from Python (pika) python

import pika

conn = pika.BlockingConnection(
    pika.URLParameters("amqp://admin:password@rabbitmq:5672/")
)
ch = conn.channel()
ch.queue_declare(queue="emails", durable=True)
ch.basic_publish(
    exchange="",
    routing_key="emails",
    body='{"to": "[email protected]", "tpl": "welcome"}',
    properties=pika.BasicProperties(delivery_mode=2),
)

Consume in Node.js (amqplib) javascript

import amqp from "amqplib";

const conn = await amqp.connect("amqp://admin:password@rabbitmq:5672/");
const ch = await conn.createChannel();
await ch.assertQueue("emails", { durable: true });
await ch.prefetch(10);
ch.consume("emails", (msg) => {
  const job = JSON.parse(msg.content.toString());
  sendEmail(job).then(() => ch.ack(msg));
});

Topic exchange routing bash

# Declare a topic exchange
rabbitmqadmin declare exchange name=events type=topic durable=true

# Service A binds to all 'order.*' events
rabbitmqadmin declare queue name=orders-svc-q durable=true
rabbitmqadmin declare binding source=events destination=orders-svc-q \
  routing_key="order.*"

# Service B binds to all 'order.paid' and 'invoice.paid'
rabbitmqadmin declare queue name=billing-q durable=true
rabbitmqadmin declare binding source=events destination=billing-q \
  routing_key="*.paid"

Dead-letter retry pattern json

{
  "queue": "tasks",
  "arguments": {
    "x-dead-letter-exchange": "tasks-dlx",
    "x-dead-letter-routing-key": "retry"
  }
}

How it compares

vs Apache Kafka	Kafka is an append-only log — high throughput, replay-friendly, requires Zookeeper or KRaft. RabbitMQ is a smart broker — flexible routing, lower throughput, simpler operations. Pick Kafka for event streaming at scale; RabbitMQ for task queues and microservice messaging.
vs Redis pub/sub & Streams	Redis is in-memory, simple, fast. Redis Streams approach Kafka semantics; Redis pub/sub is fire-and-forget. RabbitMQ wins on durability guarantees, routing flexibility, and clustering.
vs NATS	NATS is ultra-lightweight Go-based messaging. Excellent for cloud-native microservices. RabbitMQ has more features, more clients, more operational maturity.
vs Amazon SQS / Cloud Pub/Sub	Managed cloud queues — simple, no ops, vendor-locked. RabbitMQ is self-hosted with rich features. Trade-off between zero-ops and full control.

Frequently asked questions

Default port and management UI?

5672/tcp for AMQP, 15672/tcp for the management UI. Pier exposes both; attach a domain to access the UI via HTTPS.

Default credentials?

Pier generates a strong password for the `admin` user (RABBITMQ_DEFAULT_USER / RABBITMQ_DEFAULT_PASS). Visible on the service page.

Persistence?

Yes — Pier mounts `/var/lib/rabbitmq` as a persistent volume. Messages with `delivery_mode=2` (persistent) survive broker restarts when the queue is `durable`.

Clustering?

RabbitMQ clusters need shared Erlang cookie + DNS-discoverable nodes — outside the single-container template scope. For HA, use quorum queues on a single node, or build a custom multi-node template.

Memory limits?

RabbitMQ uses `RABBITMQ_VM_MEMORY_HIGH_WATERMARK` (default 0.4 = 40% of system RAM) to throttle producers when memory runs low. Tune via env if your container is memory-constrained.

Which version does Pier deploy?

Default `latest` (RabbitMQ 4.x). `3-management` and `4-management` are pinned variants that include the management UI plugin.

Backups?

For queue definitions + users + policies — `rabbitmqctl export_definitions` to JSON, version in Git. For actual message data, you typically don't back up — design queues as transient state.

Related services

Deploy on your VPS

Deploy this service →