Where Sandlock Fits
Not a smaller container runtime, not a lightweight VM: kernel-enforced confinement of a process, with no image, no privilege, and no boot.
Sandlock, Containers, and MicroVMs
Figures from Sandlock's benchmark suite on a typical workstation. Treat them as an order of magnitude.
| Property | Sandlock | Container | MicroVM (Firecracker) |
|---|---|---|---|
| Root required | No | Yes* | Yes (KVM) |
| Image build | No | Yes | Yes |
| Startup time | ~5 ms | ~200 ms | ~100 ms |
| Kernel | Shared | Shared | Separate guest |
| Filesystem isolation | Landlock + seccomp COW | Overlay | Block-level |
| Network isolation | Landlock + seccomp notify | Network namespace | TAP device |
| HTTP-level ACL | Method + host + path rules | Not available | Not available |
| Syscall filtering | seccomp-bpf | seccomp | Not applicable |
| Resource limits | seccomp notify + SIGSTOP | cgroup v2 | VM configuration |
| Programmable interception | Handler API on any syscall | Not available | Not available |
* Rootless containers need user namespaces and a configured /etc/subuid, itself a privileged operation.
Overlap With Related Tools
Where the overlap ends, and when to reach for the other tool.
gVisor
A userspace kernel that reimplements the Linux syscall interface.
- Difference
- Every syscall goes through the Sentry. Sandlock leaves the host kernel in the path and intercepts only calls that carry a policy decision.
- Prefer gVisor when
- Running a full untrusted OS image and able to absorb the per-syscall cost.
bubblewrap and firejail
Confinement assembled from mount, PID, and user namespaces.
- Difference
- An access-control ruleset, not a constructed namespace: no filesystem to assemble, no user namespaces, plus IP allowlists, HTTP rules, credential injection, and COW rollback that namespaces cannot express.
- Prefer them when
- Sandboxing desktop applications, where a private namespace view is the goal.
OpenShell
NVIDIA's agent control plane: gateway, policy engine, and model-call routing.
- Difference
- A layer above a sandbox, not a sandbox: it needs Docker, Podman, a microVM, or Kubernetes underneath. Sandlock is the confinement itself. They compose rather than compete.
- Prefer OpenShell when
- You want the control plane, especially its inference routing. Sandlock governs the request, not which model serves it.
runc and Kubernetes
The default OCI runtime, built from namespaces, cgroups, and pivot_root.
- Difference
- Not either/or.
sandlock-ociimplements the same interface, producing a namespace-less, cgroup-less container from unchanged images. - Prefer runc when
- The workload needs a private PID or network namespace specifically.
When Sandlock Is the Wrong Tool
The wrong primitive buys confidence you have not earned. In these cases, reach for something else.
You need a separate kernel
The workload shares your kernel. If your threat model includes a kernel exploit, you need a hypervisor boundary.
Use insteadA microVM, or Multikernel's per-workload kernel.
You need to boot a system
Sandlock confines processes, not machines. Anything expecting init, systemd, or kernel modules wants a VM.
Use insteadA virtual machine.
Your kernel is older than 6.12
Landlock ABI v6 lands in 6.12 and the strict default refuses to start without it. Usually only the two IPC scopes are at stake.
Use insteadSandlock with the missing protections waived per policy, knowingly.
You need hard CPU or memory guarantees
Limits come from the supervisor, not cgroups. They bound consumption without reserving capacity.
Use insteadA cgroup on the Sandlock process itself. The two compose.
You are not on Linux
The design rests on Landlock and seccomp. There is no port and will not be one.
Use insteadA VM, or platform-native sandboxing.
You need rotating secrets
Credential injection loads the secret once at start; a rotated value is picked up on the next run.
Use insteadRestart the sandbox on rotation.
Still Deciding?
Read the security model, or bring us the workload and we will tell you honestly whether Sandlock is the right boundary.