Multi-Tenancy

Multi-tenancy lets a single ProxCenter instance serve multiple isolated organizations, teams, or customers from one place. Each tenant is isolated, while the provider keeps a single, fleet-wide operational view of every cluster.

ProxCenter supports two tenant operating models, and a tenant is created in one of them. The model decides how that tenant consumes infrastructure and what its users see.

The two operating models

You choose the operating model when you create a tenant, in Settings > Tenants. It is fixed at creation and cannot be changed afterward, so pick it deliberately.

Operating model	UI label	The tenant owns...	The tenant sees...	Typical use
MSP	MSP -- Owns whole clusters and connections	One or more entire Proxmox (and PBS) connections	The full cluster view of its own connections, unmasked	Managed service providers giving each customer their own dedicated cluster
vDC (IaaS)	vDC -- Shares clusters via virtual datacenters	A slice of a shared cluster, defined by a virtual datacenter	A masked, vDC-scoped view of a shared cluster	Self-service IaaS where many tenants share the same physical clusters

The two models can coexist on the same instance: some tenants can own dedicated clusters (MSP) while others share infrastructure through vDCs.

Enterprise feature

Multi-tenancy is available in the Enterprise edition and requires the multi-tenancy feature in your license. The Tenants tab is visible only to provider administrators.

The provider (NOC) view

There is always one built-in provider tenant (the default tenant). It is the NOC console, and this is the single most common point of confusion:

The provider keeps full, fleet-wide visibility over every connection, no matter which tenant owns it. Assigning a cluster to a tenant does not remove it from the provider's inventory, dashboard, or reports. That is by design: the provider is the single pane of glass across the whole fleet, with each cluster tagged by its owning tenant.

Per-tenant isolation appears in two other ways instead:

1. By switching into a tenant with the tenant selector (see Switching tenants).
2. Through per-tenant login users, who only ever see their own tenant (see Users and isolation).

So if you have assigned clusters to tenants and "nothing looks different" from your administrator account, that is expected. You are looking at the NOC view. Switch into a tenant, or log in as one of its scoped users, to see the per-tenant experience.

Setting up an MSP tenant

This is the workflow for handing a dedicated cluster to a customer.

1. Go to Settings > Tenants with a provider administrator account and click Add Tenant.
2. Provide a name, slug, and optional description, and set Operating model to MSP. Remember that the model is immutable after creation.
3. Assign the cluster connection(s) to the tenant. By default a connection belongs to the provider pool (the default tenant), so ownership is an explicit choice. You can set it at either of two points:
   • At connection creation: when a provider administrator creates a connection, an owner can be selected directly in the connection dialog. Leaving the owner unset keeps the connection in the provider pool.
   • Later, from the tenant: for a connection already in the provider pool, edit the MSP tenant and, in the Connections section, pick it under Assign connection, then click Add.
4. To take a cluster back, use Release to pool next to the connection in the tenant's owned list. The connection returns to the provider and stays fully operational.

A connection can be owned by only one MSP tenant at a time. Once owned, that whole cluster (its nodes, pools, storages, VMs, and backups) is the tenant's, and the tenant's users get an unmasked full-cluster view of it.

vDC (IaaS) tenants

A vDC tenant does not own a whole cluster. Instead it consumes one or more virtual datacenters, which slice a shared cluster with pools, allowed nodes and storages, networks, quotas, and PBS namespaces.

1. Create the tenant with Operating model set to vDC.
2. Create or assign the tenant's vDC and configure pool membership, allowed resources, quotas, and backup bindings.

A vDC defines:

• Proxmox pool membership
• Allowed nodes, storages, bridges, VNets, and subnets
• CPU, RAM, storage, snapshot, and backup quotas
• PBS namespace and backup job boundaries
• Datacenter assignment for Green IT metrics

See Virtual Datacenters for the full vDC workflow.

Switching tenants

Any user who can access more than one tenant gets a Tenant selector in the top-right profile menu. Provider super admins see every enabled tenant there and can switch into any of them.

Switching tenants reloads the application scoped to that tenant immediately:

• Switching into an MSP tenant shows the full-cluster view of only the connections it owns.
• Switching into a vDC tenant shows its sliced, vDC-scoped view.
• Switching back to the provider tenant restores the fleet-wide NOC view.

tip

The selector only appears once you have access to more than one tenant. If you do not see it, confirm that you have created at least one additional tenant and that it is enabled.

Users and isolation

Assign users to a tenant in Settings > Tenants: edit the tenant and use the Users section to add a user. A newly added user receives a default role (Viewer); set the role you actually want from RBAC.

Super admins are never confined

Super admins are pinned to every tenant by design and always see the whole fleet. A super admin cannot be limited to a single tenant, even if you add them to one. For a login you intend to hand to a customer, use a non-super-admin user with a scoped role. That user will only ever see their own tenant.

Data isolation

Tenant boundaries are enforced across shared services. The boundary is the owned connections for MSP tenants, and the vDC pools for vDC tenants:

• Inventory -- Tenant users see only their owned clusters (MSP) or their vDC pool resources (vDC). Provider administrators see the full hierarchy.
• Deployments -- Requests that reference foreign nodes, storages, bridges, VNets, subnets, or pools are rejected.
• Backups -- PBS archives and PVE backup jobs are scoped to the tenant's owned PBS or its vDC pool and namespace.
• Events and Tasks -- Operational activity is filtered by tenant visibility.
• Reports and Alerts -- Generated and displayed within tenant boundaries.
• Audit logs -- Tenant actions remain attributable, while provider administrators can review activity across tenants.

Isolation also applies when several vDC tenants share the same Proxmox node or cluster.

Tenant lifecycle

A tenant is either active or disabled, controlled by the Active toggle in the tenant dialog:

State	Description
Active	Users can log in and use the tenant's resources
Disabled	Tenant users lose UI access. Proxmox resources, backups, and IPAM are preserved, and the action is reversible

Disable a tenant to suspend access for billing, security review, or offboarding while keeping its configuration intact. The default provider tenant cannot be disabled.

Cross-tenant users view

Provider administrators can use the cross-tenant users view to list every user across all tenants on one page, with tenant assignments, role propagation, and account status. This is useful for MSP support teams managing many customer accounts. Tenant administrators only see users within their own tenant scope.

Settings visibility

Provider-only settings stay hidden from tenant users. Enterprise tabs such as LDAP, OIDC, white-label, notifications, and platform alerts are shown only when relevant to the current user and license.

Licensing across tenants

In MSP deployments you can stack multiple licenses on one install and attribute coverage to each customer tenant. See Licensing for license stacking, cluster mapping, and the per-tenant rollup.

Permissions

Permission	Description
super_admin	Provider-wide access to every tenant and all configuration
admin.tenants	Create, edit, enable or disable tenants, and assign connections and users

Tenant management is also provider-only: these actions are available from the provider tenant, not from inside a customer tenant. See RBAC for scoping roles inside a tenant.