El equipo de Browser Use Cloud explica cómo reconstruyó su infraestructura de navegadores en la nube para reducir el precio por hora de 0,06 a 0,02 dólares —tres veces más barato— y, al mismo tiempo, acelerar el arranque y el escalado de las sesiones. El artículo describe la arquitectura basada en Firecracker, un sistema de micro máquinas virtuales (microVMs) que ejecuta cada sesión de navegador en un entorno aislado con su propia CPU, memoria, disco y red. La peculiaridad del enfoque es que Firecracker corre sobre instancias EC2 convencionales de Amazon Web Services en lugar de servidores bare-metal, lo que implica una virtualización anidada (VM dentro de VM).
Los autores detallan los problemas de rendimiento derivados de esa decisión y las soluciones aplicadas. El cuello de botella principal eran los fallos de página durante la restauración de la memoria del navegador: en el arranque en frío representaban el 72 % de las salidas de la VM y retrasaban la disponibilidad del navegador hasta 9,8 segundos. La solución pasó por mapear la memoria en páginas de 2 MB en lugar de 4 KB (512 veces más grandes) y por pre cargar las páginas calientes mediante un controlador propio de userfaultfd, lo que redujo los fallos de página unas 91 veces y el tiempo hasta un navegador listo para recibir comandos vía Chrome DevTools Protocol a 3,1 segundos.
También se descartaron los unikernels del proyecto Unikraft por su缺乏 de autoescalado, lo que provocó una caída de producción de 45 minutos durante una prueba de carga. Se construyó un plano de control propio que monitoriza la flota en tiempo real —más rápido que las ventanas de un minuto de CloudWatch— y decide cuándo añadir o retirar máquinas. El resultado es un sistema capaz de levantar hosts en unos 30 segundos, mantener el aislamiento entre sesiones y ofrecer un precio por hora de navegador significativamente inferior, todo ello pensado para que los agentes de IA puedan conectarse a navegadores remotos de forma económica y escalable.