AMQP Virtual Host Boundary Workbench

Trace how RabbitMQ virtual hosts scope connections, resource names, and configure/write/read permissions inside one shared broker.

animation
amqp
protocols
messaging
security
Interactive RabbitMQ virtual host animation showing logical resource isolation, per-vhost permissions, duplicate resource names, cross-vhost blocking, and the bridge pattern that requires separate connections to each vhost.
AMQP RabbitMQ Virtual hosts Permissions

Virtual Host Boundary Workbench

Use one broker with several virtual hosts, then watch how a client connection is limited to the vhost it selected. The important idea is logical isolation: resource names, bindings, policies, and permissions are scoped per vhost, while the broker process and cluster are still shared.

Connection vhost /production
User device-prod
Decision Allowed publish
Boundary type Logical, not physical

Allowed publish inside /production

A production device publishes telemetry to an exchange and queue that both belong to the same vhost as the connection.

Allowed
1Connectdevice-prod to /production
2Authorizewrite matches telemetry.topic
3Routeexchange to queue
4Explainstays inside boundary
RabbitMQ virtual host isolation animation A shared broker contains three virtual hosts. A message token travels from a client to resources inside the selected vhost, or stops at a boundary when the scenario is not allowed. One RabbitMQ broker / cluster Shared process and infrastructure; virtual hosts provide logical namespaces and scoped permissions.
allowed operation blocked by vhost or permission boundary deliberate bridge with two connections exchange or queue scoped to a vhost

Controls

Decision Inspector

Allowed: write is scoped to /production

The user is connected to /production and has write permission that matches the target exchange name.

Required check write exchange
Boundary result same vhost

/production resources

Exchanges

Queues

Users and permissions

Trace Log

1. Pick a vhost

The AMQP connection chooses exactly one virtual host. All resource operations are interpreted inside that namespace.

2. Read the names

The same queue or exchange name can exist in two vhosts without being the same resource.

3. Check permissions

Configure, write, and read permissions are regular-expression grants scoped to the selected vhost.

4. Watch the boundary

Cross-vhost access is blocked unless an application deliberately opens separate connections to both vhosts.

Connection Scope

An AMQP client supplies a vhost name during connection setup. After that, the connection operates only on exchanges, queues, bindings, and policies in that vhost.

  • Use one connection per vhost.
  • Open two connections for bridge behavior.
  • Do not treat vhosts as separate brokers.

Resource Names

Resource names are local to a vhost. A queue called telemetry.q in /production is a different queue from telemetry.q in /staging.

  • Bindings stay inside one vhost.
  • Policies apply only where defined.
  • Deleting a vhost deletes its entities.

Permission Triple

RabbitMQ grants configure, write, and read permissions as regular-expression patterns per user per vhost.

  • Configure: declare, delete, bind.
  • Write: publish into resources.
  • Read: consume or get messages.

Logical Isolation

Vhosts separate names and permissions. They do not provide separate CPU, memory, disk, failure domain, or compliance boundary by themselves.

  • Use limits and monitoring for noisy-neighbor risk.
  • Use separate clusters for stricter isolation.
  • Use descriptive vhost names.

IoT Uses

Vhosts are useful when teams need separate environments or trust zones but can share the same RabbitMQ installation.

  • /production for live devices.
  • /staging for test devices.
  • /iot-devices for constrained device groups.

Common Mistake

Seeing the same queue name in another vhost does not mean the current connection can consume from it. It must reconnect to that vhost with suitable permissions.

  • Check connection vhost first.
  • Then check permission regex.
  • Then check target resource name.
Learning Support
For beginners

Think of each vhost as a named room in the same building. Objects with the same label can exist in different rooms, but a connection can only touch the room it entered.

For implementers

Connection failures often come from a missing vhost grant, while channel/resource failures often come from configure, write, or read regex mismatches.

For architects

Use vhosts for administrative separation. Use separate brokers or clusters when the risk is physical resource isolation, independent scaling, or different service-level boundaries.

Technical Accuracy Notes
AMQP connection

The client names the target vhost when connecting. Successful authentication is not enough; the user must have permission to use that vhost.

Cross-vhost transfer

RabbitMQ does not route a single operation from one vhost into another. A bridge application can consume from one connection and republish through another.

Permission scope

Permission management is scoped to one vhost at a time. A user can have broad access in one vhost and no access in another.