Tenant isolation
Why instances default to a KVM VM, why a shared kernel is not a tenant boundary, and the three network controls every node class enforces so tenants can't see, reach, or spoof each other.
SpipCP is built for selling hosting to many tenants: instances holding untrusted tenant content can run next to each other on one node, and the boundary between them holds. Two things make that real — instances default to a KVM VM, and every node class keeps tenants apart on the network.
VM by default, container by exception
Every instance is one of two types:
| Type | What it is | When |
|---|---|---|
| VM (KVM) | Hardware-virtualised — its own kernel, isolated from the host and its neighbours. | The default. Safe for untrusted tenant content; required when several tenants share one node. |
| Container (LXC) | Shares the host kernel. Lighter, denser. | A single-tenant opt-in — one owner's workloads only. |
A shared kernel is not a tenant boundary
An LXC container shares the host kernel, so a kernel bug becomes a way to take over the host — and from there, every other container on it. A container is not a safe boundary for untrusted tenant content. That's why VM is the default and container is labelled one tenant per node in the create dialogs — appropriate only for workloads under one owner's direct control.
This is the same for every class — vps, dedicated-single-ip, and dedicated-multi-ip all default to
VM and all allow container as the trusted opt-in. See Node topology for the
full capability table.
One tenant per kernel
The whole model reduces to one sentence: a kernel is only ever shared within a single tenant.
- A container node is a one-tenant box. One owner, any number of that owner's apps — a client with five sites, a team with a stack of services. Every container on the node shares its kernel, so the only wall between containers is the kernel itself. That is acceptable exactly when everything behind that wall already belongs to the same owner: a breach can only reach what the owner already controls.
- Two tenants on one node means VM instances. Each VM brings its own kernel behind hardware virtualisation — the boundary real multi-tenant hosting requires. A kernel bug inside one tenant's VM stays inside that VM.
Two practical consequences follow:
- VMs live on bare metal in practice. A cloud VPS is itself a VM; running KVM inside one needs nested virtualisation, which most providers disable. So the common shapes are: cloud VPS → container instances → a single-tenant node, and dedicated bare metal → VM instances → a multi-tenant node. The metal is not what adds the boundary — the VM is. A dedicated box filled with container instances is still a one-tenant box, however large it is.
- Docker inside a container relaxes the hardening further. Running a docker engine inside LXC
requires
security.nesting, and on distribution Incus builds an unconfined AppArmor profile for that instance. Both are sound trade-offs for a tenant's own workloads — and one more reason a container node must never carry a second tenant.
The create dialogs state the same rule at the moment of choice: the instance-type options read “VM (KVM) — own kernel, required for multiple tenants” and “Container (LXC) — shared kernel, one tenant per node”.
The network boundary
A VM isolates the compute. The other half is the network: tenants share a node's NAT bridge, so the bridge itself has to keep them apart. Every class enforces three controls:
| Control | What it stops | How |
|---|---|---|
| L2 isolation | One tenant scanning or talking to a neighbour on the local network. | The shared bridge gives tenants no direct link to each other. |
| Egress firewall | A guest reaching the node's management (the panel, the worker). | A guest can reach the internet but cannot reach host management. |
| Anti-spoof | A tenant faking a neighbour's IP or MAC. | Each interface is pinned to its own address. |
So a tenant can't see its neighbours, can't reach the control plane, and can't impersonate another address. All three are on for every class.
The boundary belongs to the node class
The isolation rules are part of the node's class, so what the agent applies and what the instance workspace displays come from the same source. It's a property of the node class, not a per-instance toggle that can be forgotten.
Next steps
- Node topology classes — how a node declares what it is and what each class can deliver.
- Instances — creating VM or container instances on a node.
- Site owners — the next isolation layer down: a per-site Linux owner inside an instance.
Node topology classes
A node declares what it is when it's added — VPS, single-IP dedicated, or multi-IP dedicated. The class decides how instances are reached and what instance creation can offer.
IPv6 & IPv6-only nodes
SpipCP runs end to end over IPv6 — including on an IPv6-only box with no public IPv4. The panel, agents, child instances, and hosted sites all work, and normal IPv4 nodes are completely unchanged.