Iniciar un navegador en menos de 1 segundo con una VM de Firecracker dentro de EC2
(browser-use.com)- Browser Use Cloud usa una VM individual de Firecracker por sesión de navegador, reduciendo el tiempo de inicio de nuevas sesiones a menos de 1 segundo y bajando el costo de $0.06 por hora de navegador a $0.02
- La arquitectura anterior con Unikraft era buena para los costos en reposo, pero durante picos de tráfico requería que una persona ajustara la capacidad, lo que provocó una caída de producción de 45 minutos durante una prueba de carga
- La nueva arquitectura usa su propio control plane para monitorear en tiempo real la flota de navegadores y decidir con más precisión que CloudWatch la asignación, escalado y drenaje de hosts EC2
- En lugar de usar
.metal, optaron por virtualización anidada ejecutando Firecracker sobre EC2 normal, y redujeron cuellos de botella con páginas de memoria de 2 MB,userfaultfd, fijación de vCPU, prioridad en tiempo real y parches a Chromium headless - El cold start de la VM es de menos de 400 ms, y en una prueba de estrés de 10,000 sesiones la latencia de creación de navegador medida desde la API pública fue p50 de 825 ms y p99 de 1.35 segundos, con todos los navegadores iniciando correctamente
Navegadores en la nube rápidos, aislados y baratos
- El objetivo de Browser Use Cloud es iniciar navegadores rápido, aislar el estado entre sesiones y reducir costos
- Una sesión incluye Chromium, sistema de archivos, cookies, caché, configuración de proxy, descargas y a veces hasta una sesión de cliente ya autenticada
- Si un navegador pudiera leer el estado de otro, sería un problema de seguridad, así que cada sesión debe estar separada del host y de las demás sesiones
- La solución típica es una VM con su propio CPU, memoria, disco y dispositivos de red, pero eso es demasiado pesado y costoso para un entorno de navegadores en la nube donde se crean continuamente y se descartan al terminar la sesión
- La nueva arquitectura ejecuta todas las sesiones de Browser Use Cloud dentro de una pequeña VM de Firecracker, y esas VM corren sobre Amazon EC2
Por qué dejaron Unikraft
- La arquitectura anterior ejecutaba navegadores en la nube con Unikraft
- Unikraft carga un unikernel, una imagen pequeña hecha para un propósito específico, en lugar de arrancar un Linux completo
- Los unikernels arrancan rápido y pueden apagarse cuando no hay usuarios, así que el costo en reposo es bajo
- El cuello de botella era aumentar rápidamente la capacidad de navegadores cuando había picos de tráfico
- Unikraft no tenía un buen autoscaling integrado
- Los ingenieros tenían que cambiar variables y agregar instancias manualmente
- Una prueba de carga dejó producción fuera de servicio durante 45 minutos
- Después de reconstruir la arquitectura, pasaron a usar Firecracker
- Firecracker aporta la capa para crear, monitorear y ejecutar VM
- Proporciona a cada VM CPU, memoria, disco y dispositivos de red, y la aísla del host y de otras VM
Automatizar el escalado de navegadores con su propio control plane
- Firecracker puede dar una VM a cada navegador, pero no decide automáticamente cuántas VM debe haber, cómo distribuirlas ni cuándo escalar
- Browser Use creó su propio control plane para monitorear la flota de navegadores y decidir cuándo escalar hacia arriba o hacia abajo
- Cuando un usuario solicita un navegador, el control plane elige una máquina con capacidad disponible
- Si el tráfico sube, inicia más máquinas; si baja, deja de enviar nuevos navegadores a las máquinas que van a retirarse
- El control plane observa la flota en tiempo real
- CloudWatch, el servicio de monitoreo de AWS, normalmente reacciona en ventanas de 1 minuto
- El control plane conoce información que no aparece en métricas comunes, como navegadores que aún están arrancando, máquinas que se están retirando o máquinas que no deberían recibir nuevas sesiones
- Las solicitudes de usuarios pasan por un edge router stateless hacia el control plane, y este selecciona un host EC2 con capacidad libre
Por qué ejecutaron Firecracker sobre EC2 normal
- La forma habitual de ejecutar Firecracker en AWS es usar instancias
.metal.metalimplica rentar el servidor físico completo para que Firecracker corra directamente ahí
- Browser Use eligió EC2 normal
- Las máquinas EC2 normales se pueden conseguir más rápido
- Tienen menor costo de mantenimiento
- Los hosts arrancan desde una imagen preconstruida y pueden ofrecer navegadores en unos 30 segundos después de iniciarse
- Si pueden agregar hosts más rápido, necesitan menos capacidad ociosa pagada, y eso también reduce el costo trasladado al cliente
- El precio a pagar es una estructura de VM dentro de VM
- EC2 normal ya corre dentro de la capa de aislamiento de AWS
- Encima de eso, vuelven a ejecutar VM para los navegadores
- Cuando una VM de navegador pide ayuda al host, la solicitud debe atravesar dos capas de VM, lo que agrega latencia
- Browser Use aceptó ese trade-off para obtener un scale-up más rápido y menor costo, y se enfocó en acelerar la ruta de ejecución de Firecracker
Flujo desde la solicitud hasta un navegador disponible
- Cuando un usuario solicita un navegador, el control plane elige una máquina con capacidad libre
- Esa máquina restaura una VM de navegador guardada y dentro de ella inicia Chromium
- Cuando Chromium queda en un estado controlable, devuelve una URL de conexión
- El agente del usuario se conecta a esa URL
- Browser Use controla Chromium mediante Chrome DevTools Protocol (CDP) por WebSocket
- CDP es la API de control remoto de Chrome para hacer clic en botones, escribir texto, leer páginas y tomar capturas de pantalla
- Hubo tres cuellos de botella principales que agregaban latencia
- Restauración de la memoria de la VM
- Inicio de Chromium
- Mantener el modo stealth sin ser detectado por sistemas anti-bot
Primer cuello de botella: restauración de memoria
- Los navegadores de producción no arrancan desde cero: se reanudan desde un snapshot
- El snapshot es una VM guardada que ya arrancó y quedó detenida justo antes de iniciar Chromium
- Reanudar la VM es más rápido que hacer un arranque nuevo, pero en el cold start inicial los page faults representaban el 72% de todas las VM exits
- El tiempo desde reanudar la VM hasta tener un navegador listo para CDP era inicialmente de 9.8 segundos
- Era lento porque cuando la VM restaurada tocaba memoria por primera vez, el host tenía que volver a mapear esa memoria
- Ese evento es un page fault
- En una VM anidada, un page fault puede atravesar ambas capas de virtualización y resultar costoso
- La solución fue mapear memoria en unidades más grandes
- Antes restauraban con páginas de 4 KB
- Ahora usan páginas de 2 MB
- Cada página cubre 512 veces más memoria, lo que reduce fuertemente los page faults mientras el navegador “despierta”
- También agregaron un handler personalizado para
userfaultfd, la API de Linux para manejar páginas de memoria faltantes- Carga antes de ejecutar la VM la memoria a la que Chromium probablemente accederá primero
- Así evita una avalancha de page faults durante el arranque de Chromium
- Con este cambio, el tiempo desde reanudar la VM hasta tener un navegador capaz de aceptar comandos bajó de 9.8 segundos a 3.1 segundos
- La cantidad de veces que la VM del navegador se detenía para pedirle al host que resolviera memoria faltante cayó de unas 100,000 veces a unas 1,100 veces por reanudación, una reducción de unas 91 veces
- Las optimizaciones pequeñas también sumaron
- Desactivaron una verificación de 500 ms que buscaba un viejo teclado PS/2 inexistente
- Cambiaron la verificación de readiness de HTTP polling a lectura de logs por
vsock - Cuando el driver del navegador escribe un mensaje de ready en el log, el host lo lee por
vsocky detecta ese estado en menos de 1 ms
Segundo cuello de botella: inicio de Chromium y asignación de CPU
- Al iniciar Chromium, el uso de CPU es alto porque crea al mismo tiempo renderer, compositor y V8 isolate
- Después del arranque, la automatización del navegador es relativamente tranquila
- El agente hace clic, espera, lee y vuelve a hacer clic
- El navegador pasa la mayor parte del tiempo esperando la página, la respuesta de red o la siguiente acción del agente
- Por esa característica, pueden empaquetar muchos navegadores en un mismo host
- El burst de CPU del arranque se maneja en dos etapas
- Mientras el navegador se reanuda y Chromium está arrancando, dejan la vCPU sin fijar
- Linux puede distribuir la carga de CPU del navegador por todo el host en lugar de atarla a núcleos fijos
- Cuando el navegador reporta que ya está ready, fijan la vCPU a núcleos estables
- Si fijaban desde el inicio, varios navegadores arrancando al mismo tiempo se concentraban en el mismo núcleo caliente y algunos lanzamientos fallaban
- También ajustaron el manejo de hyperthreading
- Un núcleo físico de CPU suele aparecer como dos CPU lógicos llamados sibling threads
- Si dos VM de navegador reciben uno de esos siblings cada una, compiten por el mismo núcleo físico
- En un entorno anidado, esa competencia se manifestaba como fallas de lanzamiento
- Ahora cada navegador recibe ambos sibling threads del núcleo físico que usa
- A cada thread de vCPU fijado se le asigna prioridad en tiempo real
- Así Linux ejecuta la VM de inmediato en vez de dejarla esperando detrás de tareas menos importantes
- Antes de este cambio, en una prueba de 1,000 navegadores se perdía el 17% de las sesiones justo después de crearlas
- Después del cambio, la pérdida fue de 0 en la misma prueba
Navegadores stealth sin pantalla
- Un navegador headless corre sin ventana visible, mientras que un navegador headful corre como el de una laptop, con ventana, gráficos y frames de renderizado
- Un Chromium headless común es fácil de detectar en sitios con medidas anti-bot
- Según el stealth benchmark de Browser Use, Chromium headless sin modificar evitaba bloqueos en solo 2% de los casos
- Ejecutar ese mismo Chromium en modo headful con ventana visible elevaba la evasión de bloqueos a 50% solo por el renderizado
- Por eso muchos proveedores ejecutan navegadores headful, aunque nadie vea la pantalla, pagando el costo de display server, GPU y compositor
- Browser Use modificó el propio navegador para mantener una ejecución completamente headless
- El primer componente es un fork de Chromium
- Muchas herramientas stealth inyectan JavaScript en todas las páginas después de arrancar el navegador para ocultar la automatización
- Por ejemplo, sobrescriben el valor de
navigator.webdriverpara que el sitio veafalseen lugar detrue - Los sitios web pueden detectar que ese valor fue sobrescrito
- Browser Use parchea capas más bajas de Chromium para que esos valores no queden expuestos desde el principio
- El segundo componente es el fingerprinting
- El fingerprint del navegador es la combinación de información del navegador y la máquina que un sitio web puede leer
- Incluye cientos de detalles como sistema operativo, tamaño de pantalla, fuentes, salida gráfica, audio, zona horaria e idioma
- Browser Use utiliza decenas de miles de fingerprints reales de macOS, Windows y Linux
- Estos navegadores lograron 81% de evasión de bloqueos en su stealth benchmark y 84.8% en Halluminate BrowserBench
- Como no hay pantalla, el costo de ejecutar los navegadores es menor y también es más fácil escalarlos
Conectarse al navegador correcto
- Cuando el navegador está listo, el usuario se conecta por CDP
- La URL pública es una URL de WebSocket
- Delante de la flota de navegadores hay edge routers simples
- El router recibe la conexión WebSocket, le pregunta al control plane dónde está ese navegador y luego reenvía los bytes crudos de CDP a la VM correcta
- El router no decide dónde se ejecutará el navegador
- Si un router falla, otro router puede hacerse cargo de nuevas conexiones
- La asignación la maneja el control plane; el router solo transporta bytes
Resultados y siguientes pasos
- Actualmente cada sesión de navegador se reanuda desde un pequeño snapshot de VM que corre dentro de EC2 normal, y dentro de esa VM se ejecuta Chromium headless
- El cold start de la VM es de menos de 400 ms
- La latencia de creación del navegador medida desde la API pública es de p50 825 ms y p99 1.35 segundos
- Estas métricas se midieron en una prueba de estrés de 10,000 sesiones donde todos los navegadores iniciaron correctamente
- El leaderboard independiente de BrowserArena ubicó a Browser Use en el primer lugar con $0.02/hr y 100% reliability
- En esta infraestructura, el mayor costo que queda es Chromium mismo
- Después del resume, iniciar Chromium todavía toma unos 545 ms en p50
- Actualmente el snapshot se crea justo antes de iniciar Chromium
- Todos los navegadores despiertan desde el mismo punto limpio e idéntico, y luego cada uno inicia su propia instancia de Chromium
- El siguiente paso es crear el snapshot cuando Chromium ya esté ejecutándose
- Así, una nueva sesión podría despertar con un navegador ya vivo, sin tener que iniciarlo
- Este trabajo es complejo
- Un navegador en ejecución tiene dispositivos abiertos, timers, estado gráfico, estado de red y estado de fingerprint
- Hay que volver seguros esos estados antes de congelarlo
- Después del restore, cada navegador debe verse como su propio navegador, no como un clon del anterior
- Browser Use Cloud ya está disponible en cloud.browser-use.com
1 comentarios
Comentarios en Hacker News
Poner como benchmark la evasión de antibots se ve bastante poco ético. El objetivo de los antibots es bloquear bots no deseados, y este tipo de servicio al final hace que la web sea menos amigable para las personas y más cara
Los sitios van a seguir intentando bloquear el acceso automatizado, y las barreras para acceder al contenido solo van a aumentar. Que en la web crezcan las exigencias de verificación de identidad parece ser un efecto más amplio que no solo tiene que ver con restricciones por edad o “proteger a los niños”, sino también con defensa contra bots y protección de ingresos publicitarios
En sitios sin API también uso scrapers, y además indexo todo mi historial de compras en una base de datos para poder analizarlo. No quiero gastar aún más tiempo evadiendo detección de bots tonta, y si son datos a los que no hay otra forma de acceder, con gusto pagaría por ello. Al final es quemar recursos en un juego del gato y el ratón que los scrapers inevitablemente van a ganar
Dicho eso, ofrecer proxies residenciales sí probablemente sea poco ético. Muchas veces quienes aportan esas conexiones residenciales ni siquiera saben que fueron incorporados a ese tipo de servicio
Si no puedes quedarte sentado frente a la computadora 24 horas para conseguir entradas de un concierto, cuesta ver como poco ético usar un bot personal para comprar boletos de una banda que te gusta. En cambio, si es para reventa, sí estoy de acuerdo en que es poco ético. Los anti-antibot buscan hacer posible cosas que otros creen que no deberían automatizarse, y apostaría a que bastantes lectores de Hacker News han hecho algo así al menos una vez. Si es puramente por lucro, no suena bien, pero si sirve para tener una oportunidad frente a los revendedores, parece razonable
Como son solo uno entre muchos tenants de SaaS y no un cliente lo bastante grande como para exigir que quiten el CAPTCHA, simplemente rodean esa limitación
Lo que falta aquí es que la virtualización anidada en instancias EC2 normales pasó a estar disponible desde febrero de este año. Antes de eso, para ejecutar VMs de Firecracker había que usar instancias EC2 metal
Me sorprende un poco que, incluso llegando a este nivel, sigan apostando por Chromium
Nuestro servidor MCP de acceso web[0] levanta instancias del navegador como subprocesos con una configuración mucho más simple, y la mayor mejora en estabilidad, CPU y uso de memoria vino al cambiar de Chrome a Lightpanda[1]. Como dice el cierre del artículo, un navegador que arranca más rápido bien podría ser simplemente uno que asigna menos memoria desde el inicio
[0]: https://github.com/EratoLab/web-access-mcp
[1]: https://lightpanda.io
Navegadores como LightPanda no tienen nada de stealth y son muy fáciles de detectar. Si quitas lo que no hace falta, también hay maneras de hacer más rápido a Chromium. Sin rehacer todo el motor desde cero, creemos que Chromium puede llegar a ese rendimiento sin perder lo que para nosotros es la prioridad número uno: el stealth. El lenguaje no es el problema; C++ puede rendir igual de bien que Zig, aunque sí coincido en que la hinchazón de Chromium es grande
Opero una API de screenshots llamada ApiFlash, y en vez de Firecracker sobre EC2 usamos Chromium empaquetado en imágenes de contenedor de AWS Lambda
AWS Lambda da aislamiento y autoescalado gratis, así que es ideal para trabajos stateless con picos de carga, como los screenshots. Creo que obtienes casi las mismas ventajas que con la solución de browser-use, pero con una arquitectura mucho más simple. La contrapartida son los cold starts de AWS Lambda, aunque en la práctica reutiliza funciones calientes en llamadas consecutivas. Si tienes suficiente volumen de llamadas, los picos se suavizan y los cold starts tampoco ocurren tan seguido
Los problemas que tuvimos con Lambda fueron el límite de ejecución de 15 minutos, el precio, la falta de un mecanismo de snapshots y la ausencia de control de bajo nivel sobre el host de ejecución. Nosotros soportamos hasta 4 horas y, si hace falta, podemos correr aún más tiempo. Aun así, para la mayoría de los casos comunes de automatización web, Lambda alcanza y sobra
Dicen “Siguiente: saltarse el arranque de Chromium”, pero me pregunto si no podrían simplemente mantener un warm pool de navegadores ya en ejecución y asignarlos a las solicitudes entrantes
Desde la perspectiva del usuario, la latencia sería prácticamente cero. Dependiendo del patrón de tráfico, sí haría falta cierta lógica predictiva para agrandar o achicar el warm pool, pero parece la solución más fácil
El warm pool está bien, pero al final consume recursos y tienes que seguir arrancando navegadores para mantener el pool caliente y balanceado. Con cambios futuros planeamos conservar el arranque de Chromium y aun así tener la VM lista en menos de 50 ms, superando por completo al warm pool. Algunos clientes necesitan parámetros y funciones especiales, lo que vuelve más compleja la gestión del warm pool. La ruta común sería rápida, pero las excepciones podrían ser muy lentas, y queremos garantizar velocidad sin importar qué funciones necesite el navegador solicitado
Firecracker es una tecnología excelente. La usamos en una startup de entrevistas técnicas para ejecutar runtimes aislados para entrevistas de programación y espacios de trabajo personales, y ha sido muy estable y sorprendentemente ligera
Integrarlo con el SDK de Go también fue facilísimo
Está genial ver que userfaultfd se use más. Es una API realmente poderosa porque te da control total sobre cómo y desde dónde cargar memoria cuando ocurre un page fault
Es cierto que EC2 común ya es una VM, pero según entiendo hay ciertos tipos de EC2 que dan acceso al hipervisor y por eso también permiten Firecracker. Corríjanme si me equivoco
[1] https://aws.amazon.com/about-aws/whats-new/2026/02/amazon-ec...
Me pregunto por qué hace falta Firecracker. ¿No bastaría con ejecutarlo directamente en un contenedor? Entiendo la preocupación por el aislamiento, pero la combinación de navegador más escape de contenedor suena a un CVE de mil millones de dólares, ¿no?
Los contenedores ofrecen una superficie de ataque mucho más amplia que las VM y, como el estándar de la industria no los considera una frontera segura, es probable que se destinen menos recursos a gestionar CVE de escape de contenedor que a escapes de VM
¿Para hacer esto en una instancia que no sea
.metalno hace falta un parche del kernel? Parece que se necesita el parche PVM