NVIDIA OSMO is an open-source workflow orchestration platform developed by Nvidia for physical AI and robotics development. It defines multi-stage jobs in YAML, schedules their containerized tasks across heterogeneous compute, and manages dependencies, data movement, and workflow state. Its intended workloads include synthetic data generation, model training, reinforcement learning, simulation, evaluation, and software-in-the-loop (SIL) or hardware-in-the-loop (HIL) testing.[1][2][3]

OSMO is infrastructure software, not a robot model, simulator, training framework, or deployment runtime. It can run those tools as workflow tasks, but it does not replace them or install a trained policy on a production robot. NVIDIA also distinguishes it from a general MLOps platform: OSMO focuses on execution, scheduling, dataset versioning, and lineage rather than experiment dashboards or a built-in artifact registry.[3]

History and availability

NVIDIA announced OSMO at GTC on March 18, 2024 as a cloud-native orchestration service in early access. The initial description emphasized coordinating synthetic data generation, deep neural network training and validation, robot simulation, and perception evaluation across x86-64 and Arm systems on premises and in the cloud.[1]

At CES on January 5, 2026, NVIDIA said OSMO was generally available as an open-source framework on GitHub. The public repository is licensed under Apache 2.0 and includes the service code, command-line client, deployment manifests, documentation, and example workflows. NVIDIA also distributes versioned Helm charts and container artifacts through NGC; using those packaged artifacts is subject to the terms shown by NGC.[2][4][11]

No separate software price is published for the self-hosted Apache-licensed code. Operators still pay for their Kubernetes clusters, databases, object storage, networking, GPUs, and any commercial tools or cloud services used inside a workflow. Partner-operated offerings, such as integrations from Microsoft Azure or Nebius, are separate services with their own access and pricing.[2][9]

Architecture and workflow model

An OSMO deployment separates a central control plane from one or more compute backends. The control plane exposes REST APIs used by the CLI and web interface. Its workflow engine validates a YAML specification, builds a directed execution graph, tracks state, and submits ready tasks to a scheduler. Registered compute is organized into pools and hardware platforms. Each task runs as a Kubernetes pod with its requested container image, CPU, memory, GPU, environment, and credentials.[5]

Tasks may run serially, in parallel, or in dependency groups. The workflow specification supports inputs and outputs, secrets, timeouts, checkpoints, file injection, exit actions, and host mounts. Interactive jobs can expose SSH, Jupyter, or VS Code access for remote development. Logs and metrics flow back through the control plane, while retryable failures can be rescheduled and non-retryable failures block dependent tasks.[5]

The data layer connects workflow tasks to S3-compatible object storage or Azure Blob Storage. OSMO can inject inputs into a container, persist its outputs, and pass those outputs to downstream tasks. NVIDIA describes datasets as content-addressable and tracks data versions and lineage, which can help identify which inputs produced an artifact.[1][3][5]

Physical AI workflows

OSMO's main role is to join otherwise separate stages of a physical AI pipeline. An operator might run NVIDIA Isaac Sim to generate simulated sensor data, use NVIDIA Isaac Lab to train a robot policy, and then evaluate it on an edge target. HIL workflows can reserve on-premises hardware while simulation and training tasks run on larger remote clusters.[1][4]

It can also coordinate workflows that use NVIDIA Cosmos for video or synthetic-data augmentation and NVIDIA Omniverse technologies such as NuRec and OpenUSD assets for scene construction. These products remain separate components with their own requirements and licenses. OSMO only sequences their containerized jobs and moves data among them.[3][8]

NVIDIA originally described OSMO as coordinating DGX training systems, OVX simulation systems, and Arm edge devices for Isaac GR00T. The current documentation supports EKS, AKS, GKE, on-premises Kubernetes, and NVIDIA Jetson targets. It does not document a special NVIDIA DGX Cloud adapter. A DGX or cloud environment is usable to the extent that an administrator exposes compatible Kubernetes compute, storage, networking, and credentials to OSMO.[1][5][6]

In March 2026, NVIDIA made OSMO the orchestration layer in its Physical AI Data Factory Blueprint. The company also added context files for coding agents including Claude Code, Cursor, and OpenAI Codex. Those files let an agent use the CLI to inspect capacity, submit workflows, and monitor runs. They do not make OSMO itself a model or guarantee that an agent's actions are safe or correct.[3][9]

Deployment and hardware

For a production-style cloud installation, NVIDIA's guide requires Kubernetes 1.27 or later, PostgreSQL 15 or later, Redis 7 or later, and network connectivity among those services. Its stated minimum for the OSMO service is 8 CPU cores, 32 GB of memory, and 100 GB of storage; PostgreSQL and Redis have additional minimums. The deployment uses Helm, kubectl, and an OSMO backend operator to register compute clusters.[6]

Local deployment uses Docker and KIND to create a Kubernetes environment on one workstation, with local object storage and the same YAML workflow format used for remote clusters. A GPU is optional for the control path and CPU-only examples, but a task that runs Isaac Sim, neural-network training, or another accelerated application retains that application's hardware and driver requirements. The client itself supports Ubuntu 22.04 or later on x86-64 and Arm64, and macOS 14 or later on Apple silicon. NVIDIA lists 1 CPU core, 1 GB of memory, and 500 MB of disk as the CLI minimum.[6]

