The problem: cold starts

How snapshot-based cold start works

Architecture overview

IPC: how the host talks to the VM

Execution flow

Benchmark results

The tradeoffs

What I learned

Try it yourself Ever wondered what actually happens when you invoke a Lambda function? Not the API layer but the execution layer. What runs your code, how it's isolated, and how AWS gets cold starts low enough to be usable? I wanted to understand that deeply. So I built it. This is a breakdown of how I built a Firecracker-based serverless runtime from scratch, the architectural decisions I made, and what the numbers look like. Every serverless platform faces the same fundamental tension. You want functions to start instantly, but strong isolation requires spinning up a fresh environment per invocation. A standard Linux VM boot takes ~200ms at minimum. At scale, that's unusable. AWS's solution and the core idea behind this project is VM snapshots. Instead of booting a VM on every invocation: Restoring from a snapshot takes 1–5ms. A full cold boot takes 200ms. That's a 40–200x improvement. This is exactly what AWS does with Lambda's Firecracker-based execution model. The system has two main components: Control Plane — handles everything outside the VM: MicroVM Runtime — runs inside each Firecracker VM: This is where a lot of serverless runtimes lose performance. Every round-trip between host and VM has overhead. If you open a new connection per request, that overhead compounds. I used two mechanisms: Eliminating per-request connection setup was the key unlock for throughput. Benchmarked with autocannon — 10 concurrent connections, 30 seconds: Key optimizations that got here: snapshot reuse, persistent runtime across invocations, reduced IPC overhead from connection pooling. Runtime reuse introduces shared state. When you restore from a snapshot and reuse the same runtime across invocations, module-level state in the user's code persists between calls. Strong VM-level isolation, but the runtime isn't fully stateless. This is the same tradeoff AWS makes. Lambda execution environments are reused between invocations, they just don't guarantee it, and they don't tell you when a new one is created. Throughput vs. isolation purity. You can enforce one invocation-per-VM destroy and recreate for perfect isolation, but your throughput tanks. The snapshot model is the practical middle ground. Building this taught me more about OS-level virtualization than any course or book. Specifically: The full source, architecture diagrams, and setup instructions are on GitHub: 👉 github.com/vivek1504/serverless-runtime A prebuilt kernel image and rootfs are available in the releases so you don't have to build from scratch. You'll need a Linux host with KVM support (/dev/kvm accessible) and the Firecracker binary in your PATH. If you've built something similar or have questions about any part of the implementation, I'm happy to go deeper in the comments. Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse