Rafay vs vCluster for AI Cloud Providers: Infrastructure, Isolation, and GPU Operations

Summary

• vCluster Platform is the complete infrastructure stack for AI cloud providers: bare metal provisioning (vMetal), tenant cluster orchestration, workload isolation (vNode), and production AI environments (Certified Stacks). Private Nodes, dedicated worker nodes per tenant with their own CNI and storage, is the production default.
• Rafay is a governance and fleet management platform that embeds open-source vCluster for its tenant-cluster option. That option operates in shared-host-node mode: tenants share the same underlying nodes, kernel, and networking. Private Nodes requires vCluster Platform directly.
• Open-source vCluster is the standalone runtime. Private Nodes, vCluster Standalone, vMetal, vNode, and Auto Nodes are all vCluster Platform capabilities, not part of the open-source runtime.

‍

For AI Cloud Providers, the Stack Question Comes First

If you're building a commercial GPU cloud, the comparison usually starts with two questions: what's the isolation model, and who owns the infrastructure underneath?

Rafay's vCluster-based tenant-cluster option uses the open-source runtime in shared-host-node mode that works for trusted internal teams. For a commercial GPU cloud serving external paying customers, Private Nodes is the recommended isolation model.

vMetal handles the full bare metal lifecycle from rack to production. Rafay has no equivalent provisioning layer. vCluster is named in the NVIDIA DGX reference architecture and powers 100K+ GPUs across AI cloud providers including CoreWeave and Nscale.

For AI cloud providers, vCluster Platform is the stronger default. The architecture goes further and starts earlier in the stack.

What you need to know

Rafay and vCluster Platform compete for the same buyers: AI cloud providers and enterprises building GPU infrastructure at scale. But they take fundamentally different approaches to the same problem.

Rafay is an all-in-one platform: it bundles fleet management, governance, cost optimization, AI tooling, and homegrown GitOps into a single opinionated stack. Its catalog includes a vCluster template as its tenant isolation option, which means Rafay inherits both the strengths and the limits of the open-source runtime, including its shared-nodes-only isolation. vCluster Platform delivers the complete infrastructure stack: bare metal provisioning (vMetal), tenant cluster orchestration, workload isolation (vNode), and production AI environments (Certified Stacks). It extends the open-source runtime with the production isolation model, standalone control-plane path, and infrastructure automation the open-source project alone dos not provide, and it integrates with the enterprise stack you already run rather than replacing it.

This article unpacks the architectural differences, compares the two platforms feature-by-feature, and helps you decide which path fits your team.

What is Rafay? A Kubernetes governance platform built on open-source integrations

Rafay markets itself to enterprises and GPU cloud providers that need to deliver Kubernetes environments (especially GPU-accelerated ones) at scale. Its documentation organizes the platform around three pillars: governance, self-service, and fleet management.

Practically, that means:

• Fleet management: A single pane of glass to manage clusters across on-premises, public clouds, and edge locations.
• Governance and compliance: Policy as code (OPA), RBAC, audit trails, and built-in compliance reporting.
• Self-service developer portals: Teams can provision namespaces or full clusters with guardrails, without filing tickets.
• Cost management: Resources are tracked and optimized across tenants.
• GPU orchestration and AI: Rafay handles GPU inventory, provisioning workflows, lifecycle management, and cost optimization.

Crucially, Rafay does not build its own tenant isolation technology. Its catalog offers a vCluster template: deploy a management cluster, then from the Rafay console spin up tenant clusters using the open-source vCluster runtime. The platform manages the tenant cluster lifecycle (provisioning, upgrading, decommissioning) through the same workflows you use for any other catalog item. This has two consequences. First, Rafay depends on vCluster for tenant isolation but cannot modify the runtime's core behavior; only vCluster Labs, the team that builds and maintains vCluster, can make those changes. Second, Rafay is limited to what the open-source runtime offers, which is the shared-nodes model. It does not have Private Nodes, per-tenant CNI and storage, dedicated-node tiers, or vNode. For production AI workloads and for AI cloud providers offering managed Kubernetes to untrusted end customers, that shared-nodes ceiling is a real constraint.

