Run:AI as a Service: How GPU Clouds Launch Self-Service AI Platforms with Private Nodes

Summary

• Selling raw GPU capacity is a race to the bottom; packaging Run:AI as a self-service GPU environment creates service margins on the same hardware.
• Run:ai's native isolation is control-plane only — infrastructure-level network, compute, and storage isolation is the AI cloud operator's responsibility.
• Production-grade tenant isolation requires dedicated worker nodes, per-tenant CNI and storage, and an isolated control plane per tenant — not namespace isolation or one physical cluster per customer.
• The working production model is pre-validated environment templates with hardware-level isolation as the default, automated behind a self-service portal.
• Action: define service tiers, codify environment templates, enforce dedicated worker nodes and per-tenant boundaries, and expose one-click provisioning. vCluster Platform supplies this tenant isolation layer, with production deployments in 45-90 days, 100,000+ GPUs under management, and 40M+ tenant clusters created.

Selling raw GPU capacity is a race to the bottom. Pricing pressure is relentless, and the only durable escape is moving up the value stack, from servers to services.

NVIDIA Run:ai is the GPU orchestration platform enterprises want. It delivers GPU gang-scheduling, fractional GPU sharing, and workload-aware scheduling that help AI clouds squeeze more work out of the GPUs they already own. Those capabilities make Run:ai a compelling product to sell. The problem is that packaging it as a repeatable, self-service offering for external customers requires more than a Run:ai installation. It requires production-grade tenant isolation, and that layer is not included.

This article is for the AI cloud CTO or Head of Infrastructure who already knows they want to offer Run:AI as a Service and is evaluating how to build it without assembling a platform team from scratch.

What "Run:AI as a Service" actually means for a GPU cloud

"Run:AI as a Service" is a self-service product for external customers rather than a managed Run:ai installation for a single internal team. Customers select a tier, provision their own isolated Run:ai environment, and operate it independently within your infrastructure.

A practical service catalog looks like this:

Each tier is a managed product you ship. Customers interact with your branded portal, not your infrastructure team. Provisioning is automated. Run:ai handles GPU scheduling inside the environment; your platform handles everything underneath.

The margin argument is straightforward. Every step up the stack, from bare metal to tenant cluster orchestration to managed GPU environments, adds margin on the same hardware. Customers are willing to pay a premium for the cloud experience: self-service access, isolation guarantees, and managed tooling. Selling GPUs without that experience competes only on price.

The hard problem nobody talks about: tenant isolation

Run:ai handles GPU scheduling exceptionally well. The obstacle to selling it to external customers is tenant isolation.

NVIDIA's own Run:ai documentation states this directly: Run:ai's tenant isolation is implemented only at the control-plane level, providing logical and access isolation. Network, compute, and storage isolation must be implemented by the host organization at the infrastructure level. For untrusted external organizations, NVIDIA's guidance is to provision dedicated Kubernetes clusters per tenant.

That guidance is correct, but it leaves automation unsolved. Run:ai defines the target architecture; provisioning remains the operator's job.

Two approaches teams reach for first both fail at scale:

Namespace-level isolation is the most common starting point and an insufficient boundary for external customers. Namespaces provide no protection against container breakouts, no per-tenant CNI or storage boundaries, and no ability for tenants to manage their own Run:ai projects or install CRDs. Enterprise customer contracts typically require isolation at the hardware level.

One physical cluster per tenant satisfies the isolation requirement but breaks the business model. Dedicated physical clusters fragment node pools, eliminate the GPU utilization gains Run:ai is designed to provide, and require manual provisioning that destroys the self-service experience. The operational overhead scales linearly with customer count.

The gap between what Run:ai's isolation provides and what external customers require is exactly where most AI clouds stall.

How vCluster packages Run:AI as a service: the working recipe

vCluster closes that gap through two complementary components: Certified Stacks and Private Nodes. Run:ai handles GPU scheduling and workload orchestration. vCluster provides the production-grade isolation envelope underneath.

Certified Stacks: from bare cluster to live Run:ai in minutes

A Certified Stack is a pre-validated, version-locked deployment that packages everything required to run a specific workload type. The Run:ai Certified Stack ships vCluster + NVIDIA GPU Operator + NVIDIA Run:ai in a single tested deployment, verified against specific versions (Kubernetes v1.34 / vCluster v0.31 / Run:ai v2.25).

The result is a repeatable unit of infrastructure. Every customer provisioned from the same Certified Stack receives an identical environment: the same versions, the same policies, the same configuration. There is no manual setup, no configuration drift, and no per-customer troubleshooting of environment inconsistencies.

Run:ai is listed first among vCluster's Certified Stack integrations. Other available stacks include Ray, Jupyter, and Slurm via Slinky. The same platform that ships your Run:ai service can also ship additional cluster types as your product catalog grows.

