Building a Self-Hosted Cloud Functions (FaaS) Platform with Firecracker MicroVMs on Ubuntu VPS

Introduction: The Case for Self-Hosted Serverless Architecture

In the modern cloud computing landscape, Serverless architectures and Function-as-a-Service (FaaS) platforms like AWS Lambda, Google Cloud Functions, and Azure Functions have revolutionized deployment pipelines. They offer seamless scaling, abstract infrastructure management, and operate on a strict pay-as-you-go model. However, enterprise reliance on public FaaS vendors introduces specific trade-offs: vendor lock-in, cold start latencies, rigid execution runtime boundaries, and unpredictable data egress fees.

For businesses seeking absolute control over data sovereignty, strict execution environments, and cost predictability, public cloud offerings may not always align with strategic objectives. The alternative? Building a private FaaS infrastructure. Historically, this meant relying on heavy container orchestrators or traditional virtualization, sacrificing either isolation or speed. Enter AWS Firecracker—an open-source virtualization technology purpose-built for creating secure, multi-tenant containers and serverless services.

This technical guide provides an exhaustive architectural walkthrough for deploying Firecracker MicroVMs on a standard Ubuntu Virtual Private Server (VPS) with nested virtualization, laying the robust groundwork required to build your own high-performance, secure Cloud Functions infrastructure.

---

Understanding Firecracker: The Intersection of Containers and Traditional VMs

Before diving into configuration, it is critical to understand why Firecracker is uniquely suited for serverless workloads. Traditional deployment models generally fall into two categories:

Containers (e.g., Docker): Offer high speed, low memory overhead, and rapid initialization, but share the host operating system's kernel. This introduces potential security vulnerabilities in multi-tenant environments via kernel exploits.
Traditional Virtual Machines (e.g., KVM/QEMU): Provide strict hardware-level isolation and independent kernels, but suffer from heavy memory footprints, slower boot times, and substantial management overhead.

Firecracker bridges this gap. Developed by Amazon Web Services and written in Rust, Firecracker utilizes the Linux Kernel-based Virtual Machine (KVM) to spin up minimalist Virtual Machines, termed MicroVMs. It strips away unnecessary legacy device drivers and emulated hardware, leaving only the essential components required to run modern cloud workloads: a minimalist network interface, block storage, a serial console, and a 1-button partial CPU/memory balloon driver.

Key Metric: Firecracker MicroVMs can boot in less than 5 milliseconds and consume as little as 5 MB of RAM, achieving container-like agility with hardware-level virtual machine isolation.

---

Prerequisites and Environment Validation

To follow this guide successfully, you will need an Ubuntu VPS (Ubuntu 22.04 LTS or newer recommended) that supports Nested Virtualization. Because Firecracker leverages KVM, the underlying host must expose virtualization extensions to your VPS instance.

Step 1: Verify KVM Availability

Log into your Ubuntu VPS via SSH and execute the following commands to verify KVM capability:

lsmod | grep kvm
ls -l /dev/kvm

If /dev/kvm exists, your environment supports KVM virtualization. To confirm compatibility with Firecracker's strict requirements, check the read/write permissions of the file. Your current user must have access to this device node, which is typically managed by adding the user to the kvm group:

sudo usermod -aG kvm $USER

Log out and log back in to apply the group membership changes cleanly.

---

Installing Firecracker and Fundamental Binaries

Firecracker is distributed as a self-contained binary. To ensure security and maintainability, we will fetch the latest stable release directly from the official repository, rename it, and move it into the system's execution path.

Step 2: Download and Position Firecracker

Execute the following script block to determine your system architecture, download the appropriate binary, and grant execution rights:

ARCH=$(uname -m)
RELEASE_URL="[https://github.com/firecracker-microvm/firecracker/releases/latest/download/firecracker-v1.7.0-$](https://github.com/firecracker-microvm/firecracker/releases/latest/download/firecracker-v1.7.0-$){ARCH}"

curl -L ${RELEASE_URL} -o firecracker
chmod +x firecracker
sudo mv firecracker /usr/local/bin/firecracker

Verify the installation by running a version check: firecracker --version. If configured correctly, the system will output the software version alongside the build date.

---

Preparing the Foundation: Kernel and Root Filesystem

Unlike traditional virtual machines that boot using complex ISO images and bootloaders (like GRUB), Firecracker expects two uncompressed primitives directly exposed to its API: an uncompressed Linux Kernel binary (vmlinux) and a specialized root filesystem image.

Step 3: Download a Pre-compiled Kernel and Minimal Rootfs

