Workspace isolation

Each workspace (tenant) is a separate Kubernetes cluster with its own Postgres, Convex backend, HashiCorp Vault, Zitadel identity plane, workflow engine file store, and persistent volumes. There is no shared database or secret store across workspaces on a host. Cluster-per-tenant is the primary segregation boundary for data, credentials, and compute.

Isolation by layer

Layer	Isolation primitive	Per workspace?	Notes
Control plane	Separate k3d (k3s) cluster and API server	Yes	Kubernetes API bound to localhost; not publicly reachable
Compute	Separate Deployments and Pods	Yes	Flow, platform-api, workflow-engine, convex-backend
Data	Separate Postgres, Convex backend, PVCs	Yes	No shared database; volumes on encrypted host storage
Secrets	Separate in-cluster Vault (KV fontana)	Yes	Seeded in-cluster; no shared secrets across tenants
Network	Per-cluster NetworkPolicy default-deny	Yes	Scoped egress per workload
Identity	Self-hosted Zitadel per workspace	Yes	SSO, MFA, and RBAC scoped to the tenant
Ingress and TLS	Host edge terminates TLS per hostname	Yes	Certificate per workspace subdomain (ACME)
Kernel and container runtime	Shared host kernel and Docker daemon	Shared	Soft multi-tenancy boundary (see below)

Soft vs hard tenancy

Cluster-per-tenant delivers strong control-plane, RBAC, secret, and network isolation. Workspaces on the same physical host still share one Linux kernel and one container runtime, so a container escape or kernel vulnerability could theoretically affect other tenants on that box. Fontana treats this as soft multi-tenancy.

Mitigations on shared hosts include NetworkPolicy default-deny, Pod Security baseline, per-workspace Vault paths, image vulnerability scanning, and no cross-tenant secret access.

When your risk model requires hard isolation, deploy a dedicated host with a single workspace (or fewer tenants). The mechanism is the same; the blast radius is smaller because no other tenant workloads share the kernel.

Dedicated host

Managed cloud and customer VPC deployments can pin one customer to one box. Self-hosted operators choose host sizing and tenant count the same way. See Deployment for deployment models.

Platform cluster (shared, stateless)

A platform cluster on each host runs shared edge and stateless services: welcome gateway routing, HyperDX/OTLP collection, Gatus health probes, Docling document parsing, and OpenSandbox code execution for agent MCP tooling.

The platform cluster does not hold workspace databases, Vault secrets, or workflow datasets. Workspace clusters remain the data and secrets boundary.

Documented cross-tenant exceptions

Two platform services are intentionally shared across tenants. Fontana documents compensating controls for each:

Service	Why shared	Primary controls
OpenSandbox MCP	One sandbox control plane per host	Per-tenant bearer auth (ForwardAuth), proxy enforces sandbox ownership fail-closed, digest-pinned base image, sandbox egress restricted to DNS
Docling	Stateless PDF and office parsing	No public hostname; only workflow-engine may call the internal bridge; no durable cross-tenant store

These exceptions affect sandbox execution and in-flight document parsing only. They do not expose one workspace’s database, Vault, or workflow file store to another.

What this means for you

• Blast radius - a compromise or misconfiguration in one workspace does not grant access to another cluster’s data plane through normal application paths.
• Evidence - segregation claims map to separate clusters, Vault instances, and PVCs you can inspect during diligence.
• Graduation path - regulated workloads that outgrow soft multi-tenancy move to a dedicated host without changing the product topology.

Related documentation

• Deployment architecture - platform vs workspace cluster diagram
• Secrets and encryption - per-workspace Vault and encrypted volumes
• Network and hardening - NetworkPolicy and TLS boundaries
• SOC 2 control summary - tenant isolation row in the control matrix