vCluster Cuts Tenant-Isolation Costs 3x Over One Machine Per Tenant — Here's the Math

Give every tenant on a self-hosted PaaS their own Cluster-API-provisioned machine and you get real isolation — and a bill that scales linearly with tenant count before a single one of them runs a workload. Fifty tenants, fifty idle Kubernetes control planes, fifty machines mostly just keeping kube-apiserver and etcd alive. vCluster's answer, now running at a scale of 40M+ virtual clusters created since 2021 at Adobe, CoreWeave, and NVIDIA, is to put that same isolated control plane — its own API server, its own CRDs, its own RBAC — inside a pod instead of a machine. The concrete question this post answers: how much does that actually save per tenant, and what isolation guarantee does a platform give up to get it?

What a vCluster actually is​

A vCluster is a fully functional Kubernetes control plane — API server, controller manager, a datastore (SQLite, etcd, or the host's own etcd depending on config), and a syncer — packaged as a StatefulSet pod running inside a namespace of a real ("host") cluster. A tenant connecting to their vcluster's kubeconfig sees a cluster indistinguishable from a dedicated one: their own CRDs, their own RBAC bindings, their own version of core resources. Nothing they create is visible in the host cluster's own API unless the syncer explicitly mirrors it down (a Pod, a Service) onto the host's real nodes, which is where the actual containers run.

That syncer is the load-bearing piece. It self-throttles at a default 40 QPS and reconciles only what needs a physical counterpart — Pods and the handful of resource types that need to exist as real workloads on real nodes — while everything else (a tenant's own CRDs, their own controllers, their own RBAC graph) lives entirely inside the virtual API server and never touches the host. That's the mechanism behind "cluster-admin inside your vcluster without touching the host": the privilege escalation surface that namespace-based multi-tenancy exposes (a tenant with cluster-admin in their namespace can often see cluster-scoped objects, CRDs, or RBAC belonging to other tenants) mostly disappears, because there's no shared API server for that escalation to happen against in the first place.

Three tiers, not two​

The honest framing isn't "namespaces vs. vCluster" or "vCluster vs. dedicated cluster" — it's a spectrum with vCluster deliberately sitting in the middle:

A self-hosted PaaS that isolates purely at the namespace level is cheap but has the weakest blast-radius story. One that gives every tenant their own Cluster-API-provisioned machine has the strongest story but pays for idle capacity on day one of every tenant's lifecycle. vCluster's bet is that most of the isolation value of "own control plane" doesn't actually require "own kernel" — and that bet is testable with real numbers.

The worked cost model: 50 tenants, two architectures​

Take a self-hosted PaaS already running Cluster API against Hetzner — the same setup a platform like bex uses for its own node pools — and compare two ways of isolating 50 tenants beyond the namespace level.

Model A — one Cluster-API-provisioned machine per tenant. The minimum viable single-node cluster (control plane and workload combined, as a CAPH-provisioned HCloudMachine) needs at least a shared-vCPU box in the CX22 class (2 vCPU / 4 GB RAM, roughly €4.59/month at current Hetzner list pricing) just to run kube-apiserver, etcd, the scheduler, controller-manager, kubelet, and a container runtime before any tenant workload lands. Fifty tenants:

50 tenants × €4.59/month = €229.50/month

— spent entirely on idle control-plane shells. What's left for actual tenant workloads on a 4 GB box, after Kubernetes' own components take their share (k3s's own component breakdown runs roughly 30% API server, 15% scheduler, 15% controller-manager, 20% container runtime, 10% kubelet, 10% kube-proxy, even on a stripped-down distro), is on the order of 1–2 GB per tenant — and that's before counting the operational cost of reconciling 50 separate Cluster objects, rotating 50 separate sets of certs, and running 50 separate ingress controllers unless a shared load balancer is bolted on separately.

Model B — vCluster on shared Cluster-API-managed nodes. Instead of 50 machines, provision a modest shared pool — three dedicated-vCPU nodes in the CCX23 class (4 vCPU / 16 GB RAM, roughly €85.99/month each) via the same Cluster API machinery:

3 nodes × €85.99/month = €257.97/month for the whole pool

Each vCluster's control-plane pod — API server, controller-manager, and datastore bundled into one process, with vCluster disabling roughly 90% of a full k3s install and reusing the host's own scheduler rather than running a second one — runs at a realistic idle footprint in the 150–350 MB RAM range, well below a standalone k3s node's already-modest ~535 MB idle baseline. Fifty tenants at a conservative 250 MB each:

50 tenants × 250 MB = 12.5 GB RAM for all 50 control planes combined

— against a 48 GB pool (3 × 16 GB), that's roughly 26% of the pool's memory spent on control planes, or about €67/month of the €258/month pool. Divide that across 50 tenants and the control-plane cost per tenant drops to:

€67 / 50 tenants ≈ €1.34/tenant/month

versus Model A's €4.59/tenant/month for a control-plane shell that hasn't run a single workload yet — roughly a 3.4x reduction in isolated-control-plane overhead, and the remaining ~74% of the pool (about €191/month of real, pooled compute) is available for actual tenant workloads instead of sitting idle inside 50 separate underutilized boxes.

That ratio moves with your assumptions — a bigger per-tenant machine in Model A buys more workload headroom per tenant at a worse cost ratio; a more loaded vCluster control plane (heavy CRD usage, high API traffic) pushes past 250 MB and eats into Model B's margin. But across a reasonable range of control-plane sizes (150 MB to 500 MB), the shared-pool model stays 2–5x cheaper per tenant on control-plane overhead specifically, which is the cost namespace isolation gives you for free and dedicated machines charge full price for.

What the savings don't buy: a shared kernel is still a shared kernel​

None of this closes the actual isolation gap between "own API server" and "own kernel." Every vCluster on a host node still shares that node's Linux kernel, and a container escape or kernel-level exploit that reaches the host reaches every tenant on it, regardless of how cleanly the Kubernetes API layer is split. 2026's Januscape flaw (CVE-2026-53359) — a 16-year-old bookkeeping bug in KVM's guest-host memory handling — is a live reminder that shared-kernel boundaries fail in exactly this way: a flaw at the hypervisor or kernel layer turns "isolated at the API level" into "co-resident on the same failure domain" for every tenant sharing that node, independent of whatever RBAC or CRD isolation the Kubernetes layer enforces above it.

vCluster's own materials are direct about this: the isolation is significantly stronger than namespace-based tenancy because tenants never talk to the host's API server at all, but a sophisticated container escape or kernel exploit could in theory still reach the host. The mitigations layer on top rather than replace the model — pairing vCluster with gVisor or Kata Containers for a stronger runtime boundary, or (in newer private-beta tooling like vNode) a defense-in-depth layer aimed specifically at limiting workload escape from the container boundary. None of that is the same guarantee as a dedicated machine's own kernel, and a platform selling isolation to a tenant with genuine compliance requirements — a regulated workload, a noisy-neighbor SLA, a tenant that doesn't trust its co-tenants — still owes them the dedicated-machine tier, not a vCluster with extra padding.

Where this leaves a Cluster-API-based self-hosted PaaS​

The practical shape this suggests for a platform like bex, already running Cluster API against Hetzner for its own node pools: default new tenants to a vCluster running on a shared CAPI-managed worker pool, not a namespace and not a dedicated machine. That gets every tenant real control-plane isolation — their own API server, their own RBAC, no privilege-escalation path into another tenant's resources through a shared control plane — at the shared-pool economics worked out above, roughly a third of the per-tenant cost of spinning up a dedicated CAPI machine for the same tenant on day one.

Reserve the dedicated-machine (or dedicated CAPI-managed cluster) tier for the tenants who actually need it: hard compliance requirements, workloads sensitive enough that "shared kernel, mitigated by gVisor" isn't an acceptable answer, or GPU-heavy tenants where vCluster's own Private Nodes and Auto Nodes features (dedicated worker nodes attached to a single vcluster, provisioned on demand) already point toward a hybrid — virtual control plane, dedicated compute — as the next isolation tier up from fully shared. That escalation path, rather than a single one-size-fits-all isolation model, is what a Cluster-API-managed fleet is actually good at: the same machine lifecycle that provisions a shared worker pool for 50 vClusters can just as easily provision one dedicated node for the one tenant who needs it.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.

Sources​

• loft-sh/vcluster on GitHub.
• vCluster — Kubernetes Tenant Isolation for AI Infrastructure.
• Comparing Multi-tenancy Options in Kubernetes.
• Multi-tenancy in Kubernetes: Comparing Isolation and Costs.
• Namespace vs. vCluster: Which Multi-Tenancy Model is Right for You?.
• vCluster's Performance Paradox: Save Millions, Stay Fast.
• Solving Kubernetes Multi-tenancy Challenges with vCluster (CNCF).
• Tenant Isolation | vCluster.
• How CoreWeave and Loft Labs Leverage vCluster to Run Virtual Clusters in Kubernetes at Scale.
• Januscape (CVE-2026-53359) research note (Cloud Security Alliance).
• Hetzner Cloud pricing.