On-Premises Deployment Guide#

This guide is for platform engineers who run Omniverse Streaming on NVCF on a Kubernetes cluster they operate themselves: bare-metal servers, virtual machines, or raw cloud instances within a Cloud Service Provider (CSP) account. It covers what to plan for, what you need to provide, what the Agentic AI Skills install and validate, and the order in which the stack comes up. It is planning guidance rather than a step-by-step procedure; the skills carry the procedure.

For managed Kubernetes on AWS or Azure, see Self-Hosted Cluster Deployment and Operations for more information.

Getting Started#

The recommended way to deploy is with the Agentic AI Skills. Point an agent that supports skills at the repository root and ask it to plan a deployment with the target platform generic-kubernetes. Use the existing-cluster profile for a cluster you already run, or generic-bare-metal for nodes that still need Kubernetes. The generic Kubernetes provider skill validates or bootstraps the platform layer and writes a capability report. The orchestration skill then deploys the NVCF Control Plane, the Compute Plane, Low Latency Streaming, the caches, and the Storage APIs on top of it, and stops at the first readiness gate that fails.

The plan lists the phases, the inputs the skills need from you, and the readiness gates before anything changes on the cluster. See Agentic AI Skills for how the skills are organized.

Deployment Scope#

Area	You provide	The skills install or validate
Cluster	Control Plane, CPU platform, and GPU worker nodes, or an existing conformant cluster.	Kubernetes bootstrap or adoption, CNI, GPU Operator, storage provider, load balancer, and the capability report.
Network and DNS	A Gateway API-compliant gateway with a Gateway resource, a `LoadBalancer` implementation, a UDP path for media and a TCP path for the optional TURN fallback, a gateway domain with wildcard DNS, and TLS certificates.	NVCF routes, the streaming proxy, and the optional TURN service.
Registry	Access and credentials for the artifact registries the nodes pull from. Use a private mirror when connectivity or site policy requires it.	Pull validation and, when required, mirroring of the NVCF platform and Omniverse Streaming artifacts.
Storage	An S3-compatible or Azure Blob object store, and a `StorageClass` for persistent volumes.	Storage APIs (Discovery and the storage adapter), OVCC, OVDC, and the NVCF container cache.
NVCF account and tooling	An NGC account and API key for artifact access, and the operator tooling listed under Software Prerequisites.	NVCF prerequisites, the Self-Hosted NVCF stack, and NVCA registration of the GPU cluster.
Validation	Your containerized Kit streaming application.	Readiness gates at every phase, then a streaming function reaching ACTIVE on a GPU worker and, on request, browser playback over UDP and, when TURN is enabled, over TCP TURN.

Reference Topology#

The skills prefer three node roles. Platform services do not need a GPU, so keeping them off the GPU nodes leaves every GPU for streaming workers.

Role	Runs	Guidance
Kubernetes Control Plane	API server, etcd, scheduler	Sized by your Kubernetes distribution; follow its high-availability guidance.
CPU platform nodes	NVCF Control Plane, OVDC, OVCC, Storage APIs, LLS, gateway and load balancing, container cache, observability	Label them with a stable selector such as `nvcf.nvidia.com/platform-worker=true`. OVDC needs one node per replica.
GPU worker nodes	NVCF Compute Plane: streaming function workers	Label them with the GPU facts the GPU Operator discovers and a workload label such as `nvcf.nvidia.com/gpu-worker=true`, and taint them once the platform nodes have enough capacity. A single node that hosts everything is for validation only.

Hardware Guidance#

Planning figures from the component documentation. Confirm them against the linked pages for the versions in the Artifact Manifest and adjust for your scenes and session counts.

GPU Worker Nodes#

GPUs: Kit renders with the Omniverse RTX Renderer, which needs GPUs with RT cores: Turing, Ampere RTX, Ada Lovelace, and Blackwell RTX PRO parts such as the L4, L40S, and RTX PRO 6000. The Omniverse Technical Requirements page lists supported GPUs, validated driver branches, and reference servers. The reference configurations deploy one Kit worker per GPU.
Host CPU and memory: The Technical Requirements server reference pairs eight RTX PRO 6000 GPUs with 64 or more cores and 1 to 2 TB of RAM. That works out to at least 8 cores and 128 to 256 GB per GPU, with RAM depending on the workload. Every GPU node must keep at least 6 CPU cores and 8 GiB free for the infrastructure containers NVCF deploys alongside each function or task, and ideally much more for the Kit workload itself, per GPU Cluster Setup. Before counting on several deployments per node, check the worker pod requests NVCA generates for your instance type against the node’s allocatable resources.
Network: Media leaves the GPU node while scene data, shaders, and images arrive from the caches and the registry. Give GPU nodes at least the network class of the cache nodes.
Disk and driver: NVMe-class local disk for the container runtime, images, logs, and Kit’s working data, with headroom because the NVCF catalog storage request is set from allocatable ephemeral storage. The NVIDIA GPU Operator manages the driver; choose a branch the Technical Requirements page validates for your Kit version.