Rafay also requires a full Kubernetes management cluster to be stood up before any tenant clusters can be created, and for stronger separation its only real lever is provisioning additional full clusters. There is no equivalent to running the control plane directly on Linux without a base distribution.

One further architectural limitation worth noting: Rafay uses a one-VPC-per-tenant model, so in our analysis every tenant tends to get the same security and cost profile. It cannot easily serve one business unit with shared compute pools for dev/test and another with dedicated nodes for production training from the same control plane. For enterprises building internal AI factories that must serve multiple BUs with different requirements, this ceiling arrives quickly.

What is vCluster? The engine and the platform

At its core, vCluster virtualizes the Kubernetes control plane. When you create a tenant cluster, you get a fully independent Kubernetes API server, scheduler, and control-loop components, all running as pods on a control plane cluster. What happens below the control plane depends on the node model:

• With shared nodes, tenant workloads run on the control plane cluster's shared physical nodes. Efficient, and appropriate for trusted tenants.
• With private nodes, each tenant cluster gets its own dedicated worker nodes, joined directly to it over an encrypted VPN tunnel, with a separate CNI and separate storage. Those nodes are not visible from the control plane cluster, and no other tenant can schedule onto them.

In both models, each tenant cluster gets its own isolated control plane and API surface. This sidesteps two common extremes:

• Namespace-level isolation (weak, with a shared blast radius for CRDs, RBAC).
• Full physical clusters per tenant (expensive, slow to provision, low utilization).

vCluster gives you hard control-plane isolation while consolidating tenant control planes as pods, rather than standing up a full cluster per tenant, delivering the same self-service, hyperscaler-like Kubernetes experience your customers expect from AWS and GCP. GPU-enabled tenant clusters can spin up in seconds in typical deployments, a process that otherwise takes the better part of an hour with bare-metal provisioning.

There are two ways to get this technology.

Open-source vCluster is the standalone runtime: the control-plane virtualization primitive, the engine. It gives you the same control-plane isolation, and you build everything else yourself: fleet management, self-service portal, SSO, observability, GPU orchestration. It runs the shared-nodes model. It does not include Private Nodes, vNode, or the infrastructure automation that production GPU isolation depends on.

vCluster Platform is the complete enterprise product from vCluster Labs. It is the platform in the comparison table above: fleet management, self-service portal, Day 2 operations, GPU orchestration, and the full isolation spectrum. Because vCluster Labs builds and maintains the runtime, the Platform adds the capabilities the open-source project does not have, including Private Nodes and proprietary enterprise features (advanced scheduling, VPN, snapshots), and the vCluster Standalone path described below.

vCluster Standalone: no base cluster required

vCluster Standalone runs the control plane as a binary directly on Linux, with no k3s, kubeadm, or other base distribution underneath. The practical consequence is that you do not need a pre-existing, full Kubernetes cluster to serve as your control plane cluster before you can start creating tenant clusters. The path is bare metal to Linux to control plane cluster to tenant clusters, with one less layer to provision, patch, and pay for.

This is a capability Rafay does not have. Rafay requires a full Kubernetes cluster to exist first, and its shared-node tenant clusters run on top of that management cluster. For stronger isolation, its only option is to stand up additional full clusters. Standalone removes that requirement entirely.

Because vCluster virtualizes the Kubernetes API itself, both the open-source runtime and the Platform work with any CNCF-certified distribution, such as EKS, AKS, GKE, RKE2, or your own bare-metal Kubernetes. Shared-node tenant clusters use the control plane cluster's CNI and storage. With Private Nodes, each tenant cluster runs its own.

Private Nodes: the production default

Private Nodes is the model to lead with for any production deployment. Dedicated worker nodes are joined directly and privately into a specific tenant cluster over an encrypted VPN tunnel, and each tenant cluster runs its own CNI and storage. There is no cross-tenant scheduling, and the nodes are not visible from the control plane cluster: they exist only within that tenant cluster. Network and storage isolation are per-tenant rather than shared, so a Private Nodes tenant cluster delivers hardware-level isolation that comes as close to a separate physical cluster as you can get, while still keeping the efficiency and speed of the consolidated control-plane model. Private Nodes requires vCluster Platform, which is available in a free mode, so no paid license is needed to start.

