Ecosystem
NemoClaw provides onboarding, lifecycle management, and OpenClaw operations in OpenShell containers.
This page explains how these projects fit together, where NemoClaw sits relative to OpenShell and OpenClaw, and when to choose NemoClaw or OpenShell directly.
How the Stack Fits Together
A NemoClaw deployment for OpenClaw combines three pieces with distinct scopes: OpenClaw, OpenShell, and NemoClaw. The following diagram shows how they fit together.
NemoClaw sits above OpenShell in the operator workflow. It calls OpenShell APIs and CLI commands to create and configure the sandbox that runs OpenClaw. Models and endpoints sit behind OpenShell’s inference routing. NemoClaw onboarding connects your provider choice to that route.
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 path 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 choose NemoClaw or OpenShell.
Related Topics
- Overview defines NemoClaw’s capabilities, benefits, and use cases.
- How It Works describes how NemoClaw runs, including the plugin, blueprint, sandbox creation, routing, and protection layers.
- Architecture shows the repository structure and technical diagrams.
- NemoClaw Community collects community-driven examples, showcases, and integrations that demonstrate complete blueprint patterns.