A fresh RabbitMQ node creates a user named guest with the password guest, and by default that user can only connect from the same machine. Remote logins are refused on purpose. Do not lift the limit. Delete guest in production and create named users for each application and each administrator.
What the default does
According to the RabbitMQ access control documentation, guest has full access to the default virtual host, named /. The restriction to loopback comes from the loopback_users setting, which lists guest by default. If a remote client tries to log in as guest, the broker refuses and logs a message saying the user can only connect via localhost.
This is a sensible default because the credentials are public knowledge. Anyone who can reach the port and who finds guest enabled would own every queue in the default vhost.
Why not set loopback_users to none
The documentation says setting loopback_users to none allows remote guest logins and strongly advises against it. People do it anyway to get a tutorial working, then the setting travels into a staging file, then into production. A well known password plus a reachable port is the worst case.
If a tutorial fails with the localhost error, the fix is a new user, not a weaker guest.
What to do instead
The RabbitMQ production checklist gives the direction. Delete the default guest user and create a separate administrative user with a generated password. Then give every application its own user, so you can tell connections apart, apply tighter permissions and roll credentials one service at a time.
A practical order of work:
- Create the new administrative user and confirm you can log in with it.
- Create one user per application, each with permissions on only the vhost it needs.
- Delete guest.
- Check that no client configuration still points at guest, because those clients will start failing.
- Restrict network reach so only application hosts can talk to the client ports.
Note one detail from the access control page: if a node imports definitions on boot, no default user is created at all, so check what your definitions file actually contains.
Two traps
First, permission changes may not apply to existing connections until the client reconnects, since checks can be cached per connection or channel. After you tighten a user, restart the connection.
Second, anonymous login is a separate setting. The ANONYMOUS mechanism, if left on, lets clients connect as the configured anonymous login user, which is guest by default. Read the sibling post on auth mechanisms to disable before you call the job done.
Where this fits
Broker defaults are tuned for a developer laptop. A short hardening pass before the first real traffic is cheap compared with explaining an open broker later. For the wider picture, see message queue security for Kafka and RabbitMQ.
Safeguard can help here in a small way. Its SBOM and dependency scanning covers the broker client libraries and service frameworks your code pulls in, and reachability analysis shows which advisories your services actually call. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Can I just change the guest password instead of deleting the user?
You can, and it is better than leaving the default, but the production checklist recommends deleting it. A deleted user cannot be guessed or reused by a stale config.
Why does my app fail with a localhost error?
It is connecting as guest from another host. Create a named user with the permissions it needs and point the app at that.
Sources
Last reviewed: 19 October 2026.
