Tenant isolation

Isolation is layered. Each layer is described with what it actually enforces, so you can judge the whole rather than take a word for it.

1. API scope

Every query is filtered by organisation at the data-access layer, not by a check sprinkled through handlers.

A resource belonging to another organisation returns 404, not 403 — its existence is not disclosed. An attacker enumerating identifiers learns nothing, including whether an identifier is valid.

Alone this stops: cross-tenant reads and writes through the API. Alone this does not stop: anything below the API — network reachability, hypervisor access.

2. Network

A private network is an isolated layer-3 domain — with EVPN, its own VRF. Two organisations’ networks cannot route to each other, and this remains true when they share a gateway appliance, because forwarding there is default-deny with explicit per-leg rules.

Subnet tiers add a second, structural control: a data tier subnet can never have internet egress. Attaching a gateway to one is refused by the API. This is the cheapest compliance control available — your database subnet cannot acquire an egress path through a future misconfiguration, because there is no configuration that produces one.

Alone this stops: lateral movement between tenants at the network layer. Alone this does not stop: an attacker who has the hypervisor.

3. Hypervisor

Virtual machines are ordinary Proxmox guests with KVM isolation. Firewall rules are enforced by the hypervisor, outside the guest — a compromised machine cannot disable its own rules.

Resources are grouped and tagged per organisation, so ownership is visible in the Proxmox UI. That is an auditability property as much as an isolation one: an operator can attribute every machine without consulting the panel.

Alone this stops: guest escape being needed for policy bypass; a compromised VM turning off its own firewall.

4. Region

Regions are independent. Nothing crosses them — not networks, not addresses, not images, not migration. An installation can also restrict a region to specific organisations, for operators who want dedicated capacity for a customer.

Shared components, named honestly

Two things are shared, and pretending otherwise would be dishonest:

The control plane database. All organisations’ intent lives in one PostgreSQL instance, separated by row scoping rather than by separate databases. A control-plane compromise is therefore a multi-tenant event.

The hypervisor cluster. Tenants share physical machines unless an operator dedicates nodes. This is normal for virtualisation and it is the boundary KVM provides.

If your requirements do not permit shared infrastructure, the answer is a dedicated region — which the product supports — not a configuration flag.

What is not isolated

• Noisy neighbours. There is no per-tenant IO or network quality-of-service. A neighbour generating heavy disk traffic affects you the way it would on any shared virtualisation platform.
• Capacity. There is no per-organisation reservation. Placement decides where a machine lands, not how much of the node it may consume beyond its plan.