Private Nodes: hardware-level isolation as the production default

Private Nodes is vCluster's production default and the starting point for any external customer deployment.

Under this model, each tenant cluster receives dedicated worker nodes, a per-tenant CNI, and per-tenant storage. At the control-plane level, each tenant gets their own Kubernetes API server, etcd instance, and RBAC configuration. No tenant shares nodes, networking fabric, or storage boundaries with another.

This architecture delivers the isolation guarantees of separate physical clusters without the fragmentation and operational cost. GPU pools remain consolidated; Run:ai's scheduling operates across the node pool; vCluster's isolation layer is designed so each tenant's workloads, data, and credentials run on dedicated nodes, networking, and storage.

For workloads that require an additional hardening layer, vNode provides kernel-native workload isolation via seccomp, cgroups, and namespaces, with direct GPU access and near-zero overhead, and no hypervisor tax.

The provisioning flow

The customer experience a well-built Run:AI as a Service product delivers:

1. Customer selects "Run:AI — Enterprise 8×H100" in your self-service portal.
2. vCluster Platform receives the API call and provisions a new tenant cluster with dedicated Private Nodes in seconds.
3. The Run:ai Certified Stack deploys automatically into that tenant cluster.
4. The customer receives credentials for their private Run:ai control plane.
5. They configure projects, set GPU quotas, and submit workloads — entirely within their isolated environment.

Your infrastructure team does not touch a ticket. The provisioning is fully automated end-to-end, and the customer's environment is indistinguishable from a dedicated cluster.

vCluster offers two integration models: a turnkey self-service portal out of the box, or an API-first building-blocks model where you place your own branded frontend over the vCluster API. Switching between the two requires no re-platforming.

Why build it with vCluster instead of DIY

The decision is how much of the platform to build yourself, and what that delay costs. A dedicated isolation layer is a multi-quarter build with ongoing maintenance, incident response, and iteration that competes with the customer-facing work that actually grows the business.

Boost Run demonstrates what a faster path looks like. The AI cloud launched a production-grade managed Kubernetes service in under 45 days.

Lintasarta launched Indonesia's leading GPU cloud in 90 days — a case study vCluster documents in detail.

vCluster Platform is now production-proven at 100,000+ GPUs across 50+ AI Clouds & Fortune 500s, with 40 million+ tenant clusters created. vCluster Platform is also validated in NVIDIA's DGX reference architecture.

The point that lands in these conversations is simple: major cloud providers spent years building their Kubernetes platforms in-house. That timeline is not available to an AI cloud competing today. vCluster delivers an equivalent platform foundation in days.

Buying vs. building the isolation layer

The architectural question is whether to build the isolation layer as a custom system or adopt a platform purpose-built for this problem.

Generic management platforms can provision Kubernetes clusters, but production-grade tenant isolation for untrusted external customers requires more than cluster provisioning. The missing pieces are dedicated worker nodes as a default, per-tenant networking and storage boundaries, control-plane isolation per tenant, and a workload hardening layer for sensitive environments. Platforms that reach these requirements through configuration wrappers built over a generic foundation are solving a different problem than platforms designed around isolation from the ground up.

vCluster's architecture addresses this as a complete, integrated stack:

• vMetal supplies a single EC2-like API for the machine layer. It handles zero-touch bare metal provisioning (PXE boot, OS installation), machine registration, and hard network isolation via programmatic VLANs, VRFs, ACLs, and DPU policies (networking powered by Netris). The output is bare metal machines and VMs as sellable products.
• vCluster Platform handles tenant cluster orchestration. Each tenant cluster has dedicated Private Nodes, isolated control plane, per-tenant CNI, and per-tenant storage. Certified Stacks, including Run:ai, deploy into these tenant clusters automatically.
• vNode adds workload isolation via seccomp, cgroups, and namespaces. Purpose-built for AI workloads: direct GPU access, near-native network performance, no hypervisor tax.

These three layers are complementary and coherent. vMetal handles the machine layer. vCluster Platform handles tenant cluster orchestration and isolation. vNode handles workload hardening within the tenant cluster. Run:ai operates inside that envelope, handling GPU scheduling, fractional GPU sharing, and workload-aware queue management.

The distinction between production-grade hardware-level isolation and isolation bolted on to a generic management platform is architectural. It determines what customer contracts you can sign, what compliance claims you can make, and how your platform behaves under adversarial conditions.

vCluster's isolation layer earns the "hard" label because each tenant's workloads run on dedicated nodes, with dedicated networking and storage, behind an isolated control plane. That is Private Nodes by default.

Launch checklist for Run:AI as a Service

For AI cloud teams ready to move from intent to production, the sequence is straightforward:

