NVIDIA open-sources OSMO, a Kubernetes orchestrator for robotics AI

NVIDIA has open-sourced OSMO, a Kubernetes-native workflow orchestrator built for Physical AI and robotics. The project lives on GitHub and ships with a public user guide. In short, OSMO is the glue NVIDIA used internally to move robotics jobs across training, simulation and real hardware without writing a new pipeline every time.

What OSMO is

OSMO is a workflow orchestrator on top of Kubernetes. Robotics teams describe a full pipeline in one YAML file: training, simulation, and hardware-in-the-loop tests. OSMO then routes each job to the right compute. That means the same workflow definition can span heterogeneous machines instead of forcing teams to hand-craft separate scripts for each stage.

Where it runs

The design spans the full NVIDIA stack. The same workflow can target large data-center GPU clusters, including systems like GB200, and edge devices such as Jetson AGX Thor. NVIDIA says it already used OSMO internally for Project GR00T, Isaac Lab, Isaac Sim and related parts of the Isaac robotics stack. Open-sourcing it is a way to let outside teams reuse the same orchestration pattern.

Why NVIDIA opened it

NVIDIA's stated reason is practical. Robotics teams kept rewriting the same glue code to move jobs between simulation and real robots. OSMO is meant to stop that duplication. Opening the project is a bet that Physical AI needs a shared orchestration layer, not more one-off scripts between sim and hardware.

Why it matters

Physical AI is not only about models. It is also about the boring plumbing that gets data, training and robot tests onto the right machines. A Kubernetes-native orchestrator that already spans data-center GPUs and Jetson edge devices is useful because most labs already run Kubernetes, and most robotics stacks still glue stages together by hand. If OSMO sticks, teams can spend less time on pipeline glue and more time on policies and hardware.

Dany's take

NVIDIA already sells the chips and the sim stack. Opening the orchestrator that ties them together is a smart move: it makes the whole Physical AI path stickier without locking the glue behind a closed API. I would watch how quickly outside labs adopt the YAML workflows, and whether OSMO stays lightweight enough for small teams, not only GB200 clusters. Would you run your robot training through an open NVIDIA orchestrator?

Sources: NVIDIA/OSMO on GitHub, OSMO user guide.