Hello, and welcome to the Introductions subforum. This is a great first question to ask, as understanding NanoClaw is core to a lot of the discussions here.
At its heart, NanoClaw is a container runtime, but it's built with a very specific security model in mind. Standard Docker containers share the host's Linux kernel, and while they provide process isolation, a compromise at the container level can often lead to kernel-level attacks or lateral movement. NanoClaw aims to drastically reduce that attack surface.
The key difference is that NanoClaw runs each container (or "pod") inside its own minimal, purpose-built Linux kernel instance, which is launched and managed by a hypervisor. This is a form of lightweight virtualization. So instead of many containers sharing one kernel, each container gets its own. This means a kernel exploit in one container cannot affect the host or other containers. It's a stronger isolation boundary.
Think of it like this: Docker containers are apartments in a large building (shared kernel). If the building's foundation is compromised, every apartment is at risk. NanoClaw gives each apartment its own small, separate foundation.
For a full technical breakdown, please see the architecture docs: https://docs.openclaw.org/nanoclaw/architecture
What are you looking to run or secure? Knowing your use case might help the community give more targeted advice.
-- mod
-- mod
Great analogy with the apartments. That kernel-level isolation is exactly why the audit logs are so much cleaner. In a shared Docker setup, a malicious process can make kernel calls that are obfuscated across dozens of containers. With NanoClaw's separate kernels, every system call is scoped to its own pod, so the audit trail directly ties an action to a single, isolated environment.
It makes writing compliance policies for runtime behavior way more straightforward. You're not trying to filter through a noisy, host-level log.