Firecracker Virtualization Overview

2025-12-11 1203 words 6 minutes

Contents

Firecracker is an open source virtualization technology created by Amazon Web Services (AWS) which underpins their AWS Lambda Functions as a Service (FaaS) serverless product.

Firecracker was open sourced in 2018 [0], making it possible for anyone to use this extremely fast and reliable system for their own projects and use cases.

I’ve been researching the ecosystem lately and am impressed at the flexibility architected into the Firecracker code which enables it to be used in many ways. We might have expected them to design it such that it only works in their very tightly controlled environment. But the fact that it’s not specialized to just the AWS Lambda use case means that it can be leveraged by anyone from AWS scale to a home lab running a single VM.

Let’s explore the capabilities of Firecracker and the various methods of using it.

Firecracker High Level Overview

There are many good quick start documents 1 and blogs describing how to install and start a single Firecracker MicroVM instance. Because of these great resources readily available, I won’t describe that here.

The basic requirements are:

Firecracker binary
kernel
rootfs
networking configuration (optional)

When you start a firecracker VM by executing the firecracker program, you are running a single VM instance which can be managed through the firecracker process you launched it with. You can send subsequent commands to perform additional management tasks to the firecracker process using the API via a unix socket. When you are done with the VM you can and should stop it “gracefully”.

Multiple firecracker processes can be executed at one time, which translates to running multiple VMs. Presumably this is how AWS runs millions of Lambda functions.

Configuration

There are a couple ways to configure your VM:

Sending HTTP requests via the API socket [2]
Using the configuration file [3]

If you use the configuration file to set the VM guest kernel and rootfs, you can still use the socket to send API requests. These configuration methods seem to conflict, but they appear to me to be part of the design of a highly flexible system.

The HTTP API is enhanced by what appears to be an official Go SDK [4] that you can use to manage your Firecracker VM instances. A likely scenario is that AWS uses this Go SDK to provision and control their Lambda functions via this HTTP API provided by the Firecracker process.

Initialization

Firecracker is also flexible in how it can be initialized. Options include:

command line execution
systemd
jailer

The first two options are obviously common to many Linux tools. But the diverse use cases that AWS themselves have for a multi-purpose virtualization technology like Firecracker make it likely that they designed it to be versatile. This adaptable capability extends from the configuration methods to initialization, and likely beyond.

Enhanced Isolation using Jailer

The jailer tool [5] which is specifically designed for firecracker further isolates each firecracker process to its own chroot jail directory. This security mechanism has been used for years in Unix systems and affords a greater sense of security in a multi-tenant environment.

We won’t go into detail on this for now, and it isn’t necessary for your home lab unless you’re running untrusted code (i.e. not written by you.)

Demonstration

To quickly show what we’ve discussed above, we’ll demonstrate with a small bash script that starts a Firecracker micro VM using previously downloaded kernel and rootfs. Here’s the script:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


#!/usr/bin/env bash

firecracker="/usr/bin/firecracker"

uuid=$(/usr/bin/uuidgen)

nohup $firecracker --api-sock /tmp/$uuid.socket &

echo "created firecracker process running on socket: /tmp/$uuid.socket"

curl --unix-socket /tmp/$uuid.socket -i \
    -X PUT 'http://localhost/boot-source' \
    -H 'Accept: application/json' \
    -H 'Content-Type: application/json' \
    -d '{
        "kernel_image_path": "/tmp/firecracker-test/hello-vmlinux.bin",
        "boot_args": "console=ttyS0 reboot=k panic=1 pci=off"
    }'

curl --unix-socket /tmp/$uuid.socket -i \
    -X PUT 'http://localhost/drives/rootfs' \
    -H 'Accept: application/json' \
    -H 'Content-Type: application/json' \
    -d '{
        "drive_id": "rootfs",
        "path_on_host": "/tmp/firecracker-test/hello-rootfs.ext4",
        "is_root_device": true,
        "is_read_only": false
    }'

curl --unix-socket /tmp/$uuid.socket -i \
    -X PUT 'http://localhost/actions' \
    -H  'Accept: application/json' \
    -H  'Content-Type: application/json' \
    -d '{
        "action_type": "InstanceStart"
    }'

echo "Started VM instance."

Running it we get the following output:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


user@temphost:~/data/firecracker-test$ ./startvm.sh 
created firecracker process running on socket: /tmp/b214c708-e506-455b-a98d-647939a0ef0d.socket
nohup: appending output to 'nohup.out'
HTTP/1.1 204 
Server: Firecracker API
Connection: keep-alive

HTTP/1.1 204 
Server: Firecracker API
Connection: keep-alive

HTTP/1.1 204 
Server: Firecracker API
Connection: keep-alive

Started VM instance.
user@temphost:~/data/firecracker-test$ tail nohup.out 
 [ ok ]
 * Mounting persistent storage (pstore) filesystem ...
 [ ok ]
Starting default runlevel
[    1.088111] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2879b124109, max_idle_ns: 440795245440 ns

Welcome to Alpine Linux 3.8
Kernel 4.14.55-84.37.amzn2.x86_64 on an x86_64 (ttyS0)

localhost login: 

You can see that we have a login prompt in the nohup.out file that indicates the VM is running and ready to accept logins. We didn’t setup any SSH keys in this attempt, nor networking, so we’re SOL on logging in. But that’s OK because we were just trying to show how straightforward this can be.

Notice we created a random UUID to use as the firecracker unix socket, which is how you can communicate with it via the HTTP API. After starting the firecracker process, we then make curl requests to configure the kernel, rootfs, and then initiate the InstanceStart action.

Granted, this is a very rudimentary example. But it shows how easily firecracker can be used if you understand the fundamentals.

Firecracker Ecosystem Discrepancies Compared to Lambda

In multiple AWS re:Invent talks, Lambda architecture has been detailed by AWS employees at a high level. One example is in Julian Wood’s 2022 session A closer look at AWS Lambda (SVS404-R). At 10:36 in the video, he references the Lambda data plane, which consists of a host of interrelated services for synchronous vs. asynchronous Lambda invocations. These services are:

Synchronous

Frontend Invoke Service
Counting Service
Assignment Service
Worker Hosts
Placement Service

Asynchronous

Poller Fleet
Queue Manager
State Manager
Stream Tracker
Leasing Service

The Cold Truth

These administrative services used to run millions or billions of AWS Lambda invocations are obviously not available for Firecracker. It makes sense that AWS would release their Firecracker product as open source, but they’re not likely to ever provide the facade that props Firecracker up in their environment, enabling AWS Lambda to be highly performant and reliable. But this is something I’m interested in. I think some of these features that streamline the functionality of Firecracker in the Lambda use case could be built to make it easier to manage for those of us who think this tool is exciting and wish it came with batteries included.

Conclusion

Over the next few weeks (and months) I’ll be playing with this some more. I’ll likely be posting as I do this to give a different perspective on firecracker than the standard quick start blogs out there already.

Hope you got something out of this today!

Cover photo by NASA Hubble Space Telescope on Unsplash