- O Browser Use Cloud passou a usar uma VM Firecracker dedicada por sessão de navegador, reduzindo o tempo de início de uma nova sessão para menos de 1 segundo e baixando o custo de US$ 0,06 para US$ 0,02 por hora de navegador
- A arquitetura anterior com Unikraft era boa para custo ocioso, mas exigia ajuste manual de capacidade em picos de tráfego, e um teste de carga derrubou a produção por 45 minutos
- A nova arquitetura usa um control plane próprio que monitora a frota de navegadores em tempo real para decidir com mais granularidade que o CloudWatch o posicionamento, a expansão e o draining dos hosts EC2
- Em vez de usar instâncias
.metal, a empresa escolheu executar Firecracker sobre EC2 comum com virtualização aninhada e reduziu gargalos com páginas de memória de 2 MB,userfaultfd, fixação de vCPU, prioridade em tempo real e patches no Chromium headless - O cold start da VM fica abaixo de 400 ms e, em um teste de estresse com 10.000 sessões, a latência de criação do navegador via API pública foi de p50 825 ms e p99 1,35 s, com todos os navegadores iniciando com sucesso
Navegadores em nuvem rápidos, isolados e baratos
- O objetivo do Browser Use Cloud é iniciar navegadores rapidamente, isolar o estado entre sessões e reduzir custos
- Uma sessão inclui Chromium, sistema de arquivos, cookies, cache, configuração de proxy, downloads e, às vezes, até sessões de clientes já autenticadas
- Se um navegador puder ler o estado de outro, isso vira um problema de segurança, então cada sessão precisa ficar isolada do host e das demais sessões
- A solução mais comum é usar VMs com sua própria CPU, memória, disco e dispositivos de rede, mas isso é pesado e caro demais para um ambiente de navegadores em nuvem em que VMs são criadas continuamente e descartadas ao fim da sessão
- A nova arquitetura executa todas as sessões do Browser Use Cloud em uma pequena VM Firecracker, rodando essas VMs sobre Amazon EC2
Por que deixaram o Unikraft
- A arquitetura anterior executava os navegadores em nuvem com Unikraft
- O Unikraft carrega um unikernel, uma imagem pequena feita sob medida, em vez de inicializar um Linux completo
- Unikernels iniciam rápido e podem ser desligados quando não há usuários, o que reduz o custo ocioso
- O gargalo era aumentar rapidamente a capacidade de navegadores durante picos de tráfego
- O Unikraft não tinha autoscaling embutido de boa qualidade
- Engenheiros precisavam alterar variáveis e adicionar instâncias manualmente
- Um teste de carga derrubou a produção por 45 minutos
- Depois da reconstrução, passaram a usar Firecracker
- O Firecracker fornece a camada para criar, monitorar e executar VMs
- Ele fornece CPU, memória, disco e dispositivos de rede para cada VM, isolando-as do host e entre si
Automatizando a escala dos navegadores com um control plane próprio
- O Firecracker permite dar uma VM para cada navegador, mas não decide automaticamente quantas VMs devem existir, onde colocá-las ou quando escalar
- O Browser Use criou seu próprio control plane para monitorar a frota de navegadores e decidir quando fazer scale up ou down
- Quando um usuário pede um navegador, o control plane escolhe uma máquina com capacidade disponível
- Quando o tráfego aumenta, mais máquinas são iniciadas; quando cai, máquinas a serem removidas deixam de receber novos navegadores
- O control plane observa a frota em tempo real
- O CloudWatch, serviço de monitoramento da AWS, normalmente reage em janelas de 1 minuto
- O control plane sabe de informações que métricas comuns não mostram, como navegadores ainda iniciando, máquinas em remoção e hosts que não devem receber novas sessões
- As requisições dos usuários passam por um edge router stateless até o control plane, que escolhe um host EC2 com folga
Por que executar Firecracker sobre EC2 comum
- A forma mais comum de executar Firecracker na AWS é usar instâncias
.metal- Em
.metal, aluga-se o servidor físico inteiro para que o Firecracker rode diretamente
- Em
- O Browser Use escolheu EC2 comum
- Máquinas EC2 comuns podem ser obtidas mais rapidamente
- O custo de manutenção é menor
- Os hosts inicializam a partir de imagens pré-criadas e começam a oferecer navegadores em cerca de 30 segundos após subir
- Se é possível adicionar hosts mais rápido, a capacidade ociosa paga diminui, e o custo repassado ao cliente também cai
- O preço disso é uma estrutura de VM dentro de VM
- O EC2 comum já roda dentro da camada de isolamento da AWS
- Dentro dele, rodam novamente as VMs de navegador
- Quando a VM de navegador pede ajuda ao host, ela precisa atravessar duas camadas de VM, o que adiciona latência
- O Browser Use aceitou esse compromisso para ter scale-up mais rápido e custo menor, concentrando-se em acelerar o caminho de execução do Firecracker
Do pedido até um navegador utilizável
- Quando o usuário solicita um navegador, o control plane escolhe uma máquina com capacidade disponível
- Essa máquina restaura uma VM de navegador salva e inicia o Chromium dentro dela
- Quando o Chromium chega a um estado controlável, ela retorna uma URL de conexão
- O agente do usuário se conecta a essa URL
- O Browser Use controla o Chromium via Chrome DevTools Protocol (CDP) sobre WebSocket
- O CDP é a API remota do Chrome para ações como clicar em botões, digitar texto, ler páginas e tirar screenshots
- Havia três gargalos principais na latência
- Restauração da memória da VM
- Inicialização do Chromium
- Manter o stealth sem ser detectado por proteções anti-bot
Primeiro gargalo: restauração da memória
- Os navegadores de produção não inicializam do zero; eles retomam de um snapshot
- O snapshot é uma VM salva que já foi inicializada e ficou pausada logo antes do início do Chromium
- Retomar uma VM é mais rápido que um boot novo, mas no cold start inicial os page faults respondiam por 72% de todas as saídas da VM
- O tempo entre retomar a VM e ter um navegador pronto para CDP era inicialmente de 9,8 segundos
- O motivo da lentidão é que, quando a VM restaurada toca a memória pela primeira vez, o host precisa remapear aquela região
- Esse evento é um page fault
- Em VMs aninhadas, page faults podem atravessar duas camadas de VM, o que é caro
- A solução foi mapear memória em unidades maiores
- Antes, a restauração usava páginas de 4 KB
- Agora, usa páginas de 2 MB
- Cada página cobre 512 vezes mais memória, reduzindo fortemente os page faults enquanto o navegador desperta
- Também foi adicionado um handler customizado para
userfaultfd, a API do Linux para tratar páginas de memória ausentes- Antes de executar a VM, ele carrega a memória que o Chromium provavelmente acessará primeiro
- Isso evita uma avalanche de page faults ao iniciar o Chromium
- Com essa mudança, o tempo entre a retomada da VM e um navegador capaz de aceitar comandos caiu de 9,8 segundos para 3,1 segundos
- O número de vezes em que a VM de navegador parava e pedia ajuda ao host para lidar com memória ausente caiu de cerca de 100.000 para cerca de 1.100 por retomada, uma redução de aproximadamente 91 vezes
- Pequenas otimizações também se somaram
- Foi desativada uma verificação de 500 ms que buscava um teclado PS/2 antigo e inexistente
- A verificação de prontidão mudou de polling HTTP para leitura de logs via
vsock - Quando o driver do navegador escreve uma mensagem de pronto no log, o host a lê por
vsocke confirma o estado em menos de 1 ms
Segundo gargalo: inicialização do Chromium e alocação de CPU
- Ao iniciar, o Chromium consome muita CPU porque cria renderer, compositor e V8 isolates de uma vez
- Depois da inicialização, a automação do navegador é relativamente tranquila
- O agente clica, espera, lê e clica de novo
- O navegador passa a maior parte do tempo esperando páginas, respostas de rede e a próxima ação do agente
- Por essa característica, é possível fazer muito packing de navegadores em um único host
- O burst de CPU no momento da inicialização é tratado em duas etapas
- Enquanto o navegador é retomado e o Chromium inicia, a vCPU fica sem pinning
- Assim, o Linux pode distribuir o trabalho da CPU do navegador por todo o host, sem prender a carga a núcleos fixos
- Quando o navegador sinaliza que está pronto, a vCPU é fixada em núcleos estáveis
- Se o pinning é feito desde o início, vários navegadores iniciando ao mesmo tempo acabam concentrados nos mesmos hot cores, e alguns launches falham
- O tratamento de hyperthreading também foi ajustado
- Um núcleo físico de CPU normalmente aparece como duas CPUs lógicas, chamadas sibling threads
- Se duas VMs de navegador recebem uma sibling thread cada, elas competem pelo mesmo núcleo físico
- Nesse ambiente aninhado, essa disputa aparecia como falhas de inicialização
- Agora, cada navegador recebe as duas sibling threads do núcleo físico que usa
- Cada thread de vCPU fixada também recebe prioridade em tempo real
- Assim, o Linux executa a VM imediatamente, em vez de deixá-la parada atrás de tarefas menos importantes
- Antes da mudança, em um teste com 1.000 navegadores, 17% das sessões se perdiam logo após a criação
- Depois da mudança, no mesmo teste, a perda caiu para 0
Navegadores stealth sem interface gráfica
- Navegadores headless rodam sem janela visível; navegadores headful rodam como um navegador de notebook, com janela, gráficos e frames de renderização
- O Chromium headless puro é fácil de detectar em sites que usam medidas anti-bot
- Segundo o benchmark de stealth do Browser Use, o Chromium headless puro evitava bloqueio em apenas 2% dos casos
- Executando o mesmo Chromium em modo headful com janela visível, a taxa de evasão subia para 50% só por causa da renderização
- É por isso que muitos provedores executam navegadores headful, pagando o custo de display server, GPU e compositor mesmo quando ninguém vê a tela
- O Browser Use alterou o próprio navegador para manter execução totalmente headless
- O primeiro componente é um fork do Chromium
- Muitas ferramentas de stealth injetam JavaScript em todas as páginas após a inicialização do navegador para esconder a automação
- Por exemplo, sobrescrevem o valor de
navigator.webdriverpara que os sites vejamfalseem vez detrue - Sites podem detectar que esse valor foi sobrescrito
- O Browser Use aplica patches em camadas mais baixas do Chromium para que esses valores não sejam expostos desde o início
- O segundo componente é o fingerprinting
- A fingerprint do navegador é a combinação de informações do navegador e da máquina que o site consegue ler
- Ela inclui centenas de detalhes como sistema operacional, tamanho de tela, fontes, saída gráfica, áudio, fuso horário e idioma
- O Browser Use usa dezenas de milhares de fingerprints reais de macOS, Windows e Linux
- Esses navegadores registraram 81% de evasão de bloqueio no benchmark de stealth e 84,8% no Halluminate BrowserBench
- Como não há tela, o custo de executar os navegadores é menor e a escala é mais simples
Conectando ao navegador correto
- Quando o navegador fica pronto, o usuário se conecta via CDP
- A URL pública é uma URL WebSocket
- Na frente da frota de navegadores há edge routers simples
- O router aceita a conexão WebSocket, pergunta ao control plane onde está aquele navegador e encaminha os bytes brutos do CDP para a VM correta
- O router não decide onde o navegador vai rodar
- Se um router cair, outro pode assumir novas conexões
- O control plane cuida do posicionamento, e o router apenas encaminha bytes
Resultados e próximos passos
- Hoje, cada sessão de navegador retoma a partir de um pequeno snapshot de VM executado dentro de EC2 comum, e o Chromium headless roda dentro dessa VM
- O cold start da VM fica abaixo de 400 ms
- A latência de criação do navegador via API pública é de p50 825 ms e p99 1,35 s
- Esses números foram medidos em um teste de estresse com 10.000 sessões no qual todos os navegadores iniciaram com sucesso
- O leaderboard independente do BrowserArena colocou o Browser Use em 1º lugar, com US$ 0,02/h e 100% de confiabilidade
- O maior custo restante nessa infraestrutura é o próprio Chromium
- Depois do resume, iniciar o Chromium ainda leva cerca de 545 ms em p50
- Atualmente, o snapshot é criado imediatamente antes do início do Chromium
- Todos os navegadores despertam do mesmo ponto limpo e idêntico, depois cada um inicia seu próprio Chromium
- O próximo passo é criar o snapshot depois que o Chromium já estiver em execução
- Assim, novas sessões poderiam despertar junto com um navegador já vivo, sem precisar iniciá-lo
- Isso é complexo
- Um navegador em execução tem dispositivos abertos, timers, estado gráfico, estado de rede e estado de fingerprint
- Esses estados precisam ser tornados seguros antes do freeze
- Depois do restore, cada navegador precisa parecer seu próprio navegador, não um clone do anterior
- O Browser Use Cloud já está disponível em cloud.browser-use.com
1 comentários
Comentários do Hacker News
Usar a evasão de anti-bot como benchmark parece bem antiético. O objetivo de anti-bot é bloquear bots indesejados, e esse tipo de serviço acaba tornando a web mais hostil para humanos e mais cara
Os sites vão continuar tentando bloquear acesso automatizado, e as barreiras de acesso a conteúdo só vão aumentar. O crescimento das exigências de verificação de identidade na web parece ser um efeito mais amplo que inclui não só restrições de idade ou “proteger as crianças”, mas também defesa contra bots e proteção da receita de anúncios
Em sites sem API, também uso scraper, e indexo todo o meu histórico de compras em um banco de dados para poder analisar depois. Não quero gastar ainda mais tempo burlando detecção de bots idiota, e se forem dados que não consigo acessar de outro jeito, eu pagaria de bom grado. No fim, é gastar recursos em um jogo de gato e rato que os scrapers inevitavelmente vão vencer
Dito isso, oferecer proxies residenciais provavelmente é antiético. Muitas vezes, os provedores dessas conexões residenciais nem sabem que foram incorporados a esse tipo de serviço
Se eu não posso ficar 24 horas na frente do computador para conseguir ingresso para um show, é difícil chamar de antiético usar um bot pessoal para comprar ingressos da banda de que gosto. Por outro lado, concordo que, se for para cambismo, aí é antiético. Um anti-bot contra anti-bot serve para possibilitar coisas que outros acham que não deveriam ser automatizadas, e imagino que bastante gente no Hacker News já tenha feito isso ao menos uma vez. Se for puramente por lucro, acho ruim, mas se for para ter uma chance contra cambistas, parece aceitável
Como elas são apenas um entre vários tenants SaaS, não são clientes grandes o bastante para exigir a remoção do CAPTCHA, então simplesmente contornam essa limitação
O ponto que faltou aqui é que a virtualização aninhada em instâncias EC2 comuns passou a ser possível desde fevereiro deste ano. Antes disso, para rodar Firecracker VM, era preciso usar instâncias EC2 metal
Fiquei um pouco surpreso que, mesmo fazendo tudo isso, eles ainda tenham mantido o Chromium
Nosso servidor MCP de acesso web[0] sobe instâncias do navegador como subprocessos em uma configuração muito mais simples, e a maior melhora em estabilidade, CPU e uso de memória veio quando trocamos Chrome por Lightpanda[1]. Como o texto diz no fim, um navegador que inicia mais rápido pode simplesmente ser um navegador que aloca menos memória desde o começo
[0]: https://github.com/EratoLab/web-access-mcp
[1]: https://lightpanda.io
Navegadores como LightPanda não têm stealth nenhum e são muito fáceis de detectar. Dá para tornar o Chromium mais rápido removendo coisas desnecessárias. Sem precisar recriar o engine inteiro do zero, achamos que o Chromium pode chegar nesse nível de desempenho sem perder stealth, que é a prioridade máxima. A linguagem não é o problema, e C++ pode ter desempenho tão bom quanto Zig, mas concordo que o inchaço do Chromium é grande
Eu opero uma API de screenshots chamada ApiFlash e, em vez de Firecracker no EC2, empacoto o Chromium em uma imagem de contêiner do AWS Lambda
O AWS Lambda oferece isolamento e escalonamento automático de graça, então é ideal para trabalhos sem estado com picos de carga, como screenshots. Acho que você obtém quase os mesmos benefícios da solução browser-use, mas com uma arquitetura muito mais simples. O trade-off é o cold start do AWS Lambda, mas na prática ele reutiliza funções quentes em chamadas sequenciais. Se você tiver volume suficiente de chamadas, os picos se suavizam e o cold start não acontece com tanta frequência
Os problemas que tivemos no Lambda foram o limite de execução de 15 minutos, o preço, a ausência de mecanismo de snapshot e a falta de controle de baixo nível sobre o host de execução. Nós suportamos até 4 horas e, se necessário, dá para rodar ainda mais tempo. Ainda assim, para a maioria dos casos comuns de automação web, Lambda já é mais do que suficiente
Eles disseram “próximo passo: pular a inicialização do Chromium”, mas fiquei pensando se não daria para manter um conjunto de navegadores já em execução em um pool quente e atribuí-los às requisições que entrarem
Do ponto de vista do usuário, a latência seria quase zero. Dependendo do padrão de tráfego, seria preciso uma lógica de previsão para aumentar ou reduzir o pool quente, mas parece a solução mais simples
Pool quente é bom, mas no fim consome recursos, e você precisa continuar iniciando navegadores para manter e equilibrar o pool sempre aquecido. Com as próximas mudanças, planejamos manter a inicialização do Chromium e ainda assim deixar a VM pronta em menos de 50 ms, superando completamente o pool quente. Alguns clientes precisam de parâmetros e recursos especiais, o que aumenta a complexidade do pool quente. O caminho comum pode ser rápido, mas os casos excepcionais podem ficar bem lentos, e queremos garantir velocidade independentemente dos recursos de que o navegador solicitado precisar
Firecracker é uma tecnologia excelente. Eu a uso em uma startup de entrevistas para rodar runtimes isolados para entrevistas de código e workspaces pessoais, e ela é muito estável e surpreendentemente leve
Também foi bem fácil integrar com o SDK em Go
É legal ver userfaultfd sendo mais usado. É uma API realmente poderosa, porque dá controle total sobre como e de onde a memória será carregada quando ocorrer um page fault
É verdade que EC2 normal já é uma VM, mas pelo que entendo existem tipos específicos de EC2 que fornecem acesso ao hipervisor e por isso permitem Firecracker também. Corrijam-me se eu estiver errado
[1] https://aws.amazon.com/about-aws/whats-new/2026/02/amazon-ec...
Fico pensando por que Firecracker é necessário. Não daria para simplesmente rodar direto em um contêiner? Entendo a preocupação com isolamento, mas a combinação de navegador com escape de contêiner não seria um CVE de um bilhão de dólares?
Contêineres oferecem uma superfície de ataque muito maior que VMs e, como o padrão da indústria não os considera seguros da mesma forma, é provável que menos recursos sejam investidos em gerenciar CVEs de escape de contêiner do que em escapes de VM
Para fazer isso em uma instância que não seja
.metal, não seria necessário um patch no kernel? Acho que o patch de PVM é necessário