OKAS Migration#

Omniverse Streaming on NVCF is the Reference Architecture for scaled deployment of streaming Omniverse Kit applications, built on NVIDIA Cloud Functions (NVCF). It replaces OKAS 1.0 and is purpose-built to run streaming for enterprise production at global scale. The migration requires a fresh deployment rather than an in-place upgrade of an existing OKAS 1.0 environment. This page maps OKAS 1.0 concepts and integration points to their Omniverse Streaming on NVCF equivalents and outlines the changes your Kit application and web client need for NVCF.

Key Benefits#

Migrating to Omniverse Streaming on NVCF provides significant improvements and new features:

Connect through enterprise firewalls: OKAS 1.0 streamed over UDP only, which blocked clients on networks that do not allow UDP. Omniverse Streaming on NVCF negotiates transport and adds a TURN server that falls back to TCP or TLS when a client network cannot use the direct UDP path.
Scale on demand: A built-in function autoscaler adjusts running instances with demand across clusters, rather than fixed per-session provisioning.
Stable, secure ingress: A single static ingress with standard certificates replaces the per-session dynamic load balancers and wildcard certificates used in OKAS 1.0.
End-to-end observability: Distributed tracing spans service boundaries, logs are correlated by session, and metrics export in OpenTelemetry (OTEL) format to your existing tools.
Caching and performance: A layered cache stack: Container Cache speeds up container image pulls and reduces bandwidth, GXCache caches compiled shaders to cut shader compilation time, and the Derived Data Cache Service (DDCS) and Omniverse Content Cache (OVCC) reduce scene load time and storage egress.
Storage integration: Storage APIs let you connect your own object storage (such as S3 or Azure) as working storage through standard adapters, and subscribe to real-time file-change notifications for live stage updates without a full reload.
Agentic deployment: AI-agent skills automate the full self-hosted deployment: cloud infrastructure, NVCF, caches, storage, and validation. They help stand up a working stack in far less time than a manual, multi-step process.
GPU-accelerated workloads at scale: The NVCF self-hosted stack you deploy for streaming also runs AI inference, simulation, fine-tuning, and other GPU work on the same clusters, reducing the burden of deploying and maintaining separate stacks across your organization.
Open-source NVCF platform: NVCF, the platform layer beneath this Reference Architecture, is open source under Apache 2.0, so you can build it from source, run a self-hosted deployment, customize it, and reuse parts in your own stack. The Reference Architecture is a mix of open and closed source; see the github.com/NVIDIA/nvcf repo for open-source details.

Key Concepts and Changes#

Concept Mappings#

Omniverse Streaming on NVCF introduces new terminology and expanded capabilities compared to OKAS 1.0.

OKAS 1.0	Omniverse Streaming on NVCF	Description
Session	Deployment	A deployment launches a function pod to a cluster with defined resource limits (minimum and maximum instances) and a concurrency number (concurrent invocations per pod).
Application Specification	Function	A function is a core unit, corresponding to the application, version, and profile combination from OKAS 1.0. It defines what is run.
Unique ingress per session	gRPC Proxy	Connect to any deployment behind a single domain name by specifying a header for the target function. Wildcard certificates are no longer required.
Do-it-yourself scaling	Built-in function scaling	Native support for autoscaling deployments based on demand.
Kit streaming functions only	Expanded function support	Support extends beyond Kit streaming functions to AI models and any container that exposes a local HTTP port.

Functions and Deployments#

In OKAS 1.0, a session was the key operational unit. In Omniverse Streaming on NVCF, this splits into two concepts:

Function: the equivalent of an instance specification in OKAS 1.0, identified by application, version, and profile. It defines what runs.
Deployment: a function applied to a cluster. It defines how and where it runs, including the minimum and maximum number of instances and the concurrency number (maximum concurrent invocations per pod). A deployment is similar to an OKAS 1.0 session, but it can have more than one pod behind it.

Expanded Function Support#

Omniverse Streaming on NVCF runs on NVIDIA Cloud Functions (NVCF), a platform for deploying, managing, and running GPU-accelerated workloads at scale. NVCF routes inference, streaming, and other GPU work to worker clusters, so support extends beyond Kit streaming functions to AI models and any container that exposes a local HTTP port, with less infrastructure for you to run yourself.

Networking and Ingress#

Single TCP ingress (gRPC Proxy). Clients connect to any deployment behind a single domain name, and the target function is selected with a request header. This removes the unique ingress and wildcard certificate that OKAS 1.0 required per session.

