Rafay vs vCluster: Competitors or a Platform and Its Engine?

Summary

• Rafay and vCluster Platform are direct competitors for AI cloud and GPU cloud providers building managed Kubernetes at scale, but the architectures are fundamentally different.
• Rafay is an all-in-one platform that bundles fleet management, governance, cost optimization, AI tooling, and GitOps into a single opinionated stack. It embeds the open-source vCluster runtime as its tenant isolation mechanism, and is limited to that runtime's shared-nodes model.
• vCluster Platform is a focused tenant orchestration layer (fleet management, self-service portal, Day 2 ops, GPU orchestration) that integrates with the GitOps, FinOps, identity, and observability tools you already run. Critically, its production default is Private Nodes: dedicated, privately joined nodes with their own CNI and storage that Rafay's shared-nodes model cannot deliver.
• Open-source vCluster is the standalone control-plane virtualization primitive, the engine. The production isolation model (Private Nodes), the standalone control-plane path (vCluster Standalone), and the surrounding infrastructure (vNode, vMetal, Auto Nodes) live in vCluster Platform.

‍

What you need to know

Rafay and vCluster Platform compete directly 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 is a focused tenant orchestration layer designed to integrate with the enterprise stack you already run, and it extends the runtime with the production isolation model, standalone control-plane path, and infrastructure automation that the open-source project alone does not provide.

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 CNI and storage instead, which is what makes that model approach the isolation of a dedicated physical cluster.

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. Rafay's OSS-template model is limited to shared nodes: tenants share the underlying nodes, kernel, networking, and storage. Rafay cannot offer Private Nodes at all.

The full spectrum, and when to use each:

• Shared Nodes: each tenant gets control-plane, API, and namespace isolation, but workloads share the same kernel and physical nodes. This is a supported, common model for trusted tenants, and a good fit for development, testing, CI/CD, and internal engineering teams. It is not a security boundary for untrusted tenants with Kubernetes access or the ability to run arbitrary workloads.
• Private Nodes (production default): dedicated, privately joined nodes with per-tenant CNI and storage. The recommended model for all production workloads, and for external, resale, regulated, or otherwise untrusted tenant offerings.
• Dedicated VMs and vNode (private beta): the strongest workload isolation, adding kernel-native runtime separation without a hypervisor for the most sensitive workloads.

Rafay, by contrast, offers only the shared end of this spectrum.

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.

The difference: Rafay delivers these capabilities through a bundled, opinionated platform, so adopting it means replacing or duplicating tooling you may already run, and it can only offer shared-node isolation underneath. vCluster Platform delivers them as a focused tenant orchestration layer that integrates with what's already in place, with the full isolation spectrum available underneath.

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 (private beta) 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 is purpose-built for GPU workloads from the ground up. It is named in the NVIDIA DGX SuperPOD reference architecture. It powers 100K+ GPU nodes in production. Certified Stacks provide pre-validated AI environments (Run:AI, Ray, Jupyter, Slurm) that deploy in minutes. Auto-sleep reclaims idle GPU compute automatically. GPU-level alerting catches issues like thermal throttling and ECC errors at the hardware level. Private Nodes give each production tenant its own dedicated nodes, CNI, and storage. Teams like Boost Run launched a full GPU cloud in under 45 days with zero new platform engineering hires.

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 pay for a focused tenant orchestration layer that integrates with your existing stack and gives you the production isolation model Rafay cannot.

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 building an internal GPU cloud or a commercial GPU-as-a-service platform and need a governed, self-service platform that goes live fast, with Private Nodes for production isolation.
• You already run FinOps, GitOps, identity, and observability tools, and want a platform that integrates with them rather than replacing them.
• You value a single vendor that provides fleet management, GPU orchestration, Day 2 operations, and the full isolation spectrum without bundled tooling that competes with what you already run.

Choose Rafay if:

• You are a small enterprise with no platform engineering staff, and you need a turn-key, single-vendor stack to get started quickly.
• Your organization has already standardized on Rafay's governance workflows across a large fleet, and you understand that scale ceilings (one-VPC-per-tenant, shared-nodes-only isolation, limited bare-metal maturity, services dependency) will need to be addressed as you grow.

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 an all-in-one platform that bundles fleet management, governance, cost optimization, AI tooling, and GitOps into a single opinionated stack, and its tenant isolation is limited to the open-source vCluster shared-nodes model. vCluster Platform is a focused tenant orchestration layer that virtualizes the Kubernetes control plane, integrates with the tools the enterprise already runs, and delivers the full isolation spectrum, including Private Nodes with per-tenant CNI and storage as the production default. Open-source vCluster is the standalone runtime: the shared-nodes virtualization engine, 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 an all-in-one opinionated platform limited to shared-nodes isolation, while vCluster Platform is a focused tenant orchestration layer that integrates with your stack and offers the full isolation spectrum. 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 means tenant clusters share the underlying nodes, kernel, networking, and storage. Each tenant still gets control-plane, API, and namespace isolation, which is efficient and appropriate for dev, test, CI/CD, and internal engineering teams among known, trusted tenants. It is not a security boundary for untrusted tenants that have Kubernetes access or can run arbitrary workloads. Private Nodes joins dedicated worker nodes directly and privately into a specific tenant cluster, with per-tenant CNI and storage and no cross-tenant scheduling, giving hardware-level isolation that approaches a dedicated physical cluster. Private Nodes is the recommended default for production workloads and for external, resale, regulated, or otherwise untrusted tenant offerings. Rafay's OSS-template model offers shared nodes only; Private Nodes requires vCluster Platform.

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 as a focused tenant orchestration layer, 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 is a focused tenant orchestration layer that integrates with your existing stack and delivers the full isolation spectrum, including Private Nodes for production. Before committing to Rafay, evaluate whether vCluster Platform covers your requirements as a focused layer.

‍