This distinction matters: OSMO can hide Kubernetes details from a workflow author after a platform team has configured the service, but it does not remove infrastructure administration. A production installation still needs cluster capacity, storage, DNS, TLS certificates, an identity system, container registries, secrets, and observability. NVIDIA's own networking guide recommends cloud-networking and DevOps experience.[6]

Security and reproducibility

OSMO can connect its Envoy gateway to an external identity provider through OAuth 2.0 and OpenID Connect. It maps users or identity-provider groups to roles and policies, supports service accounts and access tokens for automation, and stores passwords and credentials in Kubernetes secrets. NVIDIA recommends an external identity provider for production. The simplified deployment mode can disable authorization and inject a default administrator identity, so it is intended for development rather than an exposed production service.[7]

TLS, role design, secret rotation, registry permissions, object-store policies, and network isolation remain deployment responsibilities. Workflows can execute arbitrary container images and may receive credentials or host mounts, giving a submitted job the access configured by the operator. Coding-agent access adds another privileged automation path and should be bounded by the same least-privilege controls.

Declarative YAML, versioned workflow definitions, content-addressed data, and recorded lineage provide useful reproducibility mechanisms. They do not by themselves reproduce an experiment. Mutable container tags, changing external datasets, unpinned dependencies, hardware differences, random seeds, and nondeterministic GPU operations can still change results. Teams need immutable image digests, retained inputs, captured configuration, and application-level experiment records in addition to OSMO's workflow history.

Limitations

OSMO's portability is limited to environments that can run its control services and Kubernetes-based backends. Hardware-specific tasks are not made portable merely by placing them in YAML. HIL tests still require access to the physical device, and applications using NVIDIA simulation or training software must meet those tools' GPU, driver, and license requirements.[3][5]

The platform does not directly deploy models to robots, provide a model registry, compare experiments, validate model quality, or certify a robot's safety. It orchestrates whatever commands and tests the workflow author supplies. NVIDIA publishes examples and says OSMO runs large internal robotics workloads, but no independent, model-specific benchmark establishes its scheduling efficiency, reliability, or cost advantage against general workflow systems.[3][4]

Independent coverage has described OSMO as connective infrastructure for NVIDIA's wider robotics stack rather than a new model or robot platform. That framing is useful: its value depends on the backends, simulation tools, training code, datasets, and operational controls connected to it. The Apache-licensed release makes the orchestrator inspectable and self-hostable, but operating a secure multi-cluster installation remains a substantial systems task.[10]

References

Erin Rapacki and Spencer Huang. "Scale AI-Enabled Robotics Development Workloads with NVIDIA OSMO." NVIDIA Technical Blog, March 18, 2024. https://developer.nvidia.com/blog/scale-ai-enabled-robotics-development-workloads-with-nvidia-osmo/
NVIDIA. "NVIDIA Releases New Physical AI Models as Global Partners Unveil Next-Generation Robots." January 5, 2026. https://nvidianews.nvidia.com/news/nvidia-releases-new-physical-ai-models-as-global-partners-unveil-next-generation-robots
NVIDIA Developer. "NVIDIA OSMO." https://developer.nvidia.com/osmo
NVIDIA. "NVIDIA/OSMO." GitHub. https://github.com/NVIDIA/OSMO
NVIDIA OSMO Documentation. "Architecture." https://nvidia.github.io/OSMO/main/user_guide/architecture.html
NVIDIA OSMO Documentation. "Deployment Guide." https://nvidia.github.io/OSMO/main/deployment_guide/index.html
NVIDIA OSMO Documentation. "Authentication and Authorization." https://nvidia.github.io/OSMO/main/deployment_guide/appendix/authentication/index.html
Asawaree Bhide, Jathavan Sriram, Saurav Nanda, and Aigul Dzhumamuratova. "Build and Orchestrate End-to-End SDG Workflows with NVIDIA Isaac Sim and NVIDIA OSMO." NVIDIA Technical Blog, January 7, 2026. https://developer.nvidia.com/blog/build-synthetic-data-pipelines-to-train-smarter-robots-with-nvidia-isaac-sim/
NVIDIA. "NVIDIA Announces Open Physical AI Data Factory Blueprint to Accelerate Robotics, Vision AI Agents and Autonomous Vehicle Development." March 16, 2026. https://nvidianews.nvidia.com/news/nvidia-announces-open-physical-ai-data-factory-blueprint-to-accelerate-robotics-vision-ai-agents-and-autonomous-vehicle-development
Rebecca Bellan. "Nvidia wants to be the Android of generalist robotics." TechCrunch, January 5, 2026. https://techcrunch.com/2026/01/05/nvidia-wants-to-be-the-android-of-generalist-robotics/
NVIDIA NGC. "NVIDIA OSMO." Updated June 23, 2026. https://catalog.ngc.nvidia.com/orgs/nvidia/osmo/collections/osmo/-

Editing: NVIDIA OSMO