- Browser Use Cloud utilise une VM Firecracker dédiée par session de navigateur, tout en faisant passer le temps de démarrage d’une nouvelle session sous la seconde et en réduisant le coût de 0,06 $ à 0,02 $ par heure de navigateur
- L’ancienne architecture basée sur Unikraft était avantageuse sur le coût à vide, mais elle nécessitait une intervention humaine pour ajuster la capacité lors des pics de trafic, et un test de charge a provoqué une interruption de production de 45 minutes
- La nouvelle architecture s’appuie sur son propre control plane, qui surveille la flotte de navigateurs en temps réel pour décider du placement, du scaling et du drainage des hôtes EC2 de façon plus fine que CloudWatch
- Plutôt que d’utiliser des instances
.metal, l’équipe a choisi la virtualisation imbriquée en faisant tourner Firecracker sur des EC2 classiques, puis a réduit les goulots d’étranglement avec des pages mémoire de 2 Mo,userfaultfd, l’affinité des vCPU, une priorité temps réel et des patchs sur Chromium headless - Le cold start de la VM est inférieur à 400 ms et, lors d’un stress test de 10 000 sessions, la latence de création de navigateur mesurée via l’API publique a atteint p50 825 ms et p99 1,35 s, avec un démarrage réussi pour tous les navigateurs
Des navigateurs cloud rapides, isolés et peu coûteux
- L’objectif de Browser Use Cloud est de démarrer les navigateurs rapidement tout en isolant l’état entre les sessions et en réduisant les coûts
- Une session peut inclure Chromium, le système de fichiers, les cookies, le cache, les paramètres de proxy, les téléchargements et parfois même une session client déjà connectée
- Si un navigateur peut lire l’état d’un autre, cela devient un problème de sécurité, donc chaque session doit être isolée de l’hôte et des autres sessions
- La solution classique consiste à utiliser une VM avec son propre CPU, sa mémoire, son disque et son interface réseau, mais c’est trop lourd et trop coûteux pour un environnement de navigateurs cloud où l’on crée en permanence des sessions avant de les supprimer à leur fin
- La nouvelle architecture exécute toutes les sessions de Browser Use Cloud dans une petite VM Firecracker, elle-même lancée sur Amazon EC2
Pourquoi abandonner Unikraft
- L’ancienne architecture exécutait les navigateurs cloud avec Unikraft
- Unikraft charge un unikernel, c’est-à-dire une petite image conçue pour un usage précis, au lieu de démarrer un Linux complet
- Un unikernel démarre vite et peut s’éteindre quand il n’y a pas d’utilisateurs, ce qui réduit le coût à vide
- Le principal goulot d’étranglement apparaissait lorsqu’il fallait augmenter rapidement la capacité de navigateur pendant les pics de trafic
- Unikraft ne proposait pas de bon autoscaling intégré
- Les ingénieurs devaient modifier des variables et ajouter manuellement des instances
- Un test de charge a provoqué une interruption de production de 45 minutes
- Après la refonte, l’équipe est passée à Firecracker
- Firecracker fournit une couche pour créer, surveiller et exécuter des VM
- Chaque VM reçoit son CPU, sa mémoire, son disque et son interface réseau, avec une isolation par rapport à l’hôte et aux autres VM
Automatiser la montée en charge avec un control plane maison
- Firecracker permet d’attribuer une VM à chaque navigateur, mais ne décide pas automatiquement combien de VM lancer, où les placer ni quand les faire évoluer
- Browser Use a donc construit son propre control plane pour surveiller la flotte de navigateurs et décider des scale up/scale down
- Lorsqu’un utilisateur demande un navigateur, le control plane choisit une machine disposant encore de capacité libre
- Si le trafic augmente, il démarre davantage de machines ; s’il baisse, il cesse d’envoyer de nouveaux navigateurs vers les machines en cours de retrait
- Le control plane observe la flotte en temps réel
- CloudWatch, le service de monitoring d’AWS, réagit généralement sur des fenêtres d’une minute
- Le control plane connaît aussi des informations absentes des métriques classiques, comme les navigateurs encore en cours de démarrage, les machines en phase de retrait ou celles qui ne doivent plus recevoir de nouvelles sessions
- Les requêtes utilisateur transitent par un edge router stateless jusqu’au control plane, qui sélectionne ensuite l’hôte EC2 approprié
Pourquoi exécuter Firecracker sur des EC2 classiques
- Sur AWS, la manière habituelle d’exécuter Firecracker consiste à utiliser des instances
.metal- Avec
.metal, on loue un serveur physique entier sur lequel Firecracker s’exécute directement
- Avec
- Browser Use a choisi des EC2 classiques
- Ces machines sont disponibles plus rapidement
- Leur coût d’exploitation est plus faible
- Les hôtes démarrent à partir d’une image préconstruite et peuvent fournir des navigateurs environ 30 secondes après leur lancement
- Pouvoir ajouter des hôtes plus vite réduit la capacité idle à financer et donc le coût répercuté aux clients
- Le compromis, c’est une architecture VM dans une VM
- Une EC2 classique fonctionne déjà à l’intérieur de la couche d’isolation d’AWS
- Les VM de navigateur s’exécutent ensuite à l’intérieur de cette première VM
- Quand une VM de navigateur demande de l’aide à l’hôte, la requête doit traverser deux couches de VM, ce qui ajoute de la latence
- Browser Use a accepté ce compromis afin de bénéficier d’un scale-up plus rapide et de coûts plus faibles, puis s’est concentré sur l’optimisation du chemin d’exécution de Firecracker
Du clic utilisateur au navigateur disponible
- Quand un utilisateur demande un navigateur, le control plane choisit une machine qui a de la capacité libre
- Cette machine restaure une VM de navigateur sauvegardée, puis lance Chromium à l’intérieur
- Dès que Chromium devient contrôlable, elle renvoie une URL de connexion
- L’agent de l’utilisateur se connecte à cette URL
- Browser Use pilote Chromium via le Chrome DevTools Protocol (CDP) au-dessus de WebSocket
- Le CDP est l’API de contrôle distant de Chrome pour cliquer sur des boutons, saisir du texte, lire des pages ou prendre des captures d’écran
- Trois principaux goulots d’étranglement expliquaient la latence
- La restauration de la mémoire de la VM
- Le démarrage de Chromium
- Le maintien du stealth face aux protections anti-bot
Premier goulot d’étranglement : la restauration mémoire
- En production, les navigateurs ne démarrent pas depuis zéro : ils reprennent depuis un snapshot
- Le snapshot correspond à une VM déjà démarrée et mise en pause juste avant le lancement de Chromium
- La reprise de VM est plus rapide qu’un boot complet, mais lors du cold start initial, les page faults représentaient 72 % de l’ensemble des VM exits
- Au départ, le temps entre la reprise de la VM et un navigateur prêt pour CDP était de 9,8 secondes
- La raison de cette lenteur est que, quand la VM restaurée touche la mémoire pour la première fois, l’hôte doit remapper cette mémoire
- Cet événement correspond à un page fault
- Dans une VM imbriquée, le page fault peut traverser les deux couches de VM, ce qui le rend coûteux
- La solution a consisté à mapper la mémoire par blocs plus grands
- Auparavant, la restauration se faisait avec des pages de 4 Ko
- Désormais, elle utilise des pages de 2 Mo
- Chaque page couvre 512 fois plus de mémoire, ce qui réduit fortement les page faults pendant le réveil du navigateur
- L’équipe a aussi ajouté un handler personnalisé pour
userfaultfd, l’API Linux de gestion des pages mémoire manquantes- Il charge avant l’exécution de la VM les zones de mémoire auxquelles Chromium a le plus de chances d’accéder en premier
- Cela évite une avalanche de page faults au démarrage de Chromium
- Grâce à ces changements, le temps entre la reprise de la VM et un navigateur capable d’accepter des commandes est passé de 9,8 secondes à 3,1 secondes
- Le nombre de fois où la VM de navigateur s’arrêtait pour demander à l’hôte de traiter de la mémoire manquante est passé d’environ 100 000 à environ 1 100 par reprise, soit une baisse d’environ 91×
- De petites optimisations se sont aussi accumulées
- Une vérification de 500 ms servant à rechercher un ancien clavier PS/2 inexistant a été désactivée
- La vérification de disponibilité est passée d’un polling HTTP à la lecture de logs via
vsock - Quand le driver du navigateur écrit un message ready dans les logs, l’hôte le lit via
vsocket détecte l’état prêt en moins d’1 ms
Deuxième goulot d’étranglement : le démarrage de Chromium et le placement CPU
- Au lancement de Chromium, la consommation CPU grimpe fortement, car il faut créer en même temps le renderer, le compositor et l’isolate V8
- Après le démarrage, l’automatisation du navigateur est relativement calme
- L’agent clique, attend, lit, puis clique à nouveau
- Le navigateur passe le plus clair de son temps à attendre la page, les réponses réseau ou l’action suivante de l’agent
- Cette caractéristique permet de densifier de nombreux navigateurs sur un même hôte
- Le pic CPU du démarrage est géré en deux étapes
- Tant que le navigateur reprend et que Chromium démarre, les vCPU restent sans affinité fixe
- Linux peut ainsi répartir la charge CPU du navigateur sur l’ensemble de l’hôte au lieu de la lier à un cœur précis
- Une fois que le navigateur signale son état ready, les vCPU sont épinglés sur des cœurs stables
- Si l’affinité est fixée dès le départ, plusieurs navigateurs lancés en parallèle peuvent se concentrer sur le même cœur chaud, ce qui fait échouer certains démarrages
- Le traitement de l’hyperthreading a aussi été ajusté
- Un cœur CPU physique apparaît souvent comme deux CPU logiques, appelés sibling threads
- Si deux VM de navigateur reçoivent chacune un de ces siblings, elles se disputent le même cœur physique
- Dans un environnement imbriqué, cette concurrence peut se traduire par des échecs au lancement
- Désormais, chaque navigateur reçoit les deux sibling threads du cœur physique qu’il utilise
- Chaque thread vCPU épinglé reçoit une priorité temps réel
- Linux exécute ainsi les VM immédiatement au lieu de les laisser attendre derrière des tâches moins importantes
- Avant ce changement, dans un test à 1 000 navigateurs, 17 % des sessions étaient perdues juste après leur création
- Après le changement, la perte est tombée à 0 dans le même test
Des navigateurs stealth sans écran
- Un navigateur headless s’exécute sans fenêtre visible, tandis qu’un navigateur headful fonctionne avec une fenêtre, des graphismes et des frames de rendu comme sur un ordinateur portable
- Un Chromium headless standard est facile à détecter sur les sites qui utilisent des protections anti-bot
- D’après le stealth benchmark de Browser Use, un Chromium headless standard n’évitait le blocage que dans 2 % des cas
- En exécutant le même Chromium en mode headful avec une fenêtre visible, le seul rendu faisait monter le taux d’évitement du blocage à 50 %
- C’est pour cette raison que de nombreux fournisseurs exécutent des navigateurs headful, en supportant les coûts d’un display server, du GPU et du compositor, même si personne ne regarde l’écran
- Browser Use a préféré modifier le navigateur lui-même afin de conserver une exécution entièrement headless
- Le premier composant est un fork de Chromium
- De nombreux outils stealth injectent du JavaScript dans chaque page après le démarrage du navigateur pour masquer l’automatisation
- Par exemple, ils écrasent la valeur de
navigator.webdriverpour qu’un site voiefalseau lieu detrue - Les sites peuvent détecter que ce type de valeur a été surchargé
- Browser Use patche des couches plus basses de Chromium afin que ces valeurs ne soient pas exposées dès le départ
- Le second composant est le fingerprinting
- Le fingerprint d’un navigateur est la combinaison des informations sur le navigateur et la machine qu’un site peut lire
- Il inclut des centaines de détails comme le système d’exploitation, la taille d’écran, les polices, la sortie graphique, l’audio, le fuseau horaire ou la langue
- Browser Use utilise des dizaines de milliers de fingerprints réels provenant de macOS, Windows et Linux
- Ces navigateurs ont atteint 81 % d’évitement du blocage dans le stealth benchmark et 84,8 % dans Halluminate BrowserBench
- Comme ils n’ont pas d’affichage, leur coût d’exécution est plus faible et leur montée en charge plus simple
Se connecter au bon navigateur
- Une fois le navigateur prêt, l’utilisateur se connecte via CDP
- L’URL publique est une URL WebSocket
- Devant la flotte de navigateurs se trouvent de simples edge routers
- Le routeur reçoit la connexion WebSocket, demande au control plane où se trouve le navigateur concerné, puis transmet les octets CDP bruts à la bonne VM
- Le routeur ne décide pas où le navigateur sera exécuté
- Si un routeur tombe, un autre peut prendre en charge les nouvelles connexions
- Le placement relève du control plane, le routeur ne fait que transporter les octets
Résultats et prochaines étapes
- Aujourd’hui, chaque session de navigateur reprend depuis un petit snapshot de VM exécuté à l’intérieur d’une EC2 classique, puis lance Chromium headless à l’intérieur
- Le cold start de la VM est inférieur à 400 ms
- La latence de création de navigateur mesurée via l’API publique est de p50 825 ms et p99 1,35 s
- Ces chiffres ont été mesurés lors d’un stress test de 10 000 sessions au cours duquel tous les navigateurs ont démarré avec succès
- Le leaderboard indépendant de BrowserArena classe Browser Use premier avec 0,02 $/h et 100 % de fiabilité
- Dans cette infrastructure, le principal coût restant est désormais Chromium lui-même
- Après la reprise, le démarrage de Chromium prend encore environ 545 ms au p50
- Les snapshots actuels sont créés juste avant le démarrage de Chromium
- Tous les navigateurs se réveillent donc depuis le même point propre, puis lancent chacun leur propre Chromium
- L’étape suivante consiste à créer le snapshot une fois Chromium déjà lancé
- Une nouvelle session pourrait ainsi se réveiller avec un navigateur déjà vivant, sans avoir à le démarrer
- C’est une tâche complexe
- Un navigateur en cours d’exécution possède des périphériques ouverts, des timers, un état graphique, un état réseau et un état de fingerprint
- Il faut rendre ces états sûrs avant le gel
- Après la restauration, chaque navigateur doit apparaître comme son propre navigateur, et non comme le clone d’un navigateur précédent
- Browser Use Cloud est disponible dès maintenant sur cloud.browser-use.com
1 commentaires
Réactions sur Hacker News
Mettre en avant le contournement des anti-bots comme benchmark semble assez contraire à l’éthique. Le but des anti-bots est de bloquer les bots indésirables, et ce genre de service finit surtout par rendre le web plus hostile aux humains et plus coûteux
Les sites vont continuer à tenter de bloquer les accès automatisés, et les barrières d’accès au contenu vont encore augmenter. La montée des exigences de vérification d’identité sur le web semble aussi être un effet de second ordre qui ne relève pas seulement des restrictions d’âge ou de la « protection des enfants », mais aussi de la défense contre les bots et de la protection des revenus publicitaires
Sur les sites sans API, j’utilise aussi des scrapers, et j’indexe l’ensemble de mon historique d’achats dans une base de données afin de pouvoir l’analyser. Je n’ai pas envie de passer encore plus de temps à contourner une détection de bots stupide, et s’il s’agit de données auxquelles on ne peut pas accéder autrement, je suis tout à fait prêt à payer. De toute façon, c’est brûler des ressources dans un jeu du chat et de la souris que les scrapers finiront forcément par gagner
En revanche, proposer des proxys résidentiels est probablement non éthique. Les fournisseurs de connexions résidentielles qui servent à ces proxys ignorent souvent qu’ils ont été intégrés à ce type de service
Si je ne peux pas rester assis 24 h/24 devant mon ordinateur pour essayer d’obtenir des billets de concert, il est difficile de voir comme non éthique le fait d’utiliser un bot personnel pour acheter des places d’un groupe que j’aime. En revanche, si c’est pour faire du marché noir, je suis d’accord pour dire que c’est non éthique. L’anti-anti-bot sert à rendre possible ce que d’autres estiment ne pas devoir être automatisé, et j’imagine qu’un bon nombre de lecteurs de Hacker News ont déjà fait ce genre de chose au moins une fois. Si c’est uniquement pour le profit, ce n’est pas terrible, mais si c’est pour avoir une chance face aux revendeurs, cela me paraît acceptable
Comme elles ne sont qu’un locataire SaaS parmi d’autres, et pas un client assez important pour exiger la suppression du CAPTCHA, elles contournent simplement cette contrainte
Ce qui manque ici, c’est que la virtualisation imbriquée sur des instances EC2 ordinaires est possible depuis février de cette année. Avant cela, il fallait utiliser des instances EC2 metal pour exécuter des VM Firecracker
Je suis un peu surpris qu’ils aient quand même persisté avec Chromium à ce niveau
Notre serveur MCP web-access[0] lance les instances de navigateur comme sous-processus avec une configuration bien plus simple, et la plus grosse amélioration en stabilité, CPU et consommation mémoire est arrivée quand nous sommes passés de Chrome à Lightpanda[1]. Comme le dit la fin de l’article, un navigateur qui démarre plus vite est peut-être simplement un navigateur qui alloue moins de mémoire dès le départ
[0]: https://github.com/EratoLab/web-access-mcp
[1]: https://lightpanda.io
Les navigateurs comme LightPanda n’ont aucun stealth et sont très faciles à détecter. Il y a aussi moyen d’accélérer Chromium en retirant ce qui n’est pas nécessaire. Sans avoir à reconstruire tout un moteur depuis zéro, je pense que Chromium peut atteindre ce niveau de performance sans perdre le stealth, qui est la priorité absolue. Le langage n’est pas le problème, et le C++ est aussi performant que Zig, mais je suis d’accord sur le fait que l’embonpoint de Chromium est réel
J’exploite une API de capture d’écran appelée ApiFlash, et au lieu de Firecracker sur EC2, nous packagons Chromium dans une image de conteneur AWS Lambda
AWS Lambda fournit gratuitement l’isolation et l’auto-scaling, ce qui en fait une solution idéale pour des tâches sans état avec des pics de charge, comme les captures d’écran. À mon avis, on obtient pratiquement les mêmes avantages que la solution browser-use, avec une architecture beaucoup plus simple. Le compromis, c’est le cold start d’AWS Lambda, mais en pratique les fonctions chaudes sont réutilisées lors d’appels rapprochés. Avec un volume d’appels suffisant, les pics s’atténuent et les cold starts ne se produisent pas si souvent
Les problèmes que nous avons rencontrés avec Lambda étaient la limite d’exécution de 15 minutes, le prix, l’absence de mécanisme de snapshot et le manque de contrôle bas niveau sur l’hôte d’exécution. Nous prenons en charge jusqu’à 4 heures et pouvons aller au-delà si nécessaire. Cela dit, pour la plupart des cas d’usage classiques d’automatisation web, Lambda est largement suffisant
Ils disent « ensuite : éviter le démarrage de Chromium », mais je me demande s’il ne suffirait pas de maintenir un warm pool de navigateurs déjà lancés et de les affecter aux requêtes entrantes
Du point de vue de l’utilisateur, la latence serait quasiment nulle. Il faudrait sans doute une logique de prédiction pour agrandir ou réduire le warm pool selon les schémas de trafic, mais cela semble être la solution la plus simple
Un warm pool, c’est bien, mais cela consomme quand même des ressources, et il faut continuer à lancer des navigateurs pour maintenir le pool chaud et l’équilibrer. Avec les changements à venir, nous comptons conserver le démarrage de Chromium tout en rendant la VM prête en moins de 50 ms, afin de battre complètement le warm pool. Certains clients ont besoin de paramètres et de fonctionnalités spécifiques, ce qui accroît la complexité du warm pool. Le chemin général serait rapide, mais les cas d’exception pourraient devenir très lents ; nous voulons garantir de bonnes performances quelle que soit la fonctionnalité requise par le navigateur demandé
Firecracker est une technologie formidable. Nous l’utilisons dans une startup d’entretiens techniques pour exécuter des runtimes isolés pour les entretiens de code et les espaces de travail personnels, et c’est très stable tout en étant étonnamment léger
L’intégration avec le SDK Go a aussi été très simple
C’est sympa de voir userfaultfd davantage utilisé. C’est une API vraiment puissante, car elle permet de contrôler complètement comment et depuis où charger la mémoire lorsqu’un page fault se produit
Je comprends bien qu’un EC2 standard est déjà une VM, mais il me semble que certains EC2 permettent l’accès à l’hyperviseur, ce qui rend aussi Firecracker possible. Corrigez-moi si je me trompe
[1] https://aws.amazon.com/about-aws/whats-new/2026/02/amazon-ec...
Je me demande pourquoi Firecracker est nécessaire. Pourquoi ne pas simplement exécuter cela directement dans un conteneur ? Je comprends les préoccupations d’isolation, mais la combinaison navigateur + container escape, ce n’est pas une CVE à un milliard de dollars ?
Les conteneurs offrent une surface d’attaque bien plus large que les VM et, comme ils ne sont pas considérés comme sûrs selon les standards de l’industrie, il est probable que moins de ressources soient consacrées à la gestion des CVE de container escape qu’aux évasions de VM
Pour faire ça sur une instance autre que
.metal, il ne faut pas un patch noyau ? Il me semble qu’il faut le patch PVM