Where Sandlock Fits
Sandlock is not a container runtime with a smaller footprint, and it is not a lightweight VM. It occupies a different point entirely: strict, kernel-enforced confinement of a process, with no image, no privilege, and no boot.
Sandlock, Containers, and MicroVMs
The measured figures come from Sandlock's own benchmark suite on a typical Linux workstation. Treat them as an order of magnitude, not a guarantee for your hardware.
| 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 exist, but they require user-namespace support and a configured /etc/subuid. On a locked-down host, that configuration is itself a privileged operation.
Overlap With Related Tools
Each solves part of the same problem. This is where the overlap ends, and which tool to reach for instead.
gVisor
A userspace kernel that reimplements the Linux syscall interface.
- Difference
- Every syscall is serviced by the Sentry, and compatibility depends on how completely it reimplements the interface. Sandlock leaves the host kernel in the syscall path and intercepts only the calls that carry a policy decision.
- Prefer gVisor when
- You are running a full untrusted OS image and can absorb the per-syscall cost.
bubblewrap and firejail
Confinement assembled from mount, PID, and user namespaces.
- Difference
- Sandlock's policy is an access-control ruleset, not a constructed namespace, so there is no filesystem to assemble and no user-namespace requirement. It also covers ground namespaces do not: destination-IP allowlists, HTTP method and path rules, credential injection, and copy-on-write rollback.
- Prefer them when
- You are sandboxing desktop applications, where a private namespace view is itself the goal.
OpenShell
An agent-first control plane from NVIDIA: a gateway, a policy engine, and privacy-aware routing for model calls.
- Difference
- OpenShell is a layer above a sandbox rather than a sandbox. It requires Docker, Podman, a microVM, or Kubernetes underneath and coordinates their lifecycle; Sandlock is the confinement itself, with no runtime to install and no image to build. They compose more naturally than they compete.
- Prefer OpenShell when
- You want the control plane around the sandbox, particularly its inference routing, which keeps sensitive context on sandbox compute and swaps model backends at runtime. Sandlock has no equivalent; its HTTP ACL and credential injection govern 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 runtime interface, producing a namespace-less, cgroup-less container that runs unprivileged, so existing OCI images need no changes. - Prefer runc when
- Your workload depends on a container-private PID or network namespace specifically, rather than on the isolation they provide.
When Sandlock Is the Wrong Tool
Picking the wrong isolation primitive is worse than picking none, because it buys confidence you have not earned. In these cases, reach for something else.
You need a separate kernel
The workload runs on your kernel, so a kernel-level vulnerability is a shared risk. If your threat model includes an attacker willing to spend 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. A workload that expects init, systemd, a full device tree, or its own kernel modules is asking for the wrong abstraction.
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 the protections it expects. Usually only the two v6 IPC scopes are at stake; every earlier protection has its own, lower kernel floor.
Use insteadSandlock with the missing protections degraded per policy, accepting that each one waived is confinement you no longer have.
You need hard CPU or memory guarantees
Limits come from the supervisor, not cgroups: memory by tracking allocation syscalls, CPU by cycling SIGSTOP and SIGCONT. That bounds consumption without reserving capacity.
Use insteadA cgroup on the Sandlock process itself. The two compose.
You are not on Linux
Landlock and seccomp are Linux facilities, and the entire design rests on them. There is no port to another platform and there will not be one.
Use insteadA VM, or platform-native sandboxing.
You need rotating secrets
Credential injection loads the secret once at supervisor start, so a leased or rotating value is only picked up on the next run.
Use insteadRestart the sandbox on rotation. Sandlock composes with a secret manager rather than embedding one.
Still Deciding?
Read the security model to see exactly what each layer enforces and what it does not, or bring us the workload and we will tell you honestly whether Sandlock is the right boundary for it.