Show HN: Sub-millisecond VM sandboxes using CoW memory forking (github.com)
I wanted to see how fast an isolated code sandbox could start if I never had to boot a fresh VM.
So instead of launching a new microVM per execution, I boot Firecracker once with Python and numpy already loaded, then snapshot the full VM state. Every execution after that creates a new KVM VM backed by a `MAP_PRIVATE` mapping of the snapshot memory, so Linux gives me copy-on-write pages automatically.
That means each sandbox starts from an already-running Python process inside a real VM, runs the code, and exits.
These are real KVM VMs, not containers: separate guest kernel, separate guest memory, separate page tables. When a VM writes to memory, it gets a private copy of that page.
The hard part was not CoW itself. The hard part was resuming the snapshotted VM correctly.
Rust, Apache 2.0.
44 comments
[ 214 ms ] story [ 858 ms ] threadI keep thinking I need to see if CRIU (checkpoint restore in userspace) is going to work here. So I can put work down for longer time, be able to close & restore instances sort of on-demand.
I don't really love the idea of using VMs more, but I super love this project. Heck yes forking our processes/VMs.
https://GitHub.com/jgbrwn/vibebin
More than the sub ms startup time the 258kb of ram per VM is huge.
On Firecracker version: tested with v1.12, but the vmstate parser auto-detects offsets rather than hardcoding them, so it should work across versions.
That said, I have seen several use cases where people want a VM for something minimal, like a python interpreter, and this is absolutely the sort of approach they should be using. Lot of promise here, excited to see how far you can push it!
https://codesandbox.io/blog/how-we-clone-a-running-vm-in-2-s...
https://codesandbox.io/blog/how-we-clone-a-running-vm-in-2-s...
Are there parallels?
The firecracker team wrote a very good paper about addressing this when they added snapshot support.
The tricky part we keep running into with agent sandboxes is that code execution is just one piece, bcs agents also need file system access, memory, git, a pty, and a bunch of other tools all wired up and isolated together. That's where things get hairy fast.
Now I want the ability to freeze the VM cryogenically and move it to another machine automagically, defrosting and running as seamlessly as possible.
I know this is gonna happen soon enough, I've been waiting since the death of TandemOS for just this feature ..