Single UDP port. Streaming uses a single UDP port, which keeps firewall rules simple to define. The ingress is provisioned up front, so a new connection starts without waiting for a per-session load balancer to spin up. A static ingress IP is available if you need a predictable address.

TURN fallback. When a client network cannot use the direct UDP media path, an optional TURN server provides a TCP or TLS fallback. Supported clients consume the STUN and TURN credentials from signaling automatically, so no separate TURN setup is required in the client.

Resource Management and Autoscaling#

Omniverse Streaming on NVCF includes a built-in function autoscaler that adjusts the number of running instances within the minimum and maximum limits defined in the deployment, based on utilization across clusters. You can manage instances by updating the deployment minimum, relying on the autoscaler, or managing the function and deployment lifecycle externally.

The Intermediary Proxy#

To align with web security best practices, place a lightweight intermediary proxy in the signaling request path. It can be a dedicated websocket HTTPS proxy service or bundled into an existing HTTPS service. The intermediary proxy adds security and session management on top of the NVCF APIs and prevents cross-site scripting (XSS) in the browser. Its responsibilities include:

Access controls.
Authentication token translation.
Session keep-alive management.
Handling CORS and session cookies to prevent XSS.
Other administrative and security functions.

Beyond security, the proxy is a natural extension point: you can layer additional NVCF API calls or application-specific logic behind it.

For NVCF, the Omniverse web streaming tooling can scaffold an NVCF proxy backend that implements this role: it holds the NVCF endpoint, API key, and function ID and exposes a WebSocket signaling endpoint for the web client.

Concurrent Connections and Administration#

Omniverse Streaming on NVCF serves one streaming session at a time per Kit instance. The omni.services.livestream.session extension manages this lifecycle: by default the Kit instance quits when the session ends (quitOnSessionEnded) and the platform provisions a fresh instance for the next session, with a configurable resume window (resumeTimeoutSeconds) for reconnects. The same extension exposes REST endpoints for session lifecycle control and streaming-readiness checks.

API Changes#

OKAS 1.0 managed a session through a small set of streaming endpoints. Omniverse Streaming on NVCF uses the NVCF API, where you register a function, deploy it, and invoke it. All endpoints are versioned under /v2/nvcf and served through your gateway domain. See the NVCF API reference for the full surface.

Action	Omniverse Streaming on NVCF	OKAS 1.0	Notes
Register Application / Function	`POST /v2/nvcf/functions` (add a version with `POST /v2/nvcf/functions/{functionId}/versions`)	No API endpoint (required `kubectl`)	Register via the API, without cluster (`kubectl`) access.
Launch Session / Deploy Function	`POST /v2/nvcf/deployments/functions/{functionId}/versions/{functionVersionId}`	`POST /streaming/stream`	Sets min/max instances; one deployment can serve many users, not one per session.
Connect to Session / Invoke Function	Connect over WebSocket to the intermediary proxy, e.g. `wss://<proxy-domain>/sign_in`	`wss://<session>.<cluster>.<domain>`	Clients connect through the intermediary proxy (it holds the API key and function ID); one static domain, no wildcard certs.
Terminate Session / Undeploy Function	`DELETE /v2/nvcf/deployments/functions/{functionId}/versions/{functionVersionId}`	`DELETE /streaming/stream/{session_id}`	Stops the instances; the registered function and version stay, ready to redeploy.

Kit Application Configuration#

Build your Kit application with the NVCF streaming configuration. The nvcf_stream.kit template (omni.nvcf_streaming_configuration) adds the omni.services.livestream.session extension and the settings required for NVCF streaming. To add this configuration to an existing Kit application, run ./repo.sh template modify (see the Kit App Template tooling guide). See the nvcf_stream.kit template for the configuration itself.

Web Client Changes#

Point your web client at NVCF using the Omniverse Web Streaming Library. Configure AppStreamer for NVCF by setting streamSource to StreamType.NVCF; the generated client supplies the signaling and media server settings for you. Rather than embedding NVCF credentials in the browser, the client connects through an NVCF proxy backend that holds the NVCF endpoint, API key, and function ID and exposes the WebSocket signaling endpoint.

The create-ov-web-rtc-app tool scaffolds both pieces - the client (with streamSource set to NVCF) and the NVCF proxy backend - and each includes a Dockerfile, so you can containerize the client and the proxy for cloud deployment. See the Omniverse Web Sample for the AppStreamer and StreamType references and the sample project.