This is the sharpest architectural line between the two products. vCluster Platform gives each production tenant dedicated worker nodes with their own CNI and storage, hardware-level isolation approaching a dedicated physical cluster, without the provisioning cost of running separate clusters.

The isolation tiers, in the order production deployments actually need them:

• Private Nodes (production default): dedicated, privately joined nodes with per-tenant CNI and storage. No shared kernel, no shared network path, no cross-tenant scheduling. The required model for any deployment serving external or untrusted tenants, including all commercial AI cloud and GPU cloud workloads.
• vNode: kernel-native workload isolation via seccomp, cgroups, and Linux namespaces. No hypervisor, no VM overhead, bare metal GPU performance preserved. Available for environments requiring workload-level isolation in addition to control-plane and node-level isolation.
• Shared Nodes: control-plane, API, and namespace isolation with workloads running on shared physical nodes. A supported model for dev, test, CI/CD, and trusted internal teams. Not a security boundary for untrusted tenants. Not the recommended tenancy boundary for commercial GPU clouds serving external paying customers.

Rafay's vCluster-based tenant-cluster SKU operates at the shared-nodes tier. vCluster Platform gives you all three.

The real comparison: all-in-one platform vs. focused tenant orchestration

This is the decision that matters. Rafay and vCluster Platform compete for the same buyers, but the philosophical difference runs deep: one vendor's opinion of every layer (compute, networking, storage, GitOps, observability, identity) or a focused layer that does tenant orchestration really well and integrates with the tools your team already runs.

Rafay bundles cost management, AI tooling, and GitOps directly into the platform. For enterprises that already run FinOps tooling, GitOps pipelines, identity providers, and observability, adopting Rafay means either replacing what's already in place (rip-and-replace) or duplicating it (more cost, more tools to manage, conflicting data).

vCluster Platform is the tenant orchestration layer in a composed AI factory stack. It integrates cleanly with what the enterprise already runs: GitOps (Argo CD, Flux), storage (Weka, DDN, Vast, NetApp), networking (Netris, Aviz), identity (Keycloak, Okta). It emits per-tenant usage events so your existing FinOps tooling can pick them up.

The two products also differ on what they can do with the isolation layer itself, not just how they package it. Rafay applies the open-source shared-nodes model consistently across whatever infrastructure it manages. vCluster Platform can offer Private Nodes, dedicated tiers, and vNode from the same control plane, because vCluster Labs owns the runtime and can extend it.

Governance and fleet management

If the only thing you need is strong control-plane tenant isolation for trusted internal teams, the open-source runtime does that. But the moment you need to enforce organization-wide policies, give developers a self-service portal, track costs per team, offer Private Nodes for production, or show compliance auditors what's happening across dozens of tenant clusters, you need a platform layer.

Both Rafay and vCluster Platform deliver these capabilities:

• Policy enforcement: OPA gatekeeper integration (Rafay) or centralized SSO/RBAC with project quotas (vCluster Platform). Both provide audit logging and role-based access across the entire fleet.
• Fleet-wide inventory and visibility: A unified control plane that sees every cluster (physical or virtual) across datacenters, cloud regions, and edge sites.
• Self-service workflows: Developer teams can request a GPU-enabled environment through a portal, get it provisioned in minutes, and never worry about the underlying isolation mechanism.
• Cost allocation and optimization: Track consumption and attribute it to tenants, moving from dedicated per-team clusters to denser, governed tenant infrastructure.

Rafay delivers these capabilities through a bundled, opinionated platform, so adopting it means replacing or duplicating tooling you may already run, and its vCluster-based tenant-cluster option is limited to shared-node isolation. vCluster Platform integrates with what's already in place and delivers the full isolation spectrum, including Private Nodes as the production default.

Tenant isolation and architecture

Both platforms deliver control-plane virtualization through vCluster. But the isolation you can actually achieve, and how you consume it, differs sharply.

vCluster's model is control-plane-level isolation, delivering the self-service, hyperscaler-like Kubernetes experience customers expect from AWS and GCP. Each tenant cluster gets:

