Skip to main content

Multiple Tenant

Overview​

YedMQ's multi-tenant model lets one broker deployment serve multiple logical organizations while keeping data paths isolated. Tenant identity affects sessions, topics, retained messages, and management APIs.

By default, connections that are not assigned a tenant use the public tenant.

What is isolated per tenant​

  • topic namespace and routing
  • client session identity
  • retained messages
  • REST resources such as clients, topics, and publish operations

A client ID only needs to be unique inside its tenant.

How tenant assignment works​

Tenant assignment is driven by the authentication plugin. During a client connection, the plugin can inspect values such as:

  • username and password
  • client ID
  • client IP
  • other connection metadata available to the authenticate request

The plugin returns an AuthenticateResponse, which can include tenant_id.

message AuthenticateResponse {
    bool authenticated = 1;
    // ...
    optional string tenant_id = 5;
}

If no plugin supplies a tenant ID, YedMQ keeps the connection in public.

Dynamic tenant creation​

YedMQ creates tenant-scoped state on demand. When a new tenant ID appears through authentication or subsequent tenant-scoped activity, the broker initializes the required internal structures automatically.

Tenant-scoped REST API paths​

Common management paths include:

  • GET /api/v1/{tenant_id}/clients
  • GET /api/v1/{tenant_id}/topics
  • GET /api/v1/{tenant_id}/messages/retained
  • POST /api/v1/{tenant_id}/messages
  • POST /api/v1/{tenant_id}/clients/{client_id}/kickoff

This path structure makes cross-tenant operations explicit instead of implicit.