For testing and initial setup, AWS provides pre-built, optimized assets. Run the following commands to create a dedicated working directory and acquire the boot files:

mkdir -p ~/firecracker-faas && cd ~/firecracker-faas

# Download an optimized, uncompressed Linux kernel vmlinux binary
curl -L [https://s3.amazonaws.com/spec.ccfc.min/firecracker-ci/vmlinux-5.10.211](https://s3.amazonaws.com/spec.ccfc.min/firecracker-ci/vmlinux-5.10.211) -o vmlinux

# Download a minimalist ext4 root filesystem image containing an Alpine Linux installation
curl -L [https://s3.amazonaws.com/spec.ccfc.min/firecracker-ci/rootfs-alpine-3.19.ext4](https://s3.amazonaws.com/spec.ccfc.min/firecracker-ci/rootfs-alpine-3.19.ext4) -o rootfs.ext4

The root filesystem image serves as the template for your serverless execution environment. In a production FaaS platform, this filesystem would be customized to contain your microservice runtimes (e.g., Node.js, Python, or Go binaries) along with a lightweight API agent designed to listen for incoming code execution payloads.

---

Launching the MicroVM: The API-Driven Approach

Firecracker does not use a configuration file by default; instead, it starts an active process that exposes an internal Unix domain socket. System administrators interact with this socket via RESTful HTTP calls to define the microVM's hardware specifications, kernel parameters, and storage mappings before issuing a final boot command.

Step 4: Start the Firecracker API Server

Open a dedicated terminal window or utilize a terminal multiplexer like tmux to run the Firecracker process, binding it to a local Unix socket file:

rm -f /tmp/firecracker.socket
firecracker --api-sock /tmp/firecracker.socket

Leave this process running. Firecracker is now blocked, waiting for configuration payloads on the socket.

Step 5: Configure and Boot via curl

Open a secondary terminal window to issue configuration directives using curl across the Unix socket.

First, configure the guest operating system's boot source, linking the vmlinux kernel and defining essential console boot arguments:

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

Next, bind the downloaded Alpine Linux filesystem image as the primary read-only block device (root partition):

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

Optionally, define specific resource limitations to enforce strict density on your FaaS host. In this instance, we will allocate 1 vCPU and 128 MB of RAM:

curl --unix-socket /tmp/firecracker.socket -X PUT \
  'http://localhost/machine-config' \
  -H 'Accept: application/json' \
  -H 'Content-Type: application/json' \
  -d '{
    "vcpu_count": 1,
    "mem_size_mib": 128
  }'

With all infrastructure parameters specified, execute the activation command to boot the MicroVM instantly:

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

If you observe your primary terminal window running the Firecracker process, you will immediately see standard Linux kernel boot logs scroll past, terminating in an active Alpine Linux shell prompt in a fraction of a second. Login credentials for this default testing image are root / root.

---

Architecting the FaaS Wrapper: From MicroVM to Serverless

Successfully booting a single MicroVM is a vital milestone, but transforming this capability into a functioning cloud functions platform requires an orchestration layer. To scale this setup into a production-grade FaaS, your control plane should execute the following operations programmatically:

API Gateway/Ingress: A high-performance reverse proxy (such as Nginx or a custom Go-based HTTP listener) accepts incoming webhooks or REST calls targeting specific serverless endpoints.
Dynamic Asset Cloning: To handle concurrent executions cleanly without corruption, the orchestrator copies the master rootfs.ext4 template into a temporary file whenever a function is called, preventing state contamination between invocations.
MicroVM Pool Management: The control plane maintains a 'warm pool' of pre-booted MicroVMs to entirely negate cold starts, routing incoming payloads to active instances via localized internal virtual network taps (TUN/TAP devices).
Teardown & Cleanup: Once the execution lifecycle terminates or times out, the controller forcefully terminates the Firecracker PID, completely purges the transient block file, and reclaims host memory resource bounds instantly.

---

Conclusion and Strategic Next Steps

By leveraging AWS Firecracker on an affordable Ubuntu VPS, you bypass the pricing structures and constraints of commercial cloud vendors, paving the way for a highly secure, scalable, and fully custom FaaS infrastructure. The low overhead and extreme performance of MicroVMs allow standard virtual servers to dense-host hundreds of isolated function runtimes efficiently.

To progress this project into production, your engineering focus should shift toward building a robust orchestration daemon. Explore automating network virtualization via iptables and TAP interfaces to provide secure internet access to your isolated functions, and investigate jailer binaries included with Firecracker to further sandbox the processes beneath unprivileged system users.