Learn RabbitMQ - Virtual Hosts & Multi-Tenancy

#Introduction

When a small team uses RabbitMQ, one unlimited space is enough. But once the team grows, or you run development, staging, and production at the same time, everything starts stepping on each other: queues with the same name from different environments collide, and user permissions become uncontrollable.

Virtual Hosts (vhosts) are RabbitMQ's answer to this problem. A vhost is a logical namespace that isolates resources: queues, exchanges, bindings, and user permissions in one vhost are invisible and inaccessible from other vhosts. A single RabbitMQ instance can host dozens of vhosts without interfering with each other.

This episode covers how to create and manage vhosts, design correct multi-tenancy patterns, manage per-vhost access, and best practices for naming, resource allocation, monitoring, and backup. With well-managed vhosts, one broker can safely serve an entire organization.

#Virtual Hosts Concepts

#Logical, Not Physical

It's important to understand: a vhost is logical isolation, not physical. All vhosts still share the same memory, disk, and CPU within a single node. Vhosts provide namespace and permission isolation, not isolated resource guarantees — for that you need separate nodes or your own cluster.

#The Default Vhost

RabbitMQ has a built-in vhost named /. The guest user only has full access to this vhost. Many beginner teams use the / vhost for everything — this is what triggers name collisions and permission problems. Start creating your own vhosts from the beginning.

#Creating and Managing Vhosts

#Basic Vhost Commands

Create a vhost and set up users inside it:

rabbitmqctl add_vhost staging
rabbitmqctl set_permissions -p staging arman '.*' '.*' '.*'
rabbitmqctl list_vhosts name

The rabbitmqctl add_vhost command creates a vhost, and set_permissions -p staging gives the user arman full rights inside it. Users without permissions won't be able to connect to that vhost.

#Deleting a Vhost

Deleting a vhost automatically deletes all resources inside it — queues, exchanges, bindings, and permissions:

rabbitmqctl delete_vhost staging

The delete_vhost command is destructive. Make sure you've backed up the definitions (episode 31) before deleting a vhost containing important data.

#Multi-Tenancy Patterns

#Per-Environment vs Per-Tenant

Two common isolation patterns:

Per-environment: separate vhosts for dev, staging, and prod. This pattern prevents development code from sending messages to production queues. Highly recommended even for small teams.

Per-tenant: for SaaS, create one vhost per tenant. Each tenant has its own queues and exchanges with isolated permissions. Watch the cost: hundreds of vhosts add metadata overhead, so limit the number of vhosts per node and monitor performance.

#Connection URIs with Vhosts

The vhost is part of the connection URI, written after the first slash. Special characters like / are URL-encoded as %2f:

amqp://arman:password@localhost:5672/staging
amqp://arman:password@localhost:5672/%2f

The first URI connects to the staging vhost; the second connects to the / vhost — which must be written as %2f because the slash character belongs to the URI.

#Per-Vhost Access Control

Permissions are per-vhost: the same user can have full rights in dev but only read access in prod. The details of the configure, write, and read permissions are covered in episode 16. The principle: never give one user full access to all vhosts without a reason.

#Vhost Best Practices

#Resource Allocation and Monitoring

Although vhosts don't isolate physical resources, you can limit their impact: set limits per vhost to protect the broker from greedy tenants. RabbitMQ supports rabbitmqctl set_vhost_limits:

rabbitmqctl set_vhost_limits -p tenant_a '{"max-connections":100,"max-queues":1000}'

#Per-Vhost Monitoring and Backup

Monitor per-vhost metrics in the Management UI — every vhost has its own tab with its own queue depth and message rate. For backup, export definitions per vhost so recovery only touches the broken part:

curl -u arman:pass -H "content-type: application/json" \
  http://localhost:15672/api/definitions/staging > staging.json

The curl command above downloads all of the staging vhost's definitions into a JSON file for backup purposes.

#Conclusion

In episode 13 you understood vhosts as logical namespaces, created and managed vhosts with rabbitmqctl, designed per-environment and per-tenant isolation, managed per-vhost permissions and limits, and set up per-vhost definitions backup.

Key takeaways:

• Vhosts isolate resources and permissions logically, not physically.
• Don't use the / vhost for everything — create your own vhosts.
• Per-environment isolation prevents cross-environment message mishaps.
• Per-tenant vhosts suit SaaS with permission isolation.
• Vhost URIs are written after the slash; / becomes %2f.
• set_vhost_limits limits the impact of greedy tenants.
• Per-vhost definitions backup makes partial recovery easy.

In the next episode we will discuss flow control and backpressure — how RabbitMQ protects itself from overload with TCP backpressure, credit-based flow control, memory alarms, and the connection blocked state, complete with publisher confirms and publisher throttling strategies. This is the key to preventing the broker from falling over under high traffic!