Read time: ~

Environment Setup and the Management UI

Run RabbitMQ locally with Docker, tour the Management UI, learn rabbitmqctl basics, and publish your first message by hand.

Prerequisite:AMQP and the RabbitMQ ModelYou’ll need: Docker installed and running locally.

You now have the mental model. This module makes it concrete: a broker running on your machine that you can click through and poke at, before you write any Spring code in the next section.

What you’ll be able to do after this module

  • Run RabbitMQ locally with the management plugin using Docker.
  • Navigate the Management UI and find connections, channels, exchanges, and queues.
  • Run basic rabbitmqctl commands to inspect the broker.
  • Publish and get a message by hand, without any application code.

1. Local development topology

For local development you run a single broker in a container. Your future Spring Boot services connect to it over the AMQP port, and you inspect it through the Management UI in your browser.

flowchart LR
    Dev["Your Spring Boot app<br/>(later modules)"]
    Browser["Browser"]
    subgraph container [Docker container]
        Broker["RabbitMQ<br/>+ management plugin"]
    end
    Dev -->|"AMQP :5672"| Broker
    Browser -->|"HTTP :15672"| Broker

2. Start RabbitMQ with Docker

Run the broker with the management plugin included. The -management image tag bundles the Management UI.

docker run -d --name rabbitmq-dev \
  -p 5672:5672 \
  -p 15672:15672 \
  rabbitmq:3.13-management

The two published ports serve different purposes:

PortPurpose
5672AMQP: your application connects here
15672Management UI: the HTTP dashboard and HTTP API

Confirm the container is healthy:

docker ps --filter name=rabbitmq-dev
docker logs rabbitmq-dev --tail 20

You should see Server startup complete near the end of the log output.

Note: This single-container setup is for development only. Production topology (clustering, quorum queues, high availability) is covered in the Operations and Troubleshooting section, Cluster Architecture and High Availability.

Keep data across restarts (optional)

The plain docker run above loses its data when the container is removed. To persist queues and messages across restarts, mount a volume:

docker run -d --name rabbitmq-dev \
  -p 5672:5672 -p 15672:15672 \
  -v rabbitmq-data:/var/lib/rabbitmq \
  rabbitmq:3.13-management

3. Tour the Management UI

Open http://localhost:15672 and log in with the default local credentials:

FieldValue
Usernameguest
Passwordguest

Caution: The guest user only works over localhost and is for development only. Real users, permissions, and TLS are covered in the Security module.

Walk through the top navigation tabs:

  • Overview: node health, total message rates, and counts of connections, channels, exchanges, and queues.
  • Connections: every open TCP connection. Empty until an app or tool connects.
  • Channels: the channels multiplexed inside those connections. This is the connection-vs-channel model from the previous module, made visible.
  • Exchanges: the pre-created default exchanges (amq.direct, amq.fanout, amq.topic, and the nameless default exchange) ship with every install.
  • Queues and Streams: empty for now. This is where messages accumulate once you publish.
  • Admin: users, virtual hosts, and permissions.

4. rabbitmqctl basics

rabbitmqctl is the broker’s command-line admin tool. Run it inside the container with docker exec.

# Overall broker status
docker exec rabbitmq-dev rabbitmqctl status

# List queues with message counts
docker exec rabbitmq-dev rabbitmqctl list_queues name messages

# List exchanges and their types
docker exec rabbitmq-dev rabbitmqctl list_exchanges name type

# List open connections
docker exec rabbitmq-dev rabbitmqctl list_connections

# List virtual hosts
docker exec rabbitmq-dev rabbitmqctl list_vhosts

You will use richer diagnostic commands on rotation in the Tooling Walkthrough. For now, list_queues and list_exchanges are enough to confirm what the UI shows you.

5. Publish a message by hand

You can exercise the broker with no application code using rabbitmqadmin, the HTTP-API command-line tool that ships with the management plugin. This proves the round trip before Spring is involved.

# Declare a queue named demo.queue
docker exec rabbitmq-dev rabbitmqadmin declare queue name=demo.queue durable=true

# Publish a message to the default exchange, routed by queue name
docker exec rabbitmq-dev rabbitmqadmin publish \
  routing_key=demo.queue payload='{"orderId":1,"item":"widget"}'

# Read one message back (requeue=false removes it)
docker exec rabbitmq-dev rabbitmqadmin get queue=demo.queue ackmode=ack_requeue_false

The get command prints the payload you published. Publishing to the default (nameless) exchange with a routing key equal to a queue name is a built-in convenience: every queue is implicitly bound to the default exchange by its own name. You will replace this manual step with a RabbitTemplate in the Building with Spring AMQP section.

Confirm the effect in the UI: open Queues and Streams, click demo.queue, and watch the message counts change as you publish and get.

Checkpoint

You should now be able to:

  • Run rabbitmq-dev locally and reach the Management UI at localhost:15672.
  • Find connections, channels, exchanges, and queues in the UI.
  • Inspect queues and exchanges with rabbitmqctl.
  • Declare a queue, publish a message, and get it back with rabbitmqadmin.

Leave the container running. The Building with Spring AMQP section connects to it from real code.