Why does this generate three separate sections?

rabbitmq.conf configures the broker process itself (listeners, default credentials), definitions.json is a separate importable file that pre-seeds users, vhosts, and permissions (useful for reproducible deployments), and clustering settings are commented out by default since a single-node config shouldn't accidentally attempt to join a cluster on first boot.

How would I actually use the definitions.json output?

It matches the shape RabbitMQ's management plugin exports and imports, either point management.load_definitions at the file path in rabbitmq.conf, or import it manually via the management UI or `rabbitmqctl import_definitions`, and RabbitMQ will create the users, vhosts, and permissions it describes on startup.

Why is the clustering section commented out?

Clustering settings (node name, peer discovery) only make sense once you actually have other nodes to join, so this tool emits them as commented reference lines you can uncomment and adjust rather than active settings that would make a single-node broker try to discover peers that don't exist.

What permissions does the generated definitions.json grant?

The default user is granted configure, write, and read permissions of '.*' (everything) on the vhost you specify, matching what a newly created RabbitMQ admin user typically needs; scope this down for non-administrative application users after importing.

RabbitMQ Config Generator - rabbitmq.conf & definitions.json

Overview

Introduction

Standing up a new RabbitMQ broker touches at least two files, rabbitmq.conf for the broker's own runtime settings and definitions.json for the users, vhosts, and permissions you want pre-seeded, plus a mental note of what clustering would eventually need.

This tool generates all three from one form: rabbitmq.conf, a matching definitions.json built from the same default user and vhost, and a commented clustering hints block, each clearly labeled in a single output.

What Is RabbitMQ Config Generator?

A generator producing rabbitmq.conf (listeners.tcp.default, default_user, default_pass, default_vhost), a definitions.json snippet with a users array, a vhosts array, and a permissions array wired to those same values, and a commented clustering section.

The clustering section includes a node name field and a repeatable list of discovery peers, rendered as commented reference lines rather than active configuration.

How RabbitMQ Config Generator Works

The rabbitmq.conf section maps form fields directly to their dotted-key settings; the definitions.json section reuses the same default_user/default_pass/vhost values to build a users entry (tagged administrator), a vhosts entry, and a permissions entry granting that user full access on that vhost.

The clustering section always emits commented lines (prefixed with #), substituting a placeholder node name and a single placeholder peer when none are provided, so the section is always present as a reference even on a single-node setup.

When To Use RabbitMQ Config Generator

Use it when provisioning a new RabbitMQ broker and you want rabbitmq.conf and a matching definitions.json produced together instead of keeping them consistent by hand.

It's also useful as a quick reference for the exact dotted-key syntax RabbitMQ's cluster_formation settings use, before wiring up a real multi-node cluster.

Often used alongside Kafka Config Generator.

Features

Advantages

Keeps rabbitmq.conf and definitions.json consistent by construction, since both are derived from the same default user, password, and vhost fields.
Produces definitions.json in the exact shape RabbitMQ's management plugin expects for import, ready to reference from management.load_definitions.
Surfaces clustering's exact dotted-key syntax as commented reference lines, useful even when you're not clustering yet.

Limitations

Only models a single default user/vhost/permission set in definitions.json; a real multi-tenant broker typically needs several users and vhosts, which would need manual extension of the generated JSON.
Clustering output is reference commentary, not a working multi-node configuration, actual clustering requires matching Erlang cookies and network connectivity between nodes.
Doesn't cover exchange, queue, or binding definitions, only users/vhosts/permissions.

Examples

A broker with a dedicated vhost and clustering hints for a 3-node setup

Input

port: 5672, default_user: admin, default_pass: changeit, vhost: /orders; cluster node name: rabbit@node1, peers: rabbit@node2, rabbit@node3

Output

# rabbitmq.conf
listeners.tcp.default = 5672
default_user = admin
default_pass = changeit
default_vhost = /orders

# definitions.json
{
  "users": [...],
  "vhosts": [{ "name": "/orders" }],
  ...
}

# Clustering (commented; enable and adjust for a real cluster)
# cluster_formation.node_name = rabbit@node1
# cluster_formation.classic_config.nodes.1 = rabbit@node2
# cluster_formation.classic_config.nodes.2 = rabbit@node3

All three sections are labeled and separated in a single output, with definitions.json reusing the same admin user and /orders vhost from the rabbitmq.conf section.

Best Practices & Notes

Best Practices

Change default_pass away from any example or placeholder value before actually deploying, definitions.json will otherwise recreate it verbatim on every fresh startup.
Create a dedicated vhost per application or environment instead of relying on the default '/' vhost for everything.
Uncomment and adjust the clustering section only once you have real peer nodes reachable on the network with a shared Erlang cookie.

Developer Notes

definitions.json is built as a plain JavaScript object and serialized with JSON.stringify(..., null, 2), matching RabbitMQ's own definitions export format closely enough to import directly; rabbitmq.conf uses RabbitMQ's newer dotted-key format (not the legacy Erlang-term advanced.config), and the clustering block always renders as commented lines, substituting placeholder values for node name and peers when the corresponding fields are left blank.

RabbitMQ Config Generator Use Cases

Bootstrapping rabbitmq.conf and a matching definitions.json for a new broker
Pre-seeding a specific vhost, admin user, and password for a fresh deployment via management.load_definitions
Referencing correct cluster_formation dotted-key syntax before configuring a real multi-node cluster

Common Mistakes

Shipping a generated definitions.json to production with an example password left unchanged.
Assuming the commented clustering lines are active configuration, they must be uncommented and given real peer addresses to take effect.
Relying on the default '/' vhost for multiple unrelated applications instead of isolating them with dedicated vhosts and permissions.

Tips

Point management.load_definitions at the generated definitions.json file path in rabbitmq.conf to have RabbitMQ import it automatically on startup.
Use the Kafka Config Generator alongside this one if you're comparing or migrating between RabbitMQ and Kafka for a given messaging workload.

RabbitMQ Config Generator