Optimizing Cloud Browsers: Running Firecracker VMs on EC2 for Sub-Second Starts

Engineering Blog | June 15, 2026

We have successfully overhauled the Browser Use Cloud infrastructure to achieve a massive leap in efficiency. By rethinking our virtualization strategy, we've managed to slash the cost of browser sessions from ~~ $0.06~~ to **$ 0.02 per hour**, all while ensuring that new browser instances spin up in under one second.

The Core Challenge

Our cloud browser infrastructure must balance three competing priorities:

Rapid Initialization: Browsers must start almost instantly.
Strict Isolation: Each session must be completely walled off.
Cost Efficiency: The overhead must be minimal to keep pricing low.

A browser is more than just a window; it's a complex bundle of Chromium, a filesystem, cache, cookies, proxy configurations, and potentially sensitive user session data.

"If one browser can access the state of another, we have a critical security failure."

To prevent this, we use Virtual Machines (VMs). A VM acts as a "computer within a computer," providing dedicated CPU, memory, disk, and network resources. This ensures that if a browser crashes or is compromised, the blast radius is limited to that specific VM. However, traditional VMs are often too slow and expensive to deploy thousands of times per minute.

The Evolution: Why We Moved Away from Unikernels

Previously, we relied on Unikraft to deploy unikernels—minimalist, specialized VM-like containers that boot only the necessary components for a specific task.

Unikraft vs. Firecracker

Feature	Unikraft (Unikernels)	Firecracker (MicroVMs)
Boot Speed	Very Fast	Extremely Fast (with snapshots)
Idle Cost	Low	Low
Autoscaling	$\text{Manual/Poor}$	$\text{Dynamic/High}$
Stability	Prone to lag during spikes	Highly scalable

While unikernels were efficient when idle, they failed us during traffic surges. Because Unikraft lacked robust built-in autoscaling, our engineers had to manually adjust variables to increase capacity.

The result? During one specific load test, the system couldn't keep up with the spike, leading to a 45-minute production outage. We realized we needed a system that could scale autonomously.

Enter Firecracker: Orchestrating MicroVMs

We transitioned to Firecracker, a virtualization technology that allows us to create and monitor isolated VMs with minimal overhead. However, Firecracker itself is just the engine; we still needed a "brain" to manage the fleet.

The Control Plane

To solve the scaling issue, we built a custom control plane. Unlike AWS CloudWatch, which often operates on one-minute intervals (too slow for our needs), our control plane provides real-time orchestration:

Placement: It identifies which EC2 host has available capacity.
Traffic Management: It stops routing new sessions to hosts marked for removal.
State Awareness: It tracks browsers currently in the "starting" phase and avoids overloading struggling machines.

The Architecture: Nested Virtualization

Typically, Firecracker is deployed on .metal instances (bare-metal servers). However, we chose to run it on standard EC2 instances. This means we are running VMs inside of VMs (Nested Virtualization).

Why make this trade-off?

Speed of Provisioning: Standard EC2 instances are faster to launch.
Cost: They are significantly cheaper than bare-metal.
Agility: Our hosts boot from a pre-built image and are ready to serve browsers in $\approx 30$ seconds.

The downside is a slight increase in latency. When a browser VM triggers a page fault, the request must pass through two hypervisor layers: $\text{Browser VM} \rightarrow \text{AWS Hypervisor} \rightarrow \text{Physical Hardware}$

Despite this, the cost savings and scaling speed make this the superior choice for our use case.

The Lifecycle of a Browser Session

When a user initiates a session, the following sequence occurs in less than a second:

Host Selection: The control plane assigns the request to an EC2 host.
Snapshot Restore: The host restores a pre-saved VM snapshot (avoiding a full boot).
Chromium Launch: The browser starts within the restored VM.
Ready State: The system waits for Chromium to signal it is ready.
Connection: A URL is returned to the user.

The actual interaction happens via the Chrome DevTools Protocol (CDP) over a WebSocket.

CDP acts as the remote-control API, allowing us to execute commands such as:

click_element()
type_text()
capture_screenshot()
read_page_content()

Summary of Improvements

By combining a custom control plane, Firecracker snapshots, and strategic nested virtualization on EC2, we've achieved a lean, mean, browsing machine.

# Conceptual logic of the new flow
def start_browser_session(user_id):
    host = control_plane.get_optimal_host()
    vm = host.restore_snapshot("chromium_base")
    browser = vm.launch_chromium()
    
    if browser.is_ready():
        return browser.get_cdp_url()