Firecracker VMs in EC2: Browser-Use baut Cloud-Browser für unter 1 Sekunde Startzeit

Browser-Sessions müssen drei Dinge gleichzeitig sein: schnell starten, isoliert bleiben, und billig sein. Browser-Use hat seine Cloud-Infrastruktur neu aufgebaut - mit Firecracker-MicroVMs auf regulärem EC2. Das Ergebnis: $0.02 pro Browser-Stunde (down from $0.06) und unter 400ms VM-Cold-Start.

Warum normale VMs zu schwer sind

Ein Browser bringt Chromium, Filesystem, Cookies, Cache, Proxy-Settings, Downloads und manchmal eine eingeloggte Kundensession mit. Wenn ein Browser den Zustand eines anderen lesen kann, hast du ein Sicherheitsproblem.

Die normale Antwort wäre eine VM - ein Computer im Computer mit eigenem CPU, Memory, Disk, Network. Aber normale VMs sind zu schwer für Cloud-Browser, die du konstant erzeugst und sofort wieder wegwirfst.

VMs in VMs: Der ungewöhnliche Ansatz

Firecracker wird normalerweise auf Bare-Metal-Servern betrieben. Browser-Use betreibt es auf regulärem EC2 - also verschachtelte Virtualisierung. Das sollte langsam sein, ist aber durch Optimierungen schneller als erwartet.

Die Vorteile:

• Schnellere Scale-Up (Hosts booten in ~30 Sekunden)
• Günstiger (kein Dedicate-Metal nötig)
• Weniger Idle-Kapazität nötig

Die Optimierungen im Detail

Memory: 2MB Pages statt 4KB

Beim Restore aus einem Snapshot triggert der Browser Page Faults. In einer verschachtelten VM ist jeder Page Fault teuer, weil er beide VM-Layer durchquert.

Die Lösung: Memory in 2MB Pages statt 4KB mappen. Jede Page deckt 512x mehr Memory ab, also 91x weniger Page Faults. Die Startup-Zeit fiel von 9.8s auf 3.1s.

CPU: Unpinned während Launch, Pinned danach

Chromium braucht beim Start viel CPU, danach ist es ruhig. Die Lösung:

• Während Launch: vCPUs unpinned lassen, Linux kann die Arbeit verteilen
• Nach Ready: vCPUs auf stabile Cores pinnen
• Hyperthreads vermeiden: Jeder Browser bekommt beide Sibling-Threads eines Cores

Stealth ohne Display

Headless Chromium ist leicht zu erkennen (nur 2% Block-Vermeidung). Headful braucht GPU und Display-Server (teuer).

Browser-Use hat Chromium selbst gepatcht:

• Patches auf der niedrigsten Ebene (nie exposed)
• Tausende echte Fingerprints über macOS, Windows, Linux
• Ergebnis: 81% Block-Vermeidung bei vollständig headless

Die Ergebnisse

• VM Cold Start: <400ms
• API End-to-End: 825ms p50, 1.35s p99
• 10.000 Browser Stress-Test: 100% Erfolgsrate
• BrowserArena Ranking: #1 mit 100% Reliability bei $0.02/hr

Der nächste Schritt: Chromium überspringen

Der größte verbleibende Kostenfaktor ist der Chromium-Start nach dem VM-Resume (~545ms p50).

Der Plan: Snapshots nach dem Chromium-Start nehmen. Die VM wacht mit bereits laufendem Browser auf. Das ist komplex (Devices, Timer, Graphics State, Network State müssen sauber sein), aber der nächste Meilenstein auf der Roadmap.

Der vollständige technische Deep-Dive steht auf Browser-Use Blog.