CPU Platform Nodes#

Component	Guidance	Source
NVCF Control Plane	Minimal high availability: 7 nodes of 8 vCPU and 32 GiB with about 500 GB of block storage. Staging or demo: one node of 16 vCPU and 64 GiB.	NVCF Infrastructure Sizing
Omniverse Derived Cache (OVDC)	One replica per node, scaled linearly with load. Per replica: a NIC of at least 12.5 Gbps, about 8 GB of memory per vCPU, and a volume that sustains 800 MB/s, sized at 2 to 8 times the scene data.	OVDC Configure
Omniverse Content Cache (OVCC)	3 replicas typical; it does not scale dynamically, so size the count up front. 100 to 500 GB per storage backend for medium workloads, using SSD-backed local ephemeral storage or high-IOPS PVCs. Ephemeral cache data is lost on pod recreation. Provide at least 10 Gbps per node, preferably 25 Gbps or more.	OVCC Configure for replicas and storage; the OVCC skill in the streaming-self-hosted repository for additional guidance.
Storage APIs	32 vCPU and 128 GiB, no GPU. About 5 Storage Service replicas per 100 GPUs is a starting point. With a subscriber under `config.storageEvents` and more than one replica, enable the shared Redis or Valkey L2 cache so invalidations reach every replica.	Storage APIs Requirements and Scalability
Low Latency Streaming	5 CPU and 24 GiB per streaming proxy pod; the documented values start with one replica, so plan capacity before adding replicas. TURN is an optional deployment.	LLS Deployment
NVCF container cache	Optional - a StatefulSet on selected nodes plus a DaemonSet that configures the container runtime on every node. Size CPU, memory, and both the container-cache and proxy-cache volumes from the selected chart values.	Container Cache

Software Prerequisites#

Area	Requirement
Kubernetes and tooling	Any conformant distribution (kubeadm, RKE2, k3s, Talos, OpenShift, Rancher, Canonical Kubernetes, MicroK8s, or another). NVCF supports the latest minor release and the two before it; the Storage APIs need 1.31 or later. On the operator workstation: Helm 3.12 or later and below 4, `helmfile` 1.1.x with the `helm-diff` plugin, `kubectl` within one minor version of the cluster, the NVCF CLI, and a mirroring tool such as `skopeo`.
GPU stack	The NVIDIA GPU Operator, which installs the driver, container toolkit, and device plugin. A manually installed driver stack is accepted when the operator does not fit your distribution. The user who registers the GPU cluster needs `cluster-admin`.
Networking and gateway	A CNI (Calico, Cilium, Flannel, or your distribution’s default) and CoreDNS. A Gateway API-compliant gateway controller (Envoy Gateway, Istio, Traefik, or Kong) with a Gateway resource for the NVCF routes. A `LoadBalancer` implementation such as MetalLB or a hardware load balancer.
Ports	Clients reach HTTPS on the NVCF gateway, the UDP media port the streaming proxy advertises (the load balancer listener, or the Service NodePort for direct node access), and the TURN listener on TCP 3478, or 5349 for TLS, when the fallback is enabled. Workers on the GPU nodes need a TCP path to NATS (4222) and to the NVCF HTTP and gRPC endpoints.
Storage and registry	A `StorageClass` that binds, reads, and writes (Longhorn, NFS CSI, Rook/Ceph, or a vendor CSI driver), with the throughput OVDC needs; the SMB CSI driver for NVCA shared worker storage; access and credentials for the selected artifact registries; and object storage credentials delivered as Kubernetes Secrets, through an external secrets operator, or through node or workload identity.

Deployment Order#

The orchestration skill runs these phases in order and stops at the first failed gate.

Platform: Adopt or bootstrap Kubernetes, install the CNI, GPU Operator, storage provider, and load balancer, confirm registry access, and write the capability report.
Artifact access: Validate pulls from NGC or, when required, mirror the NVCF platform images and Omniverse Streaming artifacts into an accessible registry.
NVCF Control Plane: Install the prerequisites, then the Self-Hosted stack with the Low Latency Streaming add-on, the optional TURN setting, and the rate limiter.
Compute Plane: Register the GPU cluster with the NVCF Control Plane and install the NVCA operator.
Auxiliary services: Low Latency Streaming, then the caches you selected.
Storage APIs: Discovery plus the adapter for your object store.
Readiness: No Pending or failing pods, GPUs allocatable, NVCF API healthy, caches and Storage APIs answering.
Streaming validation: A streaming function reaches ACTIVE on a GPU worker. On request, verify WebRTC playback over UDP and, when TURN is enabled, over the configured TURN mode.

References#

NVCF documentation for the platform: