RabbitMQ

briq_run({
  recipe: "rabbitmq",
  params: {
    "version": "4",
    "size": "small",
    "diskGb": 1
  },
  wait: true
})

curl -X POST https://api.briq.cloud/v1/briqs \
  -H "Authorization: Bearer $BRIQ_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "recipe": "rabbitmq",
    "params": {
      "version": "4",
      "size": "small",
      "diskGb": 1
    },
    "wait": true
  }'
# → { "briqs": [{ "id": "bq_…", … }], "outputs": { "AMQP_URL": "…" }, … }

# ... when done, for each briq id
curl -X DELETE https://api.briq.cloud/v1/briqs/<id> \
  -H "Authorization: Bearer $BRIQ_API_KEY"

When to use it

• Your services speak AMQP (Celery, MassTransit, amqplib, Spring AMQP) and need real acks, prefetch and dead-lettering.
• You want the management UI or HTTP API to inspect queues during a test.

Tips

• Boot takes 30 to 60 seconds on small; briq_run waits for it.
• Declare exchanges and queues from code, so tests see what production sees.
• Inspect queues: briq_exec with ["rabbitmqctl", "list_queues", "name", "messages"].
• Workers outside briq: briq_expose port 5672 with protocol: "amqp" gives an amqps:// URL. See Connect to a database from outside.
• Management UI for a human: briq_run({ recipe: "rabbitmq", expose: "private" }).
• Long queues: messages that outgrow memory go to the volume, which starts small; pass diskGb for more. Set it when the briq is created, and it counts toward your plan's disk.