I've been building tools around AI agents and kept hitting the same wall: I needed to run untrusted code in isolation. Docker isn't a security boundary (shared kernel, container escapes are well-documented). Kata Containers and raw Firecracker give you real isolation but require serious setup - writing JSON configs, managing TAP devices, building rootfs images, setting up jailers manually.
That's it. You're inside an isolated Firecracker microVM with its own kernel, jailer, seccomp filters, and network namespace. ~125ms boot time.
What vmsan does differently:
- *One-liner setup*: installs Firecracker, kernel, and rootfs automatically. No YAML, no JSON configs, no manual networking.
- *Docker images as VMs*: `vmsan create --from-image python:3.13-slim` converts any Docker/OCI image to a Firecracker rootfs and boots it. Cached locally for instant reuse.
- *Network isolation built-in*: `--network-policy deny-all` or custom allowlists with `--allowed-domain ".github.com"`. No iptables scripting.
- *Interactive shell without SSH*: WebSocket PTY via a lightweight Go agent inside the VM. Upload/download files over the same channel.
- *Automation-first*: every command supports `--json` for scripting and CI/CD pipelines.
Under the hood, each VM gets a /30 TAP subnet, runs inside Firecracker's jailer with cgroup limits, and communicates through a Go agent on port 9119. State lives in ~/.vmsan/ — no daemon, no background service.
Written in TypeScript (Bun), the Go agent is ~2MB.
Some use cases I'm targeting:
- AI agent code execution sandboxes
- Disposable dev/test environments
- Multi-tenant workload isolation
- CI/CD with untrusted build steps
I'm actively developing this and would love feedback - especially on the developer experience and any edge cases you hit. Happy to answer questions about the architecture or trade-offs.
angelorc•2h ago
I've been building tools around AI agents and kept hitting the same wall: I needed to run untrusted code in isolation. Docker isn't a security boundary (shared kernel, container escapes are well-documented). Kata Containers and raw Firecracker give you real isolation but require serious setup - writing JSON configs, managing TAP devices, building rootfs images, setting up jailers manually.
I wanted something that just works:
That's it. You're inside an isolated Firecracker microVM with its own kernel, jailer, seccomp filters, and network namespace. ~125ms boot time.What vmsan does differently:
- *One-liner setup*: installs Firecracker, kernel, and rootfs automatically. No YAML, no JSON configs, no manual networking. - *Docker images as VMs*: `vmsan create --from-image python:3.13-slim` converts any Docker/OCI image to a Firecracker rootfs and boots it. Cached locally for instant reuse. - *Network isolation built-in*: `--network-policy deny-all` or custom allowlists with `--allowed-domain ".github.com"`. No iptables scripting. - *Interactive shell without SSH*: WebSocket PTY via a lightweight Go agent inside the VM. Upload/download files over the same channel. - *Automation-first*: every command supports `--json` for scripting and CI/CD pipelines.
Under the hood, each VM gets a /30 TAP subnet, runs inside Firecracker's jailer with cgroup limits, and communicates through a Go agent on port 9119. State lives in ~/.vmsan/ — no daemon, no background service.
Written in TypeScript (Bun), the Go agent is ~2MB.
Some use cases I'm targeting: - AI agent code execution sandboxes - Disposable dev/test environments - Multi-tenant workload isolation - CI/CD with untrusted build steps
I'm actively developing this and would love feedback - especially on the developer experience and any edge cases you hit. Happy to answer questions about the architecture or trade-offs.
Docs: https://vmsan.dev