RabbitMQ

RabbitMQ is the message broker for Magento's async processing pipeline. Magento routes bulk catalog operations, async REST API calls, and background indexing tasks through AMQP queues rather than executing them synchronously in the web request. RabbitMQ holds those messages until a consumer process picks them up. Without RabbitMQ, Magento falls back to database-backed queues, which do not scale and cause lock contention on high-traffic stores.

Version

RabbitMQ version is pinned per Magento release:

The container uses the management-alpine image tag, which includes the RabbitMQ management UI.

You can pin a specific version in the environment file (.env):

CONTAINERS__RABBITMQ_VERSION='4.1.8'

Connection defaults

The credentials are written to .env at provision time and to app/etc/env.php via Magento's setup:install. Do not edit env.php directly — it is regenerated on provision runs.

Magento consumer model

Magento's queue consumers are PHP CLI processes that run in a loop, pulling messages from RabbitMQ and processing them. StoreFrame configures Magento with --consumers-wait-for-messages=0, which means each consumer exits after processing all available messages rather than waiting indefinitely for new ones. This works alongside Magento's cron-based consumer runner — cron starts a new consumer process whenever there are messages to process.

Common Magento queues that flow through RabbitMQ:

You can list all configured queues from the VM host:

php bin/magento queue:consumers:list

To start a consumer manually (useful for debugging a stuck queue):

php bin/magento queue:consumers:start async.operations.all --max-messages=100

Management UI

The RabbitMQ management UI runs inside the Docker network and is not exposed directly to the internet. It is available through your environment's domain behind HTTP basic authentication; ask support for the address. The management UI shows:

• Queue depths and message rates
• Consumer connections and channel status
• Exchange topology
• Node health and memory/disk alarms

How to access

# Check queue status from the command line
docker exec rabbitmq rabbitmqctl list_queues name messages consumers

# List connections
docker exec rabbitmq rabbitmqctl list_connections

# Check node health
docker exec rabbitmq rabbitmqctl status

# Purge a specific queue (clears all pending messages — use with care)
docker exec rabbitmq rabbitmqctl purge_queue async.operations.all

Operational gotchas

Memory alarm blocks publishing. RabbitMQ monitors its own memory usage and triggers a memory alarm when it exceeds 40% of available RAM. When the alarm fires, all publishers (including Magento's PHP processes) are blocked — they stall waiting for RabbitMQ to free memory. This surfaces in Magento as hanging API requests or stalled imports. Check the management UI or:

docker exec rabbitmq rabbitmqctl status | grep -A 5 "alarms"

If memory alarms are frequent, the queue is accumulating messages faster than consumers process them. Add consumer capacity or investigate what is generating backlog.

Messages stuck in queue. If consumers are not running (cron is disabled, or consumer processes are crashing), messages accumulate. The management UI shows rising queue depth with zero consumers. Start consumers manually to drain the queue:

php bin/magento queue:consumers:start async.operations.all

Data volume persists across restarts. Unlike Redis, RabbitMQ data is stored in a bind-mounted directory (<project>/.docker/var/lib/rabbitmq on the host). Messages survive container restarts. This means a queue that was stuck before a restart is still stuck after — the messages are preserved.

Credential mismatch after reprovision. If a provision run generates a new rabbitmq_pass (because .env was reset), the new password is written to env.php but RabbitMQ itself may still have the old credential in its Mnesia database. The result is Magento failing to connect. Fix: delete and recreate the RabbitMQ user via rabbitmqctl, or remove the RabbitMQ data volume and re-provision.

consumers-wait-for-messages=0 and cron dependency. With this setting, consumers exit immediately when the queue is empty. If Magento's cron is not running, no new consumers start, and new messages sit in the queue until the next cron run starts a consumer. Confirm cron is healthy if async operations appear delayed.