The Erlang cookie is a shared secret string that RabbitMQ nodes and CLI tools such as rabbitmqctl use to decide whether they may talk to each other. Treat it like a password: owner-only file permissions, a value generated by your automation, and never exposed to the network or committed to a repository.
How it works
The RabbitMQ clustering documentation says nodes and CLI tools use the cookie to determine whether they are allowed to communicate. For two nodes to connect they must hold the same value. The cookie is a string of alphanumeric characters up to 255 characters long, usually kept in a local file.
That file must be accessible only to its owner, with UNIX permissions of 600 or similar. Every node in a cluster needs the same cookie.
Where the file lives
On Linux, macOS and BSD systems, the documentation names two usual places. The server uses /var/lib/rabbitmq/.erlang.cookie, and CLI tools use the .erlang.cookie file in the home directory of the user running them. Because home directories differ, each user who runs the CLI needs a copy, including root. RabbitMQ logs its effective user's home directory early in boot, which helps when you are not sure which file a tool is reading.
Generate it deliberately
If the file does not exist, the Erlang VM creates one with a random value when RabbitMQ starts. The documentation says such generated cookie files are appropriate in development only. In a cluster each node would create a different value on its own, so the strategy does not work for clustering. Generate the cookie at deployment time, ideally with automation or orchestration tooling, and give the same value to every node.
Steps
- Generate a long random value with your secrets tooling, not a word someone chose.
- Deliver it to each node through your secret store at deploy time.
- Set the file mode to 600 and the owner to the service account.
- Limit who has a shell on broker hosts, since a copy of the cookie file plus network access to the node ports is what the mechanism relies on.
- Keep the inter-node ports private. The RabbitMQ ports guide explains why epmd (4369) and the distribution port (25672) should not be public.
- Rotate it when someone with access leaves or when you suspect exposure. Expect a coordinated restart, because all nodes need to match.
Containers and Kubernetes
The community Docker image uses the RABBITMQ_ERLANG_COOKIE environment variable to populate the cookie file. That is convenient, and it creates three mistakes to watch for:
- Putting the value in a Dockerfile or image layer, where anyone who can pull the image can read it.
- Putting it in plain text in a manifest checked into a repository.
- Leaving it in a CI log because a script echoed its environment.
Use your platform's secret object and mount or inject it at runtime. Then check image layers and deployment manifests for the value.
What a leak means
The cookie is not a client credential. Applications publishing and consuming messages authenticate with usernames and passwords on the AMQP listener. The cookie matters for the node and tooling channel, which can act on the node itself. Someone who holds the cookie and can reach that channel can do administrative work, so the combination of a leaked cookie and open inter-node ports is the one to prevent.
Safeguard's asset discovery and policies help find broker deployments and flag configuration in pull requests, and the free scan can look at your repositories for committed secrets and risky dependencies.
Quick check
Can I rely on the auto-generated cookie in production?
No. The documentation says generated cookie files are appropriate in development only, because each node creates its own value and clustering needs a shared one.
Is the Erlang cookie the same thing as the guest or admin password?
No. User passwords authenticate clients and management logins. The cookie authenticates nodes and CLI tools to each other.
Sources
Last reviewed: 19 October 2026.
