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:
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.
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:
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.