- vCluster gives each tenant a real Kubernetes control plane while sharing, dedicating or privately attaching the machines underneath.
- The open-source runtime is free. Enterprise revenue comes from management, stronger isolation models, support and the operating layer around it.
- The idea emerged after the founders' first platform product failed and exposed the awkward choice between weak namespaces and expensive clusters.
- It works best where cluster count, idle capacity or tenant autonomy is already painful. Small, trusted installations may not need the extra layer.
There is a particular kind of cloud bill that feels less like a bill than a census. It counts things that exist whether or not anyone is using them: a control plane here, an Istio installation there, a monitoring stack humming through Saturday night. One Kubernetes cluster is sensible. A hundred clusters become a population. Each has a government, a civil service and, in the case of the public clouds, a small annual tax before the first useful workload appears.
Lukas Gentele and Fabian Kramm met this population in 2019 while building a platform-as-a-service. The product failed. That is the first important fact about vCluster because it explains the company's habit of looking underneath the product it thought it was making. Their PaaS had to run a large, shared Kubernetes system. Tenants wanted autonomy. Operators wanted standards. Namespaces were economical but not separate enough; individual clusters were separate but costly and tiresome. The failed product did not produce a market. It produced a diagnosis.
They tried Kiosk, an early open-source multi-tenancy project, then spent roughly a year in research and pilots. In April 2021 they released vCluster. The peculiar idea was to run a Kubernetes control plane as a workload inside another Kubernetes cluster. A tenant would talk to its own API server, install its own custom resources and manage its own permissions. A syncer would translate the necessary objects into the host below. The machines could be shared. The experience above could still feel like a cluster.
“Virtual clusters allow you to fulfill the increasing demand for Kubernetes clusters without ending up with thousands of underutilized and heavyweight ‘real’ Kubernetes clusters.”Lukas Gentele, co-founder and CEO
The trick is preserving the boundary people care about
The phrase “virtual Kubernetes cluster” sounds redundant. Kubernetes already abstracts machines. But vCluster is not chiefly virtualizing the server; it is virtualizing Kubernetes itself. The user keeps the API boundary that matters - control-plane state, RBAC, CRDs, admission rules - while the operator decides how much of the infrastructure below must truly be separate.
This middle position is vCluster's real product. A namespace is cheap but shares the host API and cluster-scoped resources. A conventional EKS, GKE or AKS cluster is familiar and strongly separated, but repeats control planes and platform services. vCluster keeps more autonomy than the namespace and less machinery than the conventional fleet. It also lets operators move along an isolation spectrum: shared nodes for density, dedicated nodes for predictability, or Private Nodes that belong to one tenant and carry their own network and storage arrangements.
What did it cost? Start with the empty room
In Gentele's 2024 account, a public-cloud control plane could cost about $900 a year. That is not a complete cluster bill; it is the cover charge. Add worker nodes, ingress, observability, security agents and the cluster-wide software copied into every environment. The awkwardness grows in development and test, where clusters may sit idle through nights and weekends but must remain ready for Monday morning.
The cleaner evidence comes from customers with an obvious before picture. Atlan hosted its software in roughly 100 EKS clusters, one per customer, because customers in finance and healthcare demanded separation. After moving to vCluster, Atlan reported cutting its number of “real” clusters by 99 percent and its Kubernetes spend by $600,000. A large insurer tested vCluster's sleep mode across pre-production environments and reported a 65 to 75 percent cost reduction in the proof of concept, with more than $6 million in projected annual savings if rolled across 200 clusters.
Selected customer-reported change
Those are case-study outcomes, not a universal discount coupon. Savings depend on having enough duplicated or idle infrastructure to consolidate. The commercial price is equally contextual. The open-source runtime costs nothing, and a free platform tier covers unlimited virtual clusters within published CPU, GPU and high-availability limits. Enterprise pricing is custom, sold with support, stronger tenancy features, auditability, SSO, optional service levels and either hosted-control-plane or self-hosted deployment.
The company followed the bottleneck down the stack
For its first years, the company was called Loft Labs. The project was called vCluster. This eventually became a naming problem of the pleasant sort: people remembered the product more readily than the business. In August 2025, Loft Labs became vCluster Labs. The legal entity remains Loft Labs, Inc., doing business under the newer name.
By then the product line had started moving downward. vCluster isolated the control plane. vNode, introduced in 2025, tackled workloads on shared machines using Linux user namespaces, seccomp and other kernel controls. vMetal, introduced in March 2026, moved lower still, automating discovery, provisioning, assignment and lifecycle management for bare-metal GPU servers. The progression is almost geological: API, process, machine.
That explains why the company now talks so much about AI clouds. GPU providers do not merely need to schedule expensive chips. They need to turn racks into a product: give each customer an isolated environment, attach the right nodes, configure networks and storage, replace hardware, and do all of it before the hardware depreciates into yesterday's premium. vCluster says its stack now runs across more than 50 GPU clouds and Fortune 500 customers, covering over 100,000 GPUs and one million CPUs in production.
The parts worth copying
The obvious temptation is to copy the recursion: find something already virtual and virtualize it again. That is not the lesson. The useful move is to identify which boundary the user values and which machinery has become accidental duplication.
- Count the fixed tax, not just consumption. Control planes, agents, upgrades and platform services cost money and attention even when application usage is near zero.
- Preserve the interface people trust. vCluster did not ask Kubernetes users to learn a toy approximation. It kept a conformant Kubernetes API and moved the sharing underneath.
- Let failure expose the deeper problem. The PaaS failed first. What changed the founders' minds was living with its multi-tenant infrastructure, then seeing why the usual namespace-or-cluster choice was unsatisfying.
- Offer a spectrum, not one security claim. Density and isolation pull in opposite directions. Shared, dedicated and private node models let buyers choose where to sit.
There are conditions where the idea adds little. A small team with one cluster, trusted users and no meaningful cluster sprawl may gain more concepts than savings. Workloads requiring complete physical separation may still belong on separate infrastructure. Teams unwilling to operate or understand an additional synchronization layer should price that complexity honestly. And no amount of virtual control-plane isolation makes a shared kernel equivalent to dedicated hardware for untrusted tenants.
But at scale, the company's argument is hard to unsee. Fleet management can make a thousand clusters more orderly. It cannot make them stop being a thousand clusters. vCluster's wager was that the unit itself could change. One failed product, one strange layer of recursion, and suddenly the cluster was no longer a pet or even cattle. It was something closer to a browser tab: real enough to work in, cheap enough to close.