• Its own API server and etcd (embedded or external).
• Its own set of RBAC rules, admission controllers, and namespace-scoped CRDs.
• The ability to install any Kubernetes resource (Deployments, Services, CRDs) inside the tenant cluster, without fear of collision with other tenants.
• Optional syncing of select control-plane-cluster CRDs through sync patches, so operators like cert-manager or external-dns can be leveraged without giving tenants direct access to control plane cluster APIs.

This is stronger than simple namespace isolation because a rogue tenant cannot modify cluster-scoped resources (like ClusterRoleBindings) and cannot starve the control plane cluster's API server with poorly-configured CRD controllers. With Private Nodes, isolation extends below the control plane to dedicated nodes with their own CNI and storage.

Rafay's approach wraps this shared-nodes vCluster isolation in a governance chassis. You can enforce policies at the organization level that cascade to every tenant cluster, and self-service portals restrict what templates a team can launch, for how long, and with what quotas. But the isolation underneath is fixed at the shared-nodes level, because that is what the open-source template provides.

vCluster Platform's approach delivers the governance natively (fleet-wide policy enforcement, SSO/RBAC, project quotas, audit logging) and, more importantly, is not fixed at the shared-nodes level. Because vCluster Labs builds and maintains the runtime, the Platform supports the full isolation spectrum: Shared Nodes for trusted dev/test, Private Nodes with per-tenant CNI and storage as the production default, Dedicated VMs, and vNode for kernel-native workload isolation without a hypervisor.

That is the real isolation difference. It is not only a governance-model difference. Rafay and vCluster Platform apply governance to the same runtime, but only vCluster Platform can take that runtime past shared nodes to the production isolation model these buyers actually need.

GPU and AI infrastructure

Both Rafay and vCluster Platform deliver GPU orchestration, self-service provisioning, and AI infrastructure tooling. Two things separate them: provenance, and the isolation model underneath.

Rafay's GPU story is a turn-key PaaS with pre-built workflows for GPU inventory management, driver provisioning, and cost optimization. A data scientist requests "4×A100, 80 GB, for 8 hours," and Rafay assembles the environment. But in our analysis, Rafay's bare-metal story is less mature than its cloud-managed deployments, its one-VPC-per-tenant model means tenants tend to share the same security and cost profile, and its shared-nodes-only isolation is not the model you want under untrusted production GPU workloads.

vCluster Platform's GPU story starts at the rack. vMetal handles the full bare metal lifecycle: PXE boot, OS install, machine registration, network automation. GPU servers go from rack to production without manual intervention. This is a capability Rafay does not have. vCluster isn't managing clusters that someone else provisioned. It provisions the infrastructure itself.

From bare metal, vCluster Standalone runs a CNCF-certified Kubernetes control plane as a binary on Linux, no k3s or kubeadm needed. Above that, vCluster Platform orchestrates tenant clusters with Private Nodes as the production default, Certified Stacks for pre-validated AI environments (Run:AI, Ray, Jupyter, Slurm), Auto Nodes for dynamic GPU provisioning, and GPU-level alerting for hardware-level issues. The platform is named in the NVIDIA DGX SuperPOD reference architecture and powers 100K+ GPUs in production. Boost Run launched a full GPU cloud in under 45 days with zero new platform engineering hires.

This is infrastructure orchestration from raw GPU servers to isolated tenant clusters, not a management layer sitting on top of infrastructure someone else built.

Pricing and licensing

Rafay is a commercial platform. Its pricing follows an enterprise pattern: a platform fee plus a per-GPU, per-CPU, or per-node unit fee, with multiple tiers tailored to AI clouds, enterprises, and GPU cloud providers. Exact numbers require a conversation with Rafay's sales team. The company does not publish self-service pricing on its website.

vCluster Platform is commercially licensed. You are paying for the complete platform (fleet management, self-service portal, Day 2 operations, GPU orchestration, and the full isolation spectrum including Private Nodes) directly from vCluster Labs.

