Hi HN, I'm Angelo. I built vmsan because I wanted Firecracker's isolation without Firecracker's complexity.

If you've tried using Firecracker directly, you know the pain: setting up TAP devices, configuring the jailer, writing iptables rules, wiring up network namespaces, building rootfs images by hand. It's 30+ steps before you can boot a VM and run a command inside it. vmsan reduces that to:

  curl -fsSL https://vmsan.dev/install | bash
  vmsan create --connect

You're in a shell inside a Firecracker microVM. Sub-3 second boot. No SSH — a Go agent inside the VM handles exec, PTY, and file transfer over HTTP.

Some technical choices worth discussing:

- *nftables over iptables.* As of v0.2.0, all networking uses nftables via the google/nftables Go library (netlink, no shelling out). Each VM gets its own nftables table — teardown is one atomic flush instead of tracking dozens of rules. This also means ICMP and non-DNS UDP are blocked by default.

- *Network namespaces, not bridges.* Each VM lives in its own network namespace with a veth pair. The host routes traffic. This gives per-VM egress policies (allow-all, deny-all, or custom domain/CIDR allowlists) without iptables spaghetti.

- *Docker images as rootfs.* `--from-image node:22-alpine` pulls the image, extracts the filesystem, and builds an ext4 rootfs. You don't need to maintain custom AMIs or rootfs images.

- *Why not just Docker?* Firecracker VMs run their own kernel behind KVM. A container escape gives you the host; a VM escape gives you... another VM boundary. If you're running your own trusted code, Docker is fine. If you're running untrusted code, user-submitted workloads, or multi-tenant anything, the isolation model matters. vmsan tries to make the better isolation model just as easy to use.

Requirements: Linux with KVM support (/dev/kvm).

Feedback welcome — especially on the CLI UX and networking model.