Virtuelle Hosts zur Mandantentrennung

Sharing one broker across teams or environments risks name clashes and accidental cross-access. Virtual hosts (vhosts) partition a broker into isolated namespaces.

A vhost is a logical grouping of exchanges, queues, bindings, and permissions. Resources in one vhost are invisible to another, even with identical names.

RabbitMQ ships with a default vhost named /. Production setups usually create dedicated vhosts instead of using the default for everything.

Create vhosts via the CLI.

Permissions are scoped to a vhost. Grant a user configure, write, and read access with regex patterns.

Clients select a vhost in the connection parameters; the same credentials may have different rights in different vhosts.

• Queue orders in vhost A is separate from orders in vhost B
• A user without permission on a vhost cannot even see it
• Resource limits can be applied per vhost

Vhosts give logical isolation on shared infrastructure, cheaper than running many brokers, but they share the same node resources (CPU, memory, disk).

You can cap the number of connections and queues per vhost to stop one tenant from starving others.

The management plugin shows metrics broken down by vhost, so you can track each tenant's message rates, queue depths, and connection counts independently.

• One vhost per team or environment
• Least-privilege permission regexes
• Avoid the default vhost for real workloads
• Apply per-vhost limits

Virtual hosts partition a single broker into isolated namespaces with their own resources, permissions, and limits.

Use one vhost per team or environment, apply least-privilege permissions and per-vhost limits, and avoid the default vhost for production traffic.