Because Rafay bundles vCluster inside its platform, you cannot separate its vCluster cost from the platform. When you pay Rafay, you pay for the full opinionated platform, all bundled. When you pay vCluster Labs directly for vCluster Platform, you get the complete infrastructure stack, Private Nodes, vMetal, vNode, fleet management, Day 2 operations, integrated with your existing tooling and without paying for bundled governance layers you may not need.

Operational complexity: the real cost of each path

The question is not just "what features does each have?" but "what do I, the platform team, have to build and maintain?"

vCluster Platform path:

• Self-hosted Helm deployment: you deploy it, you manage it, it runs in your infrastructure. No SaaS dependency.
• Fleet management, self-service portal, SSO/RBAC, GPU orchestration, and Day 2 operations are integrated.
• Centralized upgrades, observability, and backup/restore across all tenant clusters. GitOps-native: manage everything as CRDs via Argo CD or Terraform.
• GPU infrastructure: Private Nodes, Auto Nodes (Karpenter), VPN, and Certified Stacks (Run:AI, Ray, Jupyter, Slurm) are part of the platform. Teams like Boost Run launched in under 45 days with zero new platform engineering hires.
• vCluster Standalone means you can run the control plane cluster directly on Linux, with no base distribution to maintain.

Rafay path:

• Rafay provisions the management cluster and the vCluster template is a button-click in the catalog. Provisioning, upgrading, and decommissioning are lifecycle-managed.
• Governance, self-service portals, cost management, GPU inventory, and compliance reports are all surfaced in the Rafay console.
• The platform enforces consistency: every tenant cluster gets the same baseline policies, admission controls, and quotas.
• Trade-offs: you depend on Rafay's platform for the full stack, the isolation is fixed at shared nodes, a full management cluster is always required, and field feedback suggests the product often requires significant professional services engagement to reach production. When you need to modify how tenant isolation works at the core level, only the runtime's creator (vCluster Labs) can make those changes.

Full Platform vs. standalone runtime: who should pick which?

Choose vCluster Platform if:

• You are an AI cloud provider or neocloud building commercial GPU infrastructure. Private Nodes is the required isolation model for untrusted production workloads. vMetal handles your bare metal lifecycle. The NVIDIA DGX reference architecture validates the stack. This is what the leading AI cloud providers are running.
• You already run FinOps, GitOps, identity, and observability tools, and want a platform that integrates with what's already in place rather than replacing each layer with its own opinion.
• You want fleet management, GPU orchestration, Day 2 operations, and the full isolation spectrum from one vendor, without bundled tooling that competes with what you already run.

Choose Rafay if:

• You are an enterprise with limited platform engineering staff who needs a turn-key governance stack across existing managed cloud Kubernetes, and dedicated tenant isolation at the node level is not a current requirement.
• Your organization has already standardized on Rafay's governance workflows and is primarily managing existing cloud-managed clusters rather than building a GPU cloud from bare metal up.

For AI cloud providers or neoclouds building commercial GPU infrastructure with bare metal provisioning and dedicated per-tenant isolation, vCluster Platform is purpose-built for that use case.

Before committing to an all-in-one opinionated platform, ask whether that trade-off is right: vCluster Platform delivers the same fleet management, GPU orchestration, and self-service capabilities as a focused layer that integrates with your existing stack, and it gives you a production isolation model Rafay does not have.

The open-source runtime is the engine, not a platform, and not a production alternative to either product. It provides shared-nodes control-plane isolation for teams that want to build their own tooling around it and do not need Private Nodes, vNode, or integrated GPU infrastructure. It is a fit for internal, trusted, non-production isolation, not for serving production or untrusted tenants.

For most teams evaluating Rafay, vCluster Platform is the more direct path: the same tenant isolation runtime, a focused platform, integration with your stack, and the production isolation model Rafay cannot offer. Request a demo to compare what you are getting versus what you are paying for.

Frequently Asked Questions

What is the main difference between Rafay and vCluster?

Rafay is a governance and fleet management platform that bundles fleet management, policy enforcement, cost optimization, and GitOps into a single opinionated stack. Its vCluster-based tenant-cluster SKU uses the open-source runtime in shared-host-node mode.

