Comment by ammmir

I've built the same thing twice, first with Firecracker microVM, and second time using containers (gVisor).

While the microVM route is more secure, it's more complicated and ops are tricky, but you can do some cool things to optimize startup time like when I was working on a function as a service platform, and to reduce TTFB, I trapped the `listen()` call, sent a VSOCK message to the VMM to trigger a freeze, snapshot the VM and save it as a "template". Then for every request, the snapshot was cloned (with some file system tricks like CoW) and resumed to handle the request. It "just" worked, but the orchestration was kludgy.

In the second incarnation of this, I decided to use Linux containers with the gVisor sandbox. You can take a look at my project https://github.com/ammmir/sandboxer which uses Podman and gVisor underneath; it's good enough for a prototype. Later on, you can swap it out with Firecracker microVM, if necessary. In fact, I'm thinking of adding microVM support to sandboxer itself. If you wanted to do it yourself, swap out ContainerEngine() with a new implementation based on calling out to Firecracker. You'll need some way to do disk volume management (grow, clone, shared, cross-machine? good luck!), snapshots, etc.