Design customer tiers around capacity and service needs. vMetal provisions machines, and vCluster gives every customer tier dedicated Private Nodes with optional vNode runtime hardening.
Capacity, support and runtime requirements can differentiate customer tiers while dedicated workers remain the production foundation.
GPU quantity, support and runtime controls influence service tiers. Dedicated tenant workers can underpin several pricing and service options.
Namespace boundaries suit internal teams who already trust each other. Paying customers running arbitrary workloads on your GPUs need a stronger boundary.
Separate physical clusters give you the boundary but multiply hardware cost, ops burden and onboarding time with every tenant you add.
Operators can define service tiers using capacity, support and runtime controls. Every external customer receives dedicated Private Nodes and an independent tenant control plane; vMetal supplies machines and vNode adds optional hardening. vCluster Labs software powers 100K+ GPUs.
The control plane model is the same for every tenant. The tier decides how many boundaries sit around their workloads.
Each tenant has an independent Kubernetes API, data store and RBAC boundary. Lightweight control-plane hosting reduces dedicated server requirements for operator-defined service tiers; Private Nodes keep production workers tenant-specific.
Trusted internal development and CI can use operator-controlled worker pools with separate tenant APIs. External customers use dedicated Private Nodes. Internal GPU configuration and worker policies remain under the platform operator’s control.
Each customer service tier uses dedicated worker capacity through Private Nodes. Operators can choose physical servers or supported VMs, then differentiate capacity, support and runtime controls. These are operator-defined services rather than fixed vCluster pricing packages.
vNode uses Linux user namespaces and seccomp to restrict workload privileges and system calls. It adds runtime hardening for operator-defined service tiers without a guest kernel or hypervisor, complementing dedicated workers rather than allocating GPUs.
Coordinate tenant environments for operator-defined service tiers through one UI, CLI and API. Templates, access policies and quotas provide central operator controls while tenant Kubernetes APIs and dedicated production workers remain separate.
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
vCluster supports multiple customer environments through separate Kubernetes APIs, data stores and administrative scopes. Private Nodes dedicate production worker capacity to each customer, while vMetal orchestrates machines. Operators can define service tiers around GPU capacity, support and optional runtime hardening. Those tiers are examples of service design, rather than official standard and hardened vCluster product packages.
Service tiers are defined by the operator rather than fixed vCluster packages. Capacity, support levels and runtime controls can differentiate offerings while every external customer uses Private Nodes. An optional hardened configuration can add vNode. Select controls against the workload and threat model; adding a runtime does not itself establish regulatory compliance or a guaranteed GPU performance level.
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.
Treat a tier change as a controlled configuration or migration workflow. Some changes can apply to an existing environment, while others need a new template and replacement cluster. Private Nodes must be selected at cluster creation; an existing node model cannot be switched in place. Test workloads, storage and rollback before moving traffic or changing the customer's capacity commitment.
Dedicated Private Nodes remove cross-tenant workload placement from those workers. Bare metal avoids a hypervisor layer, but this is not a throughput or latency guarantee. GPU drivers, workload configuration, network fabrics and storage can still influence performance. vNode adds runtime hardening using the Linux kernel; benchmark the selected stack against the workload and service levels you intend to offer.
Capacity depends on control-plane sizing, tenant API activity, workload demand and available workers. Lightweight tenant control planes avoid dedicated control-plane servers for each customer, while Private Nodes still need dedicated worker capacity. Lintasarta's 170+ tenant clusters are a named deployment example, not a universal cluster limit. Size and test your fleet against its own availability and performance objectives.
See how GPU clouds sell standard and hardened tenant tiers on the same infrastructure.