vCluster Platform delivers the full infrastructure stack, bare metal provisioning (vMetal), tenant cluster orchestration, workload isolation (vNode), with Private Nodes as the production default: dedicated worker nodes per tenant with their own CNI and storage. For AI cloud providers serving external customers, that's the isolation tier that matters. Open-source vCluster is the standalone runtime with no platform layer and no Private Nodes.

Are Rafay and vCluster competitors?

Yes, Rafay and vCluster Platform are direct competitors for the same buyers: AI cloud providers and enterprises building GPU infrastructure. Rafay is a governance and fleet management platform whose vCluster-based tenant-cluster option uses shared-host-node mode. vCluster Platform delivers the full infrastructure stack with Private Nodes as the production default. Open-source vCluster is also available standalone from vCluster Labs as the underlying runtime.

How does Rafay use vCluster internally?

Rafay deploys vCluster through its system template catalog as its tenant isolation component. The platform manages the entire tenant cluster lifecycle (provisioning, upgrading, decommissioning) through its console and APIs. Because it consumes the open-source runtime, Rafay is limited to that runtime's shared-nodes model and cannot offer Private Nodes or modify core runtime behavior.

What is the difference between shared nodes and Private Nodes?

Shared nodes give each tenant a dedicated control plane but share the same underlying physical nodes, kernel, and networking. Good for dev, test, CI/CD, and trusted internal teams, not a security boundary for untrusted tenants. Private Nodes gives each tenant dedicated physical worker nodes with their own CNI and storage. No cross-tenant scheduling, no shared kernel. Hardware-level isolation approaching a dedicated physical cluster. Private Nodes is the recommended model for production workloads and external customers. It requires vCluster Platform; Rafay's vCluster-based tenant-cluster option does not include it.

Why use vCluster instead of just Kubernetes namespaces for tenant isolation?

vCluster provides significantly stronger isolation than namespaces, delivering the self-service, hyperscaler-like Kubernetes experience your customers expect from AWS and GCP. Namespaces share the control plane cluster's API server and etcd, so a misconfiguration or vulnerability in one tenant can impact all others. vCluster gives each tenant its own virtual control plane, creating a hard boundary that prevents cross-tenant interference, and with Private Nodes that boundary extends to dedicated nodes.

How do vCluster tenant clusters provide isolation?

vCluster virtualizes the Kubernetes control plane for each tenant. Each tenant cluster runs its own API server, scheduler, and controllers as pods on a control plane cluster, giving each tenant a dedicated, sandboxed Kubernetes environment while preventing access to or interference with other tenants and the underlying control plane cluster. With Private Nodes, isolation extends to dedicated worker nodes with per-tenant CNI and storage that are not visible from the control plane cluster.

What is the performance overhead of using vCluster?

The primary overhead is the CPU and memory consumption of running a separate control plane for each tenant cluster. While this overhead is generally minimal for most workloads, control plane clusters supporting many tenant clusters or high-API-traffic tenants must be sized with enough resources to accommodate the additional control plane load.

Can I use control plane cluster operators and CRDs inside a tenant cluster?

Yes. Using vCluster's resource syncing and sync patch features, you can expose control-plane-level operators and CRDs (like cert-manager or an ingress controller) to tenants without giving them direct access to the control plane cluster's API server. Configuration is required on a per-resource basis.

Can I migrate from a standalone vCluster setup to Rafay?

Yes, and so is migrating to vCluster Platform. Because both platforms are built on the same open-source vCluster core, migration involves shifting lifecycle management from your custom toolchain to a managed platform. Before migrating to Rafay, consider whether vCluster Platform meets your requirements directly, and note that only vCluster Platform gives you Private Nodes and the rest of the production isolation spectrum.

So, is standalone vCluster a full alternative to a platform like Rafay?

No, and that is the wrong comparison. Open-source vCluster is the standalone runtime, the shared-nodes virtualization primitive. The right comparison is Rafay vs. vCluster Platform: two platforms, two philosophies. Rafay is an all-in-one platform limited to shared-nodes isolation; vCluster Platform delivers the full infrastructure stack with Private Nodes for production and integrates with your existing tooling. Before committing to Rafay, evaluate whether vCluster Platform fits your requirements.

‍