RabbitMQ Virtual Hosts

A virtual host (vhost) is a logical partition inside a single RabbitMQ broker. Each vhost has its own set of queues, exchanges, bindings, and permissions. Applications connected to different vhosts are completely isolated from one another — they cannot see or interact with each other's resources even though they share the same physical broker.

The Apartment Building Analogy

A single apartment building (RabbitMQ broker) houses many separate apartments (vhosts). Each apartment has its own rooms (queues), its own front door lock (permissions), and its own residents (users). Residents in Apartment 3A cannot walk into Apartment 5B. They share the building's infrastructure but live independently.

Why Use Virtual Hosts

• Multi-tenancy: Run multiple independent applications or customers on one broker without them interfering with each other.
• Environment separation: Create separate vhosts for production, staging, and development on the same broker.
• Security isolation: Grant teams access only to the vhost their application uses. A developer cannot accidentally consume messages from the production vhost.
• Namespace clarity: Two teams can both have a queue named orders in their own vhosts without a naming conflict.

The Default Virtual Host

RabbitMQ creates one default vhost on installation: / (a single forward slash). All beginner examples and tutorials use this default vhost. Every new queue, exchange, and binding you create goes into / unless you specify otherwise.

Virtual Host Architecture

[RabbitMQ Broker]
     |
     +-- vhost: /           (default, shared resources)
     |      |-- exchange: orders
     |      |-- queue: order-queue
     |
     +-- vhost: /production  (production app)
     |      |-- exchange: orders
     |      |-- queue: order-queue   (separate from /default)
     |
     +-- vhost: /staging     (staging app)
     |      |-- exchange: orders
     |      |-- queue: order-queue   (completely isolated)
     |
     +-- vhost: /team-alpha  (team alpha's workspace)
            |-- exchange: tasks
            |-- queue: task-queue

The queue named order-queue exists independently in each vhost. Messages in one vhost's queue never appear in another vhost's queue.

Creating a Virtual Host

Using the Management UI

1. Log into the Management UI at http://localhost:15672.
2. Click the Admin tab.
3. Click Virtual Hosts in the left sidebar.
4. Enter a name (e.g., /production) and click Add virtual host.

Using CLI

rabbitmqctl add_vhost /production
rabbitmqctl add_vhost /staging
rabbitmqctl add_vhost /team-alpha

Using the HTTP API

curl -u guest:guest -X PUT http://localhost:15672/api/vhosts/%2Fproduction

Note: URL-encode the slash — /production becomes %2Fproduction in URLs.

Listing Virtual Hosts

rabbitmqctl list_vhosts

Output:

Listing vhosts...
/
/production
/staging
/team-alpha

Assigning Users to Virtual Hosts

Creating a vhost is not enough — users must be granted permission to use it. Permissions are set with three access patterns: configure, write, and read. Each pattern is a regular expression matching resource names.

rabbitmqctl set_permissions -p /production appuser ".*" ".*" ".*"

This grants user appuser full configure, write, and read access to all resources in the /production vhost.

Permission Breakdown

Pattern 1 (configure): resources the user can declare or delete
Pattern 2 (write):     exchanges the user can publish to
Pattern 3 (read):      queues the user can consume from or bindings they can inspect

".*"  = matches everything (full access)
""    = matches nothing (no access)
"^orders$" = matches only the resource named "orders"

Connecting to a Specific Virtual Host

Clients specify the vhost in their connection parameters:

# Python pika - connecting to /production
connection = pika.BlockingConnection(
    pika.ConnectionParameters(
        host='localhost',
        virtual_host='/production',
        credentials=pika.PlainCredentials('appuser', 'secret')
    )
)

Deleting a Virtual Host

rabbitmqctl delete_vhost /staging

Deleting a vhost permanently removes all queues, exchanges, bindings, and messages inside it. This action is irreversible. Always confirm you have no active consumers before deleting a vhost.

Policies and Virtual Hosts

Policies in RabbitMQ are also scoped to a vhost. A policy that sets message TTL on all queues in /production does not affect queues in /staging. This makes per-environment configuration clean and independent.

rabbitmqctl set_policy -p /production TTL ".*" '{"message-ttl":86400000}' --apply-to queues

Monitoring Virtual Hosts

In the Management UI, the Virtual Hosts section under the Admin tab shows each vhost with its current queue count, message count, and in/out message rates. You can switch the view in the Queues and Exchanges tabs to filter by vhost using the dropdown at the top of each tab.

Summary

Virtual hosts partition a single RabbitMQ broker into isolated namespaces. Each vhost has its own queues, exchanges, bindings, and permissions. The default vhost is /. Create additional vhosts for different environments (production, staging, dev) or different teams. Assign users to vhosts using set_permissions with configure, write, and read patterns. Clients specify the vhost when opening a connection. Deleting a vhost destroys all its contents permanently.