- Browser Use Cloud nutzt für jede Browser-Session eine eigene Firecracker-VM, senkt damit die Startzeit neuer Sessions auf unter 1 Sekunde und reduziert die Kosten von $0.06 pro Browser-Stunde auf $0.02
- Die frühere Unikraft-Architektur war bei Leerlaufkosten vorteilhaft, erforderte bei Traffic-Spitzen aber manuelle Kapazitätsanpassungen, wodurch die Produktion während eines Lasttests 45 Minuten lang ausfiel
- Die neue Architektur verwendet eine eigene Control Plane, die die Browser-Flotte in Echtzeit überwacht und Platzierung, Skalierung und Draining von EC2-Hosts feiner steuert als CloudWatch
- Statt Firecracker auf
.metalauszuführen, entschied man sich für Nested Virtualization auf normalem EC2 und reduzierte Engpässe mit 2-MB-Speicherseiten,userfaultfd, vCPU-Pinning, Real-Time-Priority und Patches für headless Chromium - Der Cold Start der VM liegt bei unter 400 ms; in einem Stresstest mit 10.000 Sessions betrug die Browser-Erzeugungslatenz über die öffentliche API p50 825 ms und p99 1,35 s, wobei alle Browser erfolgreich gestartet wurden
Schnelle, isolierte und günstige Cloud-Browser
- Browser Use Cloud will Browser schnell starten, den Zustand zwischen Sessions isolieren und die Kosten niedrig halten
- Eine einzelne Session umfasst Chromium, Dateisystem, Cookies, Cache, Proxy-Einstellungen, Downloads und manchmal sogar eingeloggte Kundensessions
- Wenn ein Browser den Zustand eines anderen lesen könnte, wäre das ein Sicherheitsproblem; deshalb muss jede Session vom Host und von anderen Sessions getrennt werden
- Die übliche Lösung sind VMs mit eigener CPU, eigenem Speicher, eigener Festplatte und eigenen Netzwerkgeräten, doch für Cloud-Browser, die fortlaufend erzeugt und nach Session-Ende wieder verworfen werden, ist das zu schwergewichtig und zu teuer
- Die neue Architektur führt alle Browser-Use-Cloud-Sessions in einer kleinen Firecracker-VM aus, die auf Amazon EC2 läuft
Warum Unikraft aufgegeben wurde
- Die frühere Architektur führte die Cloud-Browser mit Unikraft aus
- Unikraft lädt ein Unikernel, also ein kleines, zweckgebautes Image, statt ein vollständiges Linux zu booten
- Unikernel starten schnell und können beendet werden, wenn keine Nutzer da sind, wodurch die Leerlaufkosten niedrig bleiben
- Der Engpass war das schnelle Hochskalieren der Browser-Kapazität bei Traffic-Spitzen
- Unikraft hatte kein gutes eingebautes Autoscaling
- Engineers mussten Variablen ändern und Instanzen manuell hinzufügen
- Ein Lasttest legte die Produktion 45 Minuten lang lahm
- Nach dem Neuaufbau wurde Firecracker verwendet
- Firecracker stellt die Schicht zum Erzeugen, Überwachen und Ausführen von VMs bereit
- Jede VM erhält CPU, Speicher, Festplatte und Netzwerkgeräte und ist vom Host sowie von anderen VMs isoliert
Browser-Skalierung mit einer eigenen Control Plane automatisieren
- Firecracker kann jedem Browser eine VM geben, entscheidet aber nicht automatisch über Anzahl, Platzierung oder den Zeitpunkt des Skalierens
- Browser Use baute eine eigene Control Plane, die die Browser-Flotte überwacht und über Scale-up und Scale-down entscheidet
- Fordert ein Nutzer einen Browser an, wählt die Control Plane eine Maschine mit freier Kapazität aus
- Steigt der Traffic, werden weitere Maschinen gestartet; fällt er, werden Maschinen, die entfernt werden sollen, nicht mehr mit neuen Browsern belegt
- Die Control Plane betrachtet die Flotte in Echtzeit
- CloudWatch, der AWS-Monitoring-Dienst, reagiert üblicherweise in 1-Minuten-Fenstern
- Die Control Plane kennt zusätzlich Informationen, die in normalen Metriken nicht auftauchen, etwa Browser, die noch starten, Maschinen im Entfernen oder Maschinen, die keine neuen Sessions mehr annehmen sollen
- Nutzeranfragen werden über einen zustandslosen Edge Router an die Control Plane geleitet, die dann einen EC2-Host mit freier Kapazität auswählt
Warum Firecracker auf normalem EC2 ausgeführt wird
- Die übliche Methode, Firecracker auf AWS zu betreiben, ist die Nutzung von
.metal-Instanzen- Bei
.metalwird ein kompletter physischer Server gemietet, auf dem Firecracker direkt läuft
- Bei
- Browser Use entschied sich für normales EC2
- Normale EC2-Maschinen lassen sich schneller beschaffen
- Die laufenden Kosten sind niedriger
- Hosts booten aus vorbereiteten Images und können etwa 30 Sekunden nach dem Start Browser bereitstellen
- Wenn sich Hosts schneller hinzufügen lassen, sinkt die bezahlte Leerlaufkapazität und damit auch der an Kunden weitergegebene Preis
- Der Preis dafür ist eine VM-in-VM-Struktur
- Normales EC2 läuft selbst bereits innerhalb der AWS-Isolierungsschicht
- Darin werden dann erneut Browser-VMs ausgeführt
- Wenn eine Browser-VM Hilfe vom Host anfordert, muss sie zwei VM-Schichten passieren, was zusätzliche Latenz erzeugt
- Browser Use nahm diesen Kompromiss für schnelleres Scale-up und geringere Kosten in Kauf und konzentrierte sich darauf, den Firecracker-Ausführungspfad zu beschleunigen
Vom Request zum nutzbaren Browser
- Wenn ein Nutzer einen Browser anfordert, wählt die Control Plane eine Maschine mit freier Kapazität aus
- Diese Maschine stellt eine gespeicherte Browser-VM wieder her und startet darin Chromium
- Sobald Chromium steuerbar ist, wird eine Verbindungs-URL zurückgegeben
- Der Agent des Nutzers verbindet sich mit dieser URL
- Browser Use steuert Chromium über das Chrome DevTools Protocol (CDP) per WebSocket
- CDP ist die Remote-Control-API von Chrome für Dinge wie Klicks, Texteingabe, Seitenlesen und Screenshots
- Es gab drei Hauptengpässe bei der Latenz
- Wiederherstellung des VM-Speichers
- Start von Chromium
- Aufrechterhaltung von Stealth, ohne von Anti-Bot-Schutz erkannt zu werden
Erster Engpass: Speicherwiederherstellung
- Produktions-Browser booten nicht von Grund auf neu, sondern werden aus einem Snapshot fortgesetzt
- Der Snapshot ist eine bereits gebootete, gespeicherte VM, die direkt vor dem Start von Chromium angehalten wurde
- Das Fortsetzen einer VM ist schneller als ein neuer Boot, doch beim anfänglichen Cold Start machten Page Faults 72 % aller VM-Exits aus
- Von der VM-Fortsetzung bis zu einem CDP-bereiten Browser dauerte es anfangs 9,8 Sekunden
- Der Grund für die Langsamkeit war, dass der Host den Speicher neu zuordnen musste, wenn die wiederhergestellte VM ihn erstmals berührte
- Dieses Ereignis ist ein Page Fault
- In einer verschachtelten VM-Umgebung kann ein Page Fault durch beide VM-Schichten laufen und ist dadurch teuer
- Die Lösung war, Speicher in größeren Einheiten zu mappen
- Zuvor wurde mit 4-KB-Seiten wiederhergestellt
- Jetzt werden 2-MB-Seiten verwendet
- Jede Seite deckt 512-mal mehr Speicher ab, wodurch die Zahl der Page Faults beim Aufwachen des Browsers stark sinkt
- Zusätzlich wurde ein Custom-Handler für
userfaultfdergänzt, die Linux-API zur Behandlung fehlender Speicherseiten- Vor dem Start der VM lädt er Speicher, auf den Chromium wahrscheinlich zuerst zugreift
- So wird ein Sturm von Page Faults beim Chromium-Start verhindert
- Mit dieser Änderung sank die Zeit von der VM-Fortsetzung bis zu einem browserbereiten Zustand von 9,8 Sekunden auf 3,1 Sekunden
- Die Zahl der Stopps, bei denen die Browser-VM zur Behandlung fehlenden Speichers den Host anfragen musste, sank pro Fortsetzung von etwa 100.000 auf rund 1.100, also um etwa das 91-Fache
- Auch kleine Optimierungen summierten sich
- Eine 500-ms-Prüfung auf eine nicht vorhandene alte PS/2-Tastatur wurde deaktiviert
- Die Readiness-Prüfung wurde von HTTP-Polling auf das Lesen von
vsock-Logs umgestellt - Sobald der Browser-Treiber eine Ready-Meldung ins Log schreibt, liest der Host sie über
vsockund bestätigt den Ready-Zustand in unter 1 ms
Zweiter Engpass: Chromium-Start und CPU-Platzierung
- Beim Start von Chromium ist die CPU-Auslastung hoch, weil gleichzeitig Renderer, Compositor und V8-Isolates erzeugt werden
- Danach ist Browser-Automatisierung vergleichsweise ruhig
- Der Agent klickt, wartet, liest und klickt erneut
- Der Browser wartet meist auf Seiten, Netzwerkantworten oder die nächste Aktion des Agents
- Diese Eigenschaft erlaubt es, viele Browser auf einem Host zu packen
- Die CPU-Bursts zum Startzeitpunkt wurden in zwei Phasen behandelt
- Während der Browser fortgesetzt wird und Chromium startet, bleiben die vCPUs unpinned
- Linux kann die CPU-Arbeit des Browsers dadurch über den gesamten Host verteilen, statt sie an feste Kerne zu binden
- Sobald der Browser seinen Ready-Zustand meldet, werden die vCPUs an stabile Kerne gepinnt
- Würde man von Anfang an pinnen, würden bei gleichzeitigem Start mehrerer Browser einige Starts fehlschlagen, weil sie sich auf denselben Hot Core drängen
- Auch der Umgang mit Hyperthreading wurde angepasst
- Ein physischer CPU-Kern erscheint oft als zwei logische CPUs, sogenannte Sibling Threads
- Wenn zwei Browser-VMs jeweils einen dieser Siblings erhalten, konkurrieren sie um denselben physischen Kern
- In der verschachtelten Umgebung äußerte sich diese Konkurrenz in fehlgeschlagenen Starts
- Aktuell erhält jeder Browser beide Sibling Threads des physischen Kerns, den er nutzt
- Jeder gepinnte vCPU-Thread erhält außerdem Real-Time-Priority
- Dadurch führt Linux die VM sofort aus, statt sie hinter weniger wichtigen Aufgaben warten zu lassen
- Vor dieser Änderung gingen in einem Test mit 1.000 Browsern 17 % der Sessions direkt nach der Erzeugung verloren
- Nach der Änderung lag der Verlust im gleichen Test bei 0
Stealth-Browser ohne sichtbare Oberfläche
- Headless-Browser laufen ohne sichtbares Fenster, während headful Browser wie auf einem Laptop mit Fenster, Grafik und Rendering-Frames ausgeführt werden
- Normales headless Chromium wird von Websites mit Anti-Bot-Maßnahmen leicht erkannt
- Laut dem Stealth-Benchmark von Browser Use lag die Umgehungsrate mit normalem headless Chromium bei nur 2 %
- Wird dasselbe Chromium im sichtbaren headful Modus ausgeführt, steigt die Umgehungsrate allein durch das Rendering auf 50 %
- Viele Anbieter betreiben deshalb headful Browser und zahlen auch dann für Display-Server, GPU und Compositor, wenn niemand den Bildschirm sieht
- Browser Use änderte stattdessen den Browser selbst, um vollständig headless zu bleiben
- Die erste Komponente ist ein Chromium-Fork
- Viele Stealth-Tools injizieren nach dem Browser-Start JavaScript in jede Seite, um Automatisierung zu verbergen
- So wird zum Beispiel der Wert von
navigator.webdriverüberschrieben, damit Websitesfalsestatttruesehen - Websites können erkennen, dass solche Werte überschrieben wurden
- Browser Use patcht niedrigere Ebenen von Chromium, damit diese Werte gar nicht erst sichtbar werden
- Die zweite Komponente ist Fingerprinting
- Ein Browser-Fingerprint ist die Kombination aus Browser- und Maschineninformationen, die eine Website ausliest
- Dazu gehören Hunderte Details wie Betriebssystem, Bildschirmgröße, Fonts, Grafikausgabe, Audio, Zeitzone und Sprache
- Browser Use verwendet Zehntausende reale Fingerprints von macOS, Windows und Linux
- Diese Browser erreichten im Stealth-Benchmark 81 % und in Halluminate BrowserBench 84,8 % Umgehungsrate
- Weil kein sichtbarer Bildschirm nötig ist, sind die Ausführungskosten geringer und die Browser lassen sich leichter skalieren
Verbindung mit dem richtigen Browser
- Sobald ein Browser bereit ist, verbindet sich der Nutzer über CDP
- Die öffentliche URL ist eine WebSocket-URL
- Vor der Browser-Flotte stehen einfache Edge Router
- Ein Router nimmt die WebSocket-Verbindung an, fragt die Control Plane nach dem Standort des betreffenden Browsers und leitet dann rohe CDP-Bytes an die richtige VM weiter
- Der Router entscheidet nicht, wo ein Browser ausgeführt wird
- Fällt ein Router aus, kann ein anderer neue Verbindungen übernehmen
- Die Platzierung übernimmt die Control Plane; der Router leitet nur Bytes weiter
Ergebnisse und nächste Schritte
- Aktuell wird jede Browser-Session aus einem kleinen VM-Snapshot fortgesetzt, der innerhalb von normalem EC2 läuft; darin wird dann headless Chromium gestartet
- Der VM-Cold-Start liegt bei unter 400 ms
- Die Browser-Erzeugungslatenz über die öffentliche API beträgt p50 825 ms und p99 1,35 Sekunden
- Diese Werte wurden in einem Stresstest mit 10.000 Sessions gemessen, bei dem alle Browser erfolgreich starteten
- Das unabhängige Leaderboard von BrowserArena führt Browser Use mit $0.02/hr und 100% reliability auf Platz 1
- Der größte verbleibende Kostenfaktor in dieser Infrastruktur ist Chromium selbst
- Der Chromium-Start nach dem Resume dauert bei p50 noch immer etwa 545 ms
- Der aktuelle Snapshot wird direkt vor dem Start von Chromium erstellt
- Alle Browser wachen an demselben sauberen Punkt auf und starten dann jeweils ihr eigenes Chromium
- Der nächste Schritt ist, den Snapshot erst zu erstellen, nachdem Chromium bereits läuft
- Eine neue Session könnte dann aufwachen, ohne den Browser zu starten, und direkt mit einem bereits lebenden Browser beginnen
- Diese Arbeit ist komplex
- Ein laufender Browser hat offene Geräte, Timer, Grafikzustand, Netzwerkzustand und Fingerprint-Zustand
- Diese Zustände müssen vor dem Freeze sicher gemacht werden
- Nach dem Restore muss jeder Browser wie sein eigener Browser erscheinen und nicht wie eine Kopie des vorherigen
- Browser Use Cloud ist derzeit unter cloud.browser-use.com verfügbar
1 Kommentare
Hacker-News-Kommentare
Anti-Bot-Umgehung als Benchmark anzupreisen, wirkt ziemlich unethisch. Der Zweck von Anti-Bot-Systemen ist es, unerwünschte Bots zu blockieren, und solche Dienste machen das Web letztlich nur menschenfeindlicher und teurer
Websites werden weiterhin versuchen, automatisierte Zugriffe zu blockieren, und die Hürden für den Zugang zu Inhalten werden weiter steigen. Dass im Web immer häufiger Identitätsnachweise verlangt werden, scheint nicht nur an Altersbeschränkungen oder „Kinderschutz“ zu liegen, sondern auch an Bot-Abwehr und dem Schutz von Werbeeinnahmen
Auf Websites ohne API verwende ich auch Scraper, und ich indexiere meine komplette Kaufhistorie in einer Datenbank, damit ich sie analysieren kann. Ich möchte nicht noch mehr Zeit damit verschwenden, dumme Bot-Erkennung zu umgehen, und wenn es Daten sind, an die man anders nicht herankommt, bin ich auch bereit, dafür zu zahlen. Es ist letztlich nur Ressourcenverschwendung in einem Katz-und-Maus-Spiel, das Scraper ohnehin gewinnen werden
Wohnsitz-Proxys anzubieten, ist allerdings wahrscheinlich unethisch. Viele Anbieter solcher privaten Anschlüsse wissen oft gar nicht, dass sie in solche Dienste eingebunden sind
Wenn ich nicht 24 Stunden vor dem Computer sitzen kann, um an Tickets für ein bestimmtes Konzert zu kommen, dann ist es schwer, den Einsatz eines persönlichen Bots zum Kauf von Tickets meiner Lieblingsband als unethisch zu sehen. Wenn es dagegen um Weiterverkauf zu Wucherpreisen geht, stimme ich zu, dass es unethisch ist. Anti-Anti-Bot macht Dinge möglich, die andere nicht automatisiert sehen wollen, und vermutlich haben ziemlich viele Hacker-News-Leser so etwas schon einmal gemacht. Rein profitorientiert ist es fragwürdig, aber um eine Chance gegen Ticket-Scalper zu haben, erscheint es okay
Da man nur einer von vielen SaaS-Tenants ist und kein Kunde mit genügend Gewicht, um die Entfernung des CAPTCHA zu verlangen, umgeht man die Einschränkung einfach
Was hier fehlt: Verschachtelte Virtualisierung auf normalen EC2-Instanzen ist seit Februar dieses Jahres möglich. Davor brauchte man für Firecracker-VMs EC2-Metal-Instanzen
Es überrascht mich etwas, dass man trotz dieses Aufwands immer noch bei Chromium geblieben ist
Unser web-access MCP-Server[0] startet Browser-Instanzen in einer viel einfacheren Konfiguration als Unterprozess, und die größten Verbesserungen bei Stabilität sowie CPU- und Speichernutzung kamen bei uns durch den Wechsel von Chrome zu Lightpanda[1]. Wie am Ende des Artikels gesagt wird, könnte ein Browser, der schneller startet, von vornherein einfach einer sein, der weniger Speicher allokiert
[0]: https://github.com/EratoLab/web-access-mcp
[1]: https://lightpanda.io
Browser wie LightPanda haben überhaupt kein Stealth und sind sehr leicht zu erkennen. Wenn man Unnötiges entfernt, gibt es Wege, auch Chromium schneller zu machen. Ich denke, Chromium kann diese Leistung erreichen, ohne die ganze Engine von Grund auf neu bauen zu müssen, und ohne Stealth zu verlieren, das für uns oberste Priorität hat. Die Sprache ist nicht das Problem, und C++ kann genauso performant sein wie Zig, aber ich stimme zu, dass Chromium sehr aufgebläht ist
Ich betreibe eine Screenshot-API namens ApiFlash und verwende statt Firecracker auf EC2 Chromium, das in ein AWS-Lambda-Container-Image gepackt ist
AWS Lambda bietet Isolation und Auto-Scaling kostenlos und ist deshalb ideal für zustandslose Jobs mit Lastspitzen wie Screenshots. Ich denke, man bekommt fast dieselben Vorteile wie mit browser-use-Lösungen, bei deutlich einfacherer Architektur. Der Trade-off ist der Cold Start von AWS Lambda, aber in der Praxis werden bei aufeinanderfolgenden Aufrufen warme Funktionen wiederverwendet. Bei genügend Aufrufvolumen werden Spitzen geglättet, und Cold Starts treten gar nicht so häufig auf
Unsere Probleme mit Lambda waren das Ausführungszeitlimit von 15 Minuten, der Preis, das Fehlen eines Snapshot-Mechanismus und mangelnde Low-Level-Kontrolle über den Ausführungshost. Wir unterstützen bis zu 4 Stunden und können bei Bedarf noch länger laufen. Für die meisten üblichen Web-Automatisierungsfälle ist Lambda aber mehr als ausreichend
Dort stand „Als Nächstes: Chromium-Start überspringen“, aber könnte man nicht einfach ein Bündel bereits laufender Browser als Warm Pool bereithalten und eingehende Anfragen darauf verteilen?
Aus Nutzersicht wäre die Latenz dann nahezu null. Je nach Traffic-Muster bräuchte man zwar Vorhersagelogik, um den Warm Pool hoch- oder runterzuskalieren, aber das scheint die einfachste Lösung zu sein
Warm Pools sind gut, verbrauchen aber letztlich Ressourcen, und man muss Browser ständig starten, um den Pool warm und im Gleichgewicht zu halten. Mit kommenden Änderungen wollen wir den Chromium-Start beibehalten und gleichzeitig dafür sorgen, dass die VM in unter 50 ms bereit ist, um Warm Pools vollständig zu übertreffen. Manche Kunden brauchen spezielle Parameter und Funktionen, was die Komplexität von Warm Pools erhöht. Der Standardpfad mag schnell sein, aber Ausnahmepfade können sehr langsam werden; wir wollen garantieren, dass es schnell bleibt, egal welche Funktionen der angeforderte Browser benötigt
Firecracker ist großartige Technologie. Wir verwenden es in einem Interview-Startup, das isolierte Laufzeitumgebungen für Coding-Interviews und persönliche Workspaces ausführt, und es ist sehr stabil und erstaunlich leichtgewichtig
Die Integration über das Go-SDK war auch sehr einfach
Schön zu sehen, dass userfaultfd öfter eingesetzt wird. Das ist eine wirklich mächtige API, weil man bei Page Faults vollständig steuern kann, wie und wo Speicher nachgeladen wird
Normales EC2 ist zwar selbst schon eine VM, aber soweit ich weiß gibt es bestimmte EC2-Typen, die Hypervisor-Zugriff bereitstellen und dadurch auch Firecracker ermöglichen. Korrigiert mich, falls das falsch ist
[1] https://aws.amazon.com/about-aws/whats-new/2026/02/amazon-ec...
Ich frage mich, warum Firecracker überhaupt nötig ist. Kann man das nicht einfach direkt in einem Container ausführen? Die Isolationsbedenken verstehe ich, aber die Kombination aus Browser und Container Escape wäre doch ein CVE im Milliarden-Dollar-Bereich, oder?
Container bieten eine deutlich größere Angriffsfläche als VMs, und da sie branchenweit nicht als sicherer Standard gelten, werden wahrscheinlich auch weniger Ressourcen in das Management von Container-Escape-CVEs gesteckt als bei VM-Escapes
Braucht man dafür auf Nicht-
.metal-Instanzen nicht einen Kernel-Patch? Ich glaube, der PVM-Patch ist nötig