RabbitMQ Definitions Export & Import GitOps Prompt
Treat RabbitMQ topology as code — export definitions, scrub secrets, version them, and import safely on boot so brokers are reproducible instead of hand-configured.
- Target user
- Platform and SRE engineers managing RabbitMQ as code
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior platform engineer who manages RabbitMQ topology as code via definitions export/import. Help me set up a safe, reproducible GitOps flow. I will provide: - What I want versioned: vhosts, users, permissions, queues, exchanges, bindings, policies, parameters [DESCRIBE] - How brokers are deployed: container image, config-managed VM, or operator, and the boot process [DESCRIBE] - Secret-handling constraints: where passwords/hashes can and can't live [DESCRIBE] - Cluster version and whether I'll import at boot (`load_definitions`) or via the management API [DESCRIBE] Your job: 1. **Export cleanly** — show `rabbitmqctl export_definitions` (or the management API), and flag that the export contains user password HASHES and policy details. Make clear what must be scrubbed or templated before it goes in git. 2. **Secret handling** — recommend keeping password hashes out of version control: template users/permissions and inject hashes at deploy time, or manage users separately from topology. Never commit raw credentials. 3. **Idempotent import** — explain that `load_definitions` on boot is additive/declarative and safe to re-run, but that it does NOT delete objects removed from the file (no pruning). Plan how removed queues/policies get cleaned up, since drift accumulates otherwise. 4. **Validate before apply** — recommend importing into a throwaway/staging broker first, diffing the resulting topology against intent, and only then promoting. Show how to catch a malformed definitions file before it hits a real node. 5. **Confirm** — after import, verify with `rabbitmqctl list_queues`, `list_policies`, `list_permissions` that the live topology matches the file. Output as: (a) the export command and what to scrub, (b) the secret-handling pattern, (c) the boot-time `load_definitions` config and the no-pruning caveat with a cleanup plan, (d) the staging validate-and-diff step, (e) the post-import verification commands. Always import into a staging broker and diff against intent before applying to production. Remember definitions import does not prune removed objects — verify there's no leftover drift, and confirm no secrets landed in the committed file.
Run this prompt with AI
Test it, get an AI-improved version, or compare models — live in the Prompt Workspace. No copy-paste.
Why this prompt works
Managing RabbitMQ topology as code is the right instinct, and definitions export/import is the supported way to do it — but the export is not safe to commit as-is, and the import does not behave the way GitOps muscle memory expects. This prompt front-loads both gotchas. The export contains user password hashes and the full topology, so dropping it straight into git leaks credentials; the prompt makes scrubbing or templating secrets a first-class step rather than an afterthought.
The import behavior is the bigger conceptual trap. load_definitions is declarative and additive and safe to re-run, which lulls people into treating it like a full reconciler — but it never deletes objects that were removed from the file. There’s no pruning. Remove a queue or policy from your versioned definitions and it lingers on every broker indefinitely, so drift quietly accumulates. By calling this out and demanding an explicit cleanup plan, the prompt prevents the slow rot that turns “infrastructure as code” back into hand-configured brokers.
The validate-and-diff step is what makes the flow trustworthy. Importing into a throwaway staging broker, diffing the resulting topology against intent, and verifying with list_queues / list_policies / list_permissions catches both malformed files and unexpected drift before production sees them. The guardrails keep two failures out: committed secrets and silent leftover objects — the two things that most often turn a tidy GitOps story into an incident.
Related prompts
-
RabbitMQ Operator Policy Design Prompt
Design RabbitMQ policies and operator policies that enforce queue limits, TTLs, and queue types fleet-wide without colliding on priority or fighting application-declared arguments.
-
RabbitMQ Blue-Green Cluster Migration Plan Prompt
Plan a blue-green migration to a brand-new RabbitMQ cluster using Shovel to drain in-flight messages, cut clients over vhost-by-vhost, and keep a clean rollback path.
-
RabbitMQ Classic Queue v2 (CQv2) Storage Migration Design Prompt
Plan a safe migration of classic queues to the CQv2 message store to cut memory use and improve consistency, validating version support, feature flags, and per-queue conversion.
-
RabbitMQ Client Connection & Channel Pooling Design Prompt
Design correct client-side connection and channel pooling for RabbitMQ so an app reuses long-lived connections, isolates publishing from consuming, and never leaks channels under load.
More RabbitMQ prompts & error guides
Browse every RabbitMQ prompt and troubleshooting guide in one place.
Reading prompts? Get all 500 in one free PDF
500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.
- 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
- Instant PDF download — yours free, forever
- Plus one practical AI-workflow email a week (no spam)
Single opt-in · unsubscribe anytime · no spam.