"Isolated" should mean something.
Plenty of hosts describe shared infrastructure as isolated. Here is what the word means on this platform, layer by layer, so you can check it rather than believe it.
Around your site
Its own namespace
Each environment gets a Kubernetes namespace of its own, with a resource quota so one site cannot eat the node, and a limit range so a pod cannot ask for everything.
Its own database and user
A database per site, and a user granted on that database alone. The credentials your site holds cannot read any other site's data — not because of a WHERE clause, because the grant does not exist.
Default-deny networking
The network policy denies ingress and egress by default and then allows only what is needed: traffic from the ingress controller, and the database. A compromised plugin cannot scan the cluster.
Restricted pods
Pod Security Admission at the restricted level: no privilege escalation, no root, dropped capabilities. Enforced by the cluster, not requested by the manifest.
Inside the control plane
The database that knows about every customer is the one that has to be hardest to get wrong.
Row-level security, forced
Every table with customer data has a policy scoping it to the organisation in
the current transaction — and FORCE ROW LEVEL SECURITY, so it
applies to the table's owner too. A missing WHERE clause is not a
data leak; it returns nothing.
Proven on every change
Four coverage assertions and a 35-assertion isolation suite run in CI and again during installation. A table added without a policy fails the build. A deployment where they do not pass does not finish.
The tenant comes from the session
Never from the request. An endpoint that accepted an organisation identifier would be a cross-tenant read the customer performs on themselves.
Append-only audit
Audit rows cannot be updated or deleted by the application role. That is a database privilege, not a policy in code that a future change could quietly drop.
In your browser
The session cookie cannot reach your sites
The panel's session cookie is host-only with the __Host- prefix,
so the browser itself refuses to send it to any other subdomain. Customer
sites run on a separate registrable domain, so a site cannot set a cookie the
panel would read either.
The API has no cookie
The public API is stateless and authenticated with keys. There is no cookie-authenticated twin of it, which is an entire class of cross-site request forgery that cannot apply.
What we do not claim. Sites share a node's kernel — this is container isolation, not a virtual machine per customer. If your threat model needs a hypervisor boundary, say so and we will talk about dedicated infrastructure rather than sell you something that does not fit.
Questions about any of this?
We would rather answer them before you move than after.