- Category
- Developer Tools
- Rank
- No. 3609Tools index
- Pricing
- Open Source
- Type
- TOOL
- Use case
- Deployment & Operations
- Interfaces
- API · CLI
- GitHub
- 6 stars
- Date
About
FastVM is a single-host micro-VM sandbox runtime written in Go on top of Firecracker and KVM. Sandboxes boot in about 100 ms, pause themselves when idle, move guest memory to disk, and wake when a network packet arrives, with the packet already queued in the guest's network path. The README lists v0.1 core features as working and tested end-to-end on KVM, while the eBPF switch is not yet wired into the daemon.
At a glance
FastVM is an early Go daemon and CLI that runs each sandbox as a Firecracker microVM on one Linux KVM host. Idle sandboxes pause themselves, then hand their RAM to a memory file on disk. The VMM stays alive in a paused state, so an inbound request lands in the guest's network queue and wakes it. The author's repository note reads "Fully vibed. Read the idea, ignore the code please :)".
Good fit
Someone exploring how a self-hosted sandbox can sleep when idle and wake on traffic, for example a dev preview server published on a host port that should give memory back between visits. It also suits reading as a design study: GOAL.md lays out the wake path, memory offload and the reasons it keeps the VMM process running.
Consider something else when
You need something to run untrusted workloads in production. This is a v0.1 project with no releases, and the author asks readers to ignore the code. Also skip it if you lack a Linux x86_64 host with KVM and root, or need sandboxes spread across machines, macOS or Windows.
Start here
On a KVM host with Firecracker, Go 1.24+ and Docker, run make build && make assets, then sudo make demo. The demo builds a disk from a Dockerfile, publishes port 8080, waits for the sandbox to reach Dormant, then curls it. Success is the page text returned and wake_count: 1.
Cost and requirements
No price is stated, and the repository root lists no licence file. It needs Linux x86_64 with accessible /dev/kvm, Firecracker v1.10 or later (v1.17 tested), Go 1.24+ to build, and root or CAP_NET_ADMIN for TAP, bridge and nftables setup. Docker is needed only for fastvm build; e2fsprogs and nft are also required.
Limits to know
Sandboxes share the daemon's network namespace, isolated only by bridge port isolation and static rules. The eBPF switch is not wired in, even though the README's default config names it. After a daemon restart, sandboxes that were Running or Paused are marked failed. Only file and never memory offload work. Guest servers must listen on IPv4, and the serial console is not reattached after a restore.
Related work
Still unclear
- The README says sandboxes boot in about 100 ms, and GOAL.md sets wake-latency targets, but no published benchmark shows measured boot or wake times on a stated host.
Sources checked 2026-11-07. Source-based assessment.
Tags
Tech Stack
Comments (0)
No comments yet
Editorially curated, with community endorsements as a secondary signal. Corrections welcome.