Por que essa migração importa?

O Browser Run permite que devs controlem navegadores headless programaticamente na rede global da Cloudflare. É usado para testes end-to-end, investigação de URLs, renderização de PDF e, cada vez mais, como base para agentes de IA que interagem com a web. Com a explosão de demanda (principalmente de builders de agentes), a infraestrutura compartilhada com o Browser Isolation (BISO) virou gargalo.

Problemas antes da migração:

  • Startup mais lento por causa das imagens grandes do BISO.
  • Distribuição global ruim, causando picos de latência.
  • Conflitos de escala entre sessões longas do BISO e o uso curto e explosivo do Browser Run.

A solução? Construir em cima da própria plataforma da Cloudflare: Containers com Durable Objects.

Fonte: Blog oficial do Cloudflare Browser Run

Cloudflare network architecture diagram showing global container distribution with DO and D1 Development Concept Image

A Migração: Containers + DO

A equipe começou inserindo um Worker no caminho das requisições para rotear uma parte dos usuários para Containers, mantendo o BISO como fallback. Essa abordagem dupla permitiu comparar performance e isolar bugs.

Desafio Arquitetural Principal

Containers com DO criam um Durable Object perto da requisição, mas o container pode subir do outro lado do mundo. Para requisições de screenshot que trocam dezenas de mensagens WebSocket, esses milissegundos extras somam.

Solução: Pools regionais pré-aquecidos de containers com DO. Quando chega uma requisição, o sistema escolhe o par DO-container mais próximo do usuário dentro da região.

// Simplificado: escolhe o melhor container baseado na região e latência
async function pickContainer(userLocation) {
  const region = getNearestRegion(userLocation);
  const pool = await getWarmPool(region);
  // Usa D1 para pegar um container atomicamente
  const container = await claimContainer(pool, region);
  return container;
}

De KV para D1 + Queues

Inicialmente, o estado dos containers ficava no KV. Mas a consistência eventual do KV (~30s de cache TTL) causava race conditions: um container marcado como "disponível" podia já estar ocupado quando a requisição chegava.

A solução: Migrar para D1 com semântica transacional SQLite. Aqui está a query de aquisição:

WITH candidate_pool AS (
  -- regras para escolher baseado em latência
)
UPDATE containers
SET status = 'picked'
WHERE sessionId IN (
  SELECT sessionId
  FROM candidate_pool
  ORDER BY RANDOM()
  LIMIT ?5
)
RETURNING data;

Writes em Lote para Escalar

Cada container atualiza seu estado a cada 5 segundos. Com 1ms por write, uma instância D1 só aguenta ~5.000 containers. Agrupando writes via Queues (100 linhas por lote), eles alcançaram 0.1ms P95, suportando até 500.000 containers por localização.

{
  "queues": {
    "consumers": [
      {
        "queue": "production-core-containers-queue-weur",
        "max_batch_size": 100,
        "max_batch_timeout": 1,
        "max_retries": 1
      }
    ]
  }
}

Essa arquitetura deu 4x mais navegadores concorrentes (até 120) e 50% menos tempo de resposta nas Quick Actions.

Quer saber como proteger usuários de links maliciosos? Veja Como a Proteção Avançada de Navegação verifica URLs sem comprometer a privacidade.

Developer monitoring browser container state migration from KV to D1 with Queues Dev Environment Setup

Benefícios Adicionais e Resultados

Quick Actions Otimizadas

Com containers dedicados, a equipe passou a enviar todos os parâmetros em uma única requisição HTTP, em vez de uma dança de WebSocket em múltiplas etapas. Isso reduziu drasticamente o tempo médio de resposta.

Upgrades de Navegador Mais Rápidos

Sem depender do cronograma de updates do BISO, agora eles lançam atualizações do Chrome e novas features (como WebGL e WebMCP) no próprio ritmo.

Limitações e Riscos

  • Backlogs nas filas ainda podem causar estado desatualizado. Regiões de fallback mitigam, mas adicionam complexidade.
  • Sharding do D1 por localização exige planejamento de capacidade cuidadoso. A equipe reforça que writes em lote são essenciais.
  • Distância DO-Container continua um desafio para operações sensíveis a latência, embora os pools regionais ajudem.

Próximos Passos

Latency comparison chart between old BISO infrastructure and new Container-based architecture IT Technology Image

Conclusão

A equipe do Browser Run transformou uma crise de escala em uma história de sucesso de plataforma. Migrando da infraestrutura compartilhada do BISO para Containers com Durable Objects, e resolvendo o gerenciamento de estado em tempo real com D1 + Queues, eles alcançaram ganhos dramáticos de performance. A lição principal: quando você escala, seja dono da sua infraestrutura e faça writes em lote.

Se você curte agentes de IA autônomos, dá uma olhada no REA da Meta: o agente de IA autônomo 5x mais produtivo em experimentação de ML.

Este conteúdo foi elaborado com o auxílio de ferramentas de IA, com base em fontes confiáveis, e revisado pela nossa equipe editorial antes da publicação. Não substitui o aconselhamento de um profissional especializado.