Ecosystem
NemoClaw provides onboarding, lifecycle management, and OpenClaw operations within OpenShell containers.
This page describes how the ecosystem is formed across projects, where NemoClaw sits relative to OpenShell and OpenClaw, and how to choose between NemoClaw and OpenShell.
How the Stack Fits Together
There are three pieces that are put together in a NemoClaw deployment: OpenClaw, OpenShell, and NemoClaw, each with a distinct scope. The following diagram shows how they fit together.
NemoClaw sits above OpenShell in the operator workflow. It drives OpenShell APIs and CLI to create and configure the sandbox that runs OpenClaw. Models and endpoints sit behind OpenShell’s inference routing. NemoClaw onboarding wires provider choice into that routing.
The following table shows the scope of each component in the stack.
NemoClaw Path versus OpenShell Path
Both paths assume OpenShell can sandbox a workload. The difference is who owns the integration work.
What NemoClaw Adds Beyond the OpenShell Community Sandbox
OpenShell ships a community sandbox for OpenClaw.
Running openshell sandbox create --from openclaw pulls that package, builds the image, applies the bundled policy, and starts a working sandbox.
This is a valid path, and it produces a running OpenClaw environment with OpenShell isolation.
NemoClaw builds on that foundation with additional security hardening, automation, and lifecycle tooling. The following table compares the two paths.
When to Use Which
Use the following table to decide when to use NemoClaw versus OpenShell.
Related topics
- Overview contains what NemoClaw is, capabilities, benefits, and use cases.
- How It Works describes how NemoClaw runs, plugin, blueprint, sandbox creation, routing, protection layers.
- Architecture shows the repository structure and technical diagrams.