What Is a Firecracker MicroVM?
How lightweight virtual machines power serverless functions and code sandboxes.
Firecracker runs lightweight virtual machines called microVMs. It was developed at AWS for services such as Lambda and Fargate, where large numbers of short-lived workloads need to start quickly and run in isolation.
Firecracker uses Linux KVM for hardware virtualization. Each microVM has its own Linux kernel, while a small set of virtual devices keeps the machine simpler than a general-purpose VM. Serverless platforms and services that execute code from different users use this design to isolate their workloads.
We'll also look at how Encore lets teams deploy backends in their own AWS or GCP account without managing VM hosts. The platform provisions the infrastructure declared in application code and handles deployment.
Firecracker, containers, and conventional VMs
How a microVM starts
Firecracker runs on a Linux host with access to KVM through /dev/kvm. Each Firecracker process manages one microVM. A program on the host configures it through an HTTP API exposed over a Unix socket.
Before boot, the program supplies a guest kernel and root filesystem, sets the virtual CPU count and memory, and configures any block devices or network interfaces. The API's InstanceStart action then boots the guest.
The guest runs its own Linux userspace, which can start the function runner, application, or task agent included in the image. Firecracker provides the virtual machine; the software inside the guest receives the work to execute.
The project's getting-started guide walks through preparing images and booting a guest. Running those steps creates an individual microVM. A service that offers sandboxes to users also needs to choose a host, deliver each task, and collect its result.
Why is Firecracker lightweight?
A general-purpose VM supports a broad range of guest operating systems and virtual hardware. Firecracker is designed around a narrower set of Linux workloads and includes fewer emulated devices. The guest has less machine setup to perform, and the VMM has less device-emulation code to maintain.
This design reduces the overhead of creating many small VMs. It is especially useful for a platform that frequently starts new execution environments instead of keeping a large machine running for one application.
The time a user waits includes more than booting the guest. The platform may need to fetch an image, find capacity on a host, and initialize the software inside the microVM. Firecracker boot measurements describe one part of that sequence.
How isolation works
KVM separates the guest's execution from the host, and each microVM runs its own kernel. Code inside one guest therefore uses that guest kernel rather than making system calls directly into the host kernel, as an ordinary Linux container does.
Firecracker also runs as a host process that needs confinement. The project provides a jailer that prepares the process environment, limits its access to host files, and drops privileges before running it. Seccomp filters restrict the host system calls available to the VMM.
The host and guest kernels still receive security updates, as does Firecracker itself. A sandbox operator maintains those images and host configurations as part of running the service.
From a microVM to a code sandbox
A code sandbox service accepts a task, places it in an execution environment, and returns the output. Firecracker can supply the VM for that environment. The service around it manages the request from arrival through cleanup.
The guest needs a way to receive commands, such as an agent included in its image. Firecracker's management API configures the VM; command execution inside the guest is handled by that tooling.
Networking also needs host-side configuration. A guest can use a virtual network interface, but the sandbox service controls how that interface reaches other systems. This is where the platform provides access to repositories, package registries, or a backend the task needs to call.
Snapshots let an operator restore a prepared microVM state rather than booting the environment from scratch every time. The platform maintains the snapshot images and handles the connections and task-specific state that need to be refreshed after restore.
How does it relate to container tooling?
A container image can be used as the application package inside a microVM. Projects such as firecracker-containerd provide integration between container tooling and Firecracker, so packaging and VM isolation can be used together.
Kata Containers also connects VM-backed isolation to container management interfaces. gVisor takes another approach, implementing a userspace application kernel that handles many of the interfaces an application would otherwise use on the host. Their architectures affect how applications interact with the host and which workloads they support.
Deploying a backend with Encore
Teams building a backend can use Encore to deploy it in their own AWS or GCP account without operating microVM hosts. The application declares the services and infrastructure it needs in code, and the platform provisions those resources and deploys the backend through a managed workflow.
For a service that uses a database, the declaration tells the platform what to create and which services need access. Encore provisions managed Postgres through RDS or Cloud SQL and configures the application's connection. Changes to the declared infrastructure are handled as part of deployment.
The development workflow uses the same declarations locally. Running encore run starts the application and local resources, while the managed platform provides deployments, logs, and tracing for environments in your cloud account.
Run in your terminal to get started locally.
Related guides
Frequently asked questions
Can Firecracker boot a Docker image directly?
Firecracker boots a guest kernel and root filesystem. Container tooling can prepare an image's contents for use inside a microVM, but an OCI image is not itself a complete Firecracker guest configuration.
Deploy to your cloud on AWS and Google Cloud
without managing infrastructure
Encore lets developers and agents define application infrastructure directly in code, then automatically provisions it from local development to production in your AWS or GCP account.
