Namespace Per Customer Kubernetes Beyond Namespace Boundaries
Move beyond a namespace per customer for Kubernetes services. vMetal supplies machines, and vCluster provides separate tenant APIs with dedicated workers through Private Nodes.
Move beyond a namespace per customer for Kubernetes services. vMetal supplies machines, and vCluster provides separate tenant APIs with dedicated workers through Private Nodes.
Namespace per customer Kubernetes shares control-plane and often worker-node components between customers.
Namespaces share the Kubernetes API server and cluster-level components between customers.
A separate management stack for every customer increases infrastructure and operational work.
Building custom tenant isolation requires ongoing work across access, capacity, networking, observability, and lifecycle operations.
A namespace per customer still shares a Kubernetes API. vCluster moves customers to independent tenant control planes with dedicated Private Nodes; vMetal supplies machines and Platform coordinates fleet operations. Lintasarta runs 170+ tenant clusters in production.
Move beyond namespace per customer Kubernetes with separate tenant control planes, Private Nodes, and centralized operations.
Private Nodes dedicate worker capacity to one tenant cluster, with its own CNI and storage configuration. For namespace migration, select physical servers or VMs according to the required infrastructure boundary.

Each customer receives a separate virtualized API server and RBAC boundary on the control plane cluster.

Tenant clusters use a certified Kubernetes distribution and standard APIs for existing tools, CRDs, and operators.
vNode uses Linux user namespaces and seccomp to restrict workload privileges and system calls. It adds runtime hardening for namespace migration without a guest kernel or hypervisor, complementing dedicated workers rather than allocating GPUs.

vCluster Platform supports air-gapped deployments and FIPS features on supported plans for controlled environments.

This isn’t a side project. Behind every vCluster deployment is 5+ years of deep K8s engineering, security hardening, and battle-tested infrastructure work at massive scale.
Talk to our team about your stack
Deploy vCluster on your infra in minutes
Go live with a hyperscaler-grade tenant experience in days
Namespaces divide resources within a Kubernetes cluster, but share its API and cluster-wide administrative scope. RBAC, quotas and network policies remain useful controls. vCluster adds a separate tenant API and data store, with Private Nodes dedicating production workers. This reduces dependencies between tenant environments while platform administrators still manage the underlying infrastructure and its failure domains.
vCluster gives each tenant an independent Kubernetes API, data store and RBAC scope. Private Nodes dedicate worker capacity to that tenant, including its own CNI and storage configuration. vMetal orchestrates the machines underneath. This separates tenant administration and worker placement; shared infrastructure, application permissions and network policies still require an explicit security design.
Tenants can receive cluster-admin within their own Kubernetes environment, including permission to install CRDs and supported operators. With Private Nodes, worker-level GPU tooling belongs to that tenant's dedicated nodes. Platform administrators retain infrastructure controls and define supported configurations. Private Node clusters do not sync workload resources to the control plane cluster, so integrations must support direct tenant worker operation.
Supported plans include air-gapped deployment and FIPS features. Private Nodes, tenant-scoped access and optional network segmentation provide controls you can include in a regulated deployment. Select supported images and configurations, and validate the full environment against your requirements. These capabilities do not establish certification of the customer's service, application, hardware or operational procedures.
A tenant control plane and its worker capacity have different readiness requirements. Existing provisioned workers can shorten onboarding, while new machines require the selected infrastructure driver's provisioning workflow. Templates, networking, storage and GPU drivers must also be ready before workloads can run. Configure Private Nodes when creating the tenant cluster, and validate application readiness separately from Kubernetes API availability.
vCluster Platform coordinates tenant environments through a central UI, CLI and API. Operators use templates, access policies and quotas while each Kubernetes tenant retains its own API and dedicated production workers. vMetal manages supported machine provisioning below the fleet. Operational consistency still depends on template configuration, version management and the monitoring and recovery workflows you connect to the platform.
See how vCluster Platform replaces namespace per customer Kubernetes with tenant clusters on Private Nodes.