Problem
The Docker backend isolates sandboxes with namespaces/cgroups, so every sandbox still shares the host kernel. For untrusted or AI-generated code, a kernel exploit remains an escape path, and hardening options (seccomp,
gVisor) add complexity without true hardware isolation.
Proposal
Add SmolVM as an optional backend engine. SmolVM runs each sandbox in its own microVM (Firecracker on Linux, QEMU on macOS), providing hardware-level isolation with ~500 ms boot times, which is fast enough to sit behind the existing engine interface without hurting UX.
Capabilities that map cleanly onto a Docker-style backend contract:
- Python SDK + CLI for create/exec/stop lifecycle
- Host directory mounts (read-only by default, opt-in writable)
- Per-sandbox network egress controls (domain allow-lists)
- Snapshots and pause/resume for persistent sessions
- Apache 2.0, pip-installable, no Rust toolchain needed on supported hosts
Problem
The Docker backend isolates sandboxes with namespaces/cgroups, so every sandbox still shares the host kernel. For untrusted or AI-generated code, a kernel exploit remains an escape path, and hardening options (seccomp,
gVisor) add complexity without true hardware isolation.
Proposal
Add SmolVM as an optional backend engine. SmolVM runs each sandbox in its own microVM (Firecracker on Linux, QEMU on macOS), providing hardware-level isolation with ~500 ms boot times, which is fast enough to sit behind the existing engine interface without hurting UX.
Capabilities that map cleanly onto a Docker-style backend contract: