Learn Firecracker - Serverless & PaaS on Top of MicroVMs

#Introduction

So far we've built microVMs from the inside: images, snapshots, networking, security. Episode 18 looks outward — to the products that stand on top of Firecracker — and understands why the architecture we've learned makes those products possible.

Why is this episode important? Because Firecracker isn't the end product; it's an enabler. Every product in this episode — from Lambda to AI agent sandboxes — uses a combination of the patterns you've already mastered: fast boot, snapshots, VM-level isolation, and the jailer. Understanding the products on top of Firecracker gives you a map of opportunities: which patterns you can replicate in your own platform, and where Firecracker beats other technologies.

#FaaS: AWS Lambda

The FaaS pattern is Firecracker's purest form: a function runs when requested, stops when done, and never shares a kernel with another function.

• Isolation per function: each invocation (or group of invocations) gets its own microVM — not a container namespace.
• Acceptable cold starts: with lightweight images + snapshot warm pools (episode 9), functions come up in milliseconds.
• Natural scale-to-zero: when there's no demand, the VM dies — no idle cost.

This is what makes the figure of 15 trillion Lambda invocations per month plausible: each invocation pays for the smallest possible microVM, for as short as possible.

#PaaS: Fargate and Fly.io

PaaS is Fargate's "heavier" sibling: a platform running applications (not functions) with strong isolation and automatic orchestration.

• AWS Fargate uses microVMs to run ECS/EKS tasks without you managing nodes — each task is a microVM, and every machine you never see is a host running Firecracker.
• Fly.io builds a global application platform on top of microVMs: apps are deployed as images, run in microVMs near the user, and moved between regions with snapshots.

The pattern used: container image → microVM → multi-region orchestration. Developers never see the kernel or hypervisor — they see the platform.

#AI Agent Sandboxes: E2B, Daytona, and Vercel

The newest generation of products on Firecracker is sandboxes for AI agents: execution environments where AI-generated code runs safely.

• E2B — sandboxes that can be spawned in milliseconds for agents; each AI session gets an isolated microVM.
• Daytona — a cloud dev environment based on microVMs.
• Vercel — a deployment platform using strong isolation for user workloads.

Why do AI agents need microVMs? Because the code an agent executes can't be trusted: an agent can be wrong, write dangerous code, or be hijacked by prompt injection. MicroVMs give a hard boundary: the code may destroy its own sandbox — nothing more. The "sandbox per user/job" pattern we covered in episode 12 becomes a mandatory architecture in this product class.

#AWS Lambda MicroVMs (June 2026)

In June 2026, AWS introduced Lambda MicroVMs — an evolution of Lambda that expands the workload range. The technical highlights:

• VM-level isolation per user/job — every user (or job) gets its own VM, not shared with other users. This is far stricter isolation than the previous multi-tenant model.
• Suspend/resume up to 8 hours — a VM can be frozen and revived up to 8 hours later, preserving state and connections. This is the Firecracker snapshot sold as a product feature (episode 9).
• Capacity up to 16 vCPU / 32 GB — microVMs far larger than classic Lambda functions, opening up heavier workloads: big processing, long-running jobs, stateful applications.
• Building images from a Dockerfile — developers describe the image as an ordinary Dockerfile; the platform converts it into a microVM rootfs. This is the image tooling from episodes 8 and 11 lifted into a product experience.

What we can learn from Lambda MicroVMs:

1. Isolation per user is a business feature — not just a technical detail. Promising "your own VM" is product differentiation.
2. Snapshot is a product API — 8-hour suspend/resume is proof that infrastructure (snapshots, warm pools) can be sold directly.
3. The Dockerfile is the gateway — container ergonomics (not kernel config) is what makes microVMs broadly adoptable.

#An Architecture You Can Copy

All the products above can be reduced to blocks you've already learned:

image_build:    # Dockerfile -> rootfs microVM (episode 8, 11)
  - pull image OCI
  - convert layer -> ext4 rootfs
warm_pool:      # ready-to-use snapshot (episode 9)
  - boot base VM
  - init application
  - create Full snapshot
  - pause / hold
on_request:     # critical path (episode 9)
  - restore snapshot
  - configure network + MMDS
  - resume
isolation:      # security (episode 7, 14)
  - jailer per VM
  - cgroup + rate limiter
  - seccomp
lifecycle:      # ops (episode 12, 20)
  - orchestrator create/delete
  - health check + metrics
  - garbage collect snapshots

These blocks, arranged to fit the product's needs, are what platform teams around the world run — from AI sandbox startups all the way to AWS itself.

#Common Pitfalls

• Copying Lambda without a warm pool: cold-starting every request without a snapshot will feel expensive; invest in a warm pool first.
• Isolation per user without quotas: one greedy user exhausts the host; set cgroups and rate limiters (episode 10).
• A Dockerfile made only for containers: images needing odd devices or mounts won't run directly in a microVM.
• Forgetting garbage collection: accumulated snapshots eat disk; enable a cleanup cycle (episode 19).
• Selling "VM isolation" without testing it: security claims must be tested with failure injection (episode 16).

#Closing

The key takeaways:

• FaaS (Lambda), PaaS (Fargate, Fly.io), and AI sandboxes (E2B, Daytona, Vercel) all sit on microVMs.
• Shared pattern: immutable image + fast boot/snapshot + VM-level isolation + orchestration.
• Lambda MicroVMs (Jun 2026): isolation per user/job, 8-hour suspend/resume, 16 vCPU/32 GB, built from Dockerfiles.
• Snapshot is a sellable product feature — not just internal tooling.
• Your platform architecture = blocks you've already learned: build → warm pool → restore → isolation → lifecycle.

In the next episode 19 we'll compute capacity: Scaling — Many MicroVMs per Host — chasing thousands of microVMs per host with a jailer per VM, cgroup v2, page cache sharing, and memory overcommit via balloon, plus the practices of a daemon per microVM, health checks, and snapshot garbage collection.