Browser Use: Running Firecracker microVMs on EC2 for High-Performance Cloud Browsers

Browser Use has rebuilt its cloud browser infrastructure to achieve a session start time of under one second and a cost reduction from $0.06 to $0.02 per browser hour. This was accomplished by deploying Firecracker microVMs on standard Amazon EC2 instances, utilizing nested virtualization to balance isolation, speed, and cost.

Solving the Cloud Browser Trilemma

Cloud browsers must simultaneously satisfy three competing requirements: fast startup times, strong security isolation, and low operational cost. While standard virtual machines (VMs) provide the necessary isolation to prevent cross-session data leaks, they are typically too heavy and slow to spawn thousands of instances rapidly.

Browser Use transitioned from Unikraft unikernels to Firecracker microVMs to better handle rapid scaling. While unikernels provided fast boot times, the team found that the orchestration layer required for horizontal scaling of the underlying EC2 infrastructure was a bottleneck. By moving to Firecracker, they were able to build a custom control plane that monitors the fleet in real-time and manages VM placement and scaling more efficiently than generic tools like AWS CloudWatch.

Implementing Nested Virtualization on EC2

Traditionally, Firecracker is deployed on bare-metal (.metal) instances to avoid the overhead of a hypervisor. However, Browser Use opted for regular EC2 instances because they are cheaper and boot faster (approximately 30 seconds), allowing the system to maintain less idle capacity.

This approach results in nested virtualization, where the browser VM runs inside an AWS-managed VM. To mitigate the resulting latency—specifically during page faults where requests must cross two VM layers—the team implemented several technical optimizations:

Memory Optimization via Hugepages and userfaultfd

Initial cold starts took 9.8 seconds, with page faults accounting for 72% of VM exits. The team reduced this to 3.1 seconds by implementing two primary changes:

  1. 2MB Hugepages: Switching from 4KB pages to 2MB pages reduced the frequency of page faults by mapping memory in larger chunks.
  2. Custom userfaultfd Handler: Using the Linux userfaultfd API, the system now pre-loads memory pages that Chromium is most likely to access first, preventing a flood of page faults during startup.

Additional refinements included disabling a 500ms check for a non-existent PS/2 keyboard and replacing HTTP polling for browser readiness with a fast vsock communication channel.

CPU Scheduling and Pinning

Chromium exhibits a massive CPU burst during startup (creating renderers and V8 isolates) followed by a period of relative inactivity. To handle this, Browser Use employs a two-phase CPU strategy:

  • Launch Phase: vCPUs remain unpinned, allowing Linux to spread the startup burst across all available host cores.
  • Ready Phase: Once the browser is ready, vCPUs are pinned to specific physical cores to ensure stable placement and higher density without interference.

To prevent contention, each browser is assigned both sibling threads of a physical core, and vCPU threads are given real-time priority to eliminate session loss during high-load stress tests.

Achieving Stealth in Headless Environments

Standard headless Chromium is easily detected by anti-bot measures, with a block-avoidance rate of only 2%. To avoid the cost of running headful browsers (which require GPUs and display servers), Browser Use developed a high-stealth headless solution:

  • Low-Level Chromium Fork: Instead of using JavaScript injection to hide automation flags (like navigator.webdriver), they patched Chromium at the source level to make the automation invisible to websites.
  • Fingerprint Rotation: The system utilizes tens of thousands of real fingerprints across macOS, Windows, and Linux to mimic genuine user environments.

This approach resulted in an 81% block-avoidance rate on their internal stealth benchmark and 84.8% on Halluminate BrowserBench.

Performance Results and Future Roadmap

In a 10,000-session stress test, the system achieved a VM cold start of under 400ms. End-to-end browser creation latency (p50) was 825ms, with a p99 of 1.35s.

Current Bottlenecks and Next Steps

The primary remaining latency source is the Chromium startup process itself, which takes approximately 545ms (p50). Currently, the system snapshots the VM just before Chromium starts. The team is working on snapshotting the VM after Chromium is already running. This will require managing open devices, timers, and network state to ensure that restored browsers remain isolated and unique, but it would effectively eliminate the Chromium launch time from the session startup sequence.

Sources