1. Define your service tiersSpecify the GPU configurations you will sell: GPU type, node count, and memory allocation per tier. Align these to workload types: experimentation, production training, and multi-node distributed jobs.

2. Certify the Run:ai configurationUse vCluster's Run:ai Certified Stack to create a standardized, version-locked deployment template. Every customer provisioned from that template receives an identical, tested environment. Configuration drift becomes a non-issue.

3. Default to Private NodesEvery external customer tier runs on Private Nodes. Dedicated worker nodes, dedicated CNI, dedicated storage: no tenant shares infrastructure with another. This is the baseline for any enterprise or compliance-sensitive customer contract.

4. Codify tiers as templatesTurn each service tier into a provisionable template within vCluster Platform. Templates encode the GPU allocation, Run:ai configuration, isolation policy, and any additional constraints. Provisioning a new tenant cluster executes the template, not a manual runbook.

5. Expose via a self-service portalConnect your templates to a customer-facing interface. Use vCluster's turnkey portal for immediate availability, or call the vCluster API from your own branded frontend. Either path gives customers one-click provisioning without touching your operations team.

6. Plan for Day 2 operationsvCluster Platform includes fleet management, GitOps and Terraform-native configuration, Auto Nodes for dynamic GPU provisioning, and 24/7 engineering support. Day 2 operations are part of the platform, not a separate build project.

Ready to launch your Run:AI service in 45 days?

Stop building undifferentiated platform plumbing. The isolation layer, the Certified Stack, the self-service portal, and the fleet management tooling are available today. They are production-proven across 100,000+ GPUs and 50+ AI Clouds & Fortune 500s.

Request a demo to see how vCluster gets your Run:AI as a Service offering into production in under 45 days.

Frequently Asked Questions

What is Run:AI as a Service?

Run:AI as a Service is a self-service product that lets external customers provision their own isolated Run:ai environment, select a GPU tier, and operate it independently within your AI cloud. Instead of selling raw GPU capacity or managing one shared Run:ai installation, you package Run:ai environments as repeatable tiers, such as 4×, 8×, or 32× GPU allocations, and automate provisioning behind a branded portal.

What tenant isolation does Run:ai provide by itself?

Run:ai provides control-plane-level logical and access isolation, not infrastructure-level network, compute, or storage isolation. NVIDIA's Run:ai documentation states that network, compute, and storage isolation must be implemented by the AI cloud operator, and for untrusted external organizations NVIDIA recommends dedicated Kubernetes clusters per tenant.

Why can't namespace-level isolation support external Run:ai customers?

Namespace-level isolation does not provide per-tenant CNI, storage boundaries, or protection against container breakouts, and it prevents tenants from managing their own Run:ai projects or installing CRDs. Enterprise customer contracts typically require hardware-level tenant isolation, so namespace-based approaches fail at the isolation layer before they can scale commercially.

How does vCluster package Run:AI as a Service for AI clouds?

vCluster packages Run:ai through Certified Stacks and Private Nodes. Certified Stacks deliver a pre-validated, version-locked Run:ai deployment, while Private Nodes provide dedicated worker nodes, per-tenant CNI, per-tenant storage, and an isolated control plane cluster for each tenant cluster.

What are vCluster Certified Stacks?

Certified Stacks are pre-validated, version-locked deployments that package vCluster with NVIDIA GPU Operator and Run:ai in a single tested environment. The Run:ai Certified Stack ships a repeatable unit of infrastructure, so every customer provisioned from that stack receives identical versions, policies, and configuration without manual setup or configuration drift.

What is the production default isolation model for external Run:ai customers?

Private Nodes is the production default for external customer deployments. Under this model, each tenant cluster receives dedicated worker nodes, a per-tenant CNI, per-tenant storage, and its own control plane cluster, so no tenant shares nodes, networking fabric, or storage boundaries with another.

How long does it take to launch Run:AI as a Service with vCluster?

A production-grade managed Kubernetes service can go live in as little as 45 days with vCluster. Boost Run launched a production-grade managed Kubernetes service in under 45 days, and Lintasarta launched Indonesia's leading GPU cloud in 90 days. Both are substantially faster than a multi-quarter DIY isolation layer build.

Can I keep my own branded portal when offering Run:AI as a Service?

Yes, vCluster supports both a turnkey self-service portal and an API-first building-blocks model. You can place your own branded frontend over the vCluster API and switch between the two integration models without re-platforming.

How is vCluster different from a generic Kubernetes management platform?

Generic management platforms can provision Kubernetes clusters, but vCluster is purpose-built around tenant isolation from the ground up. vCluster combines vMetal for machine-layer networking and bare metal provisioning, vCluster Platform for tenant cluster orchestration with Private Nodes, and vNode for workload hardening, all designed to support untrusted external customers by default.

‍