Cloudflare disponibiliza como código aberto o mecanismo de navegador Kitesurf para agentes de IA

A Cloudflare anunciou em 13 de novembro de 2026 que o Kitesurf, seu mecanismo experimental de navegador para agentes de IA, agora está disponível como código aberto sob a licença Apache 2.0. Os desenvolvedores podem examinar e modificar o código, executá-lo localmente ou implantar sua própria instância no Cloudflare Workers.

O repositório público permite que os desenvolvedores operem e modifiquem o mecanismo em suas próprias contas da Cloudflare, em vez de depender exclusivamente das APIs gerenciadas do Browser Run. A Cloudflare havia prometido essa possibilidade quando apresentou o Kitesurf em 6 de agosto de 2026 e voltou a mencioná-la em uma atualização de 28 de setembro de 2026, que adicionou suporte ao WebMCP, ampliou a cobertura da API do navegador e do Browser Run e introduziu a renderização de terminal.

Por dentro do design do Kitesurf voltado para agentes

O Kitesurf transforma HTML e CSS em páginas renderizadas, executa o JavaScript das páginas e produz capturas de tela sem usar o Chrome nem um contêiner de navegador. Ele disponibiliza um endpoint do Chrome DevTools Protocol (CDP), a interface de controle usada pelo Chrome DevTools e por softwares de automação compatíveis, permitindo a conexão de clientes Puppeteer e estruturas de agentes de IA.

Internamente, o Engine coordena as sessões do navegador e as conexões dos clientes; o PageScript executa a página e seu JavaScript; e o PageRenderer produz o resultado visual. A plataforma Developer Platform da Cloudflare é combinada com componentes em Rust compilados para WebAssembly: o Blitz fornece análise de HTML, DOM, layout e pintura; o Stylo cuida do CSS; as bibliotecas Linebender abrangem texto e gráficos 2D; e o Krilla gera arquivos PDF. O Boa fornece um ambiente de execução JavaScript alternativo dentro do WebAssembly quando o código da página não pode ser executado nos Dynamic Workers.

A Cloudflare afirma que o objetivo do design é oferecer aos agentes o acesso à web de que precisam, com menor uso de CPU e memória do que um navegador Chromium completo, e ampliar a capacidade sob demanda em toda a sua rede Workers. A arquitetura original trata cada carregamento de página como uma entrada não confiável e isola os componentes de acordo com os recursos de que precisam. Um worker SandboxOutbound dedicado cuida de todas as solicitações externas, aplica a política de rede e mantém separados os cookies de cada página; os outros componentes não podem acessar a rede diretamente.

A ausência de estado também faz parte desse design. O Engine mantém o estado da sessão, enquanto os demais componentes podem ser descartados sempre que possível, permitindo que a capacidade acompanhe os picos de atividade dos agentes. O PageRenderer não mantém estado persistente das páginas, portanto o Engine pode substituí-lo após uma solicitação de renderização malsucedida ou interrompida.

Requisitos e segurança da hospedagem própria

O desenvolvimento local requer Bazelisk, Node.js 22 ou posterior e pnpm 9.15.4. O comando de desenvolvimento compila os módulos WebAssembly e os pacotes da página e do renderizador, e então inicia um mecanismo local em 127.0.0.1:8787. A compilação inicial compila o núcleo em Rust e as dependências fornecidas pelo projeto; as compilações posteriores reutilizam o cache do Bazel. Em seguida, os desenvolvedores podem inspecionar as páginas pelo Chrome DevTools ou conectar o Puppeteer e outros clientes CDP.

A implantação na Cloudflare requer um plano pago do Workers porque os Dynamic Workers criam os workers isolados usados para páginas e renderizadores. Depois de testar localmente, os operadores podem implantar o mecanismo em sua própria conta como alternativa às APIs gerenciadas do Browser Run.

A hospedagem própria também transfere uma importante responsabilidade de segurança. O mecanismo não tem autenticação própria, e seu endereço workers.dev é público por padrão. Sem o Cloudflare Access ou outra camada de autenticação, qualquer pessoa com a URL poderia navegar pelo mecanismo, conectar clientes CDP, enviar solicitações originadas na conta Cloudflare do operador e consumir tempo de CPU pago e Dynamic Workers. O repositório instrui os operadores a proteger a URL imediatamente e explica como habilitar o Access em toda a conta antes da implantação, para evitar que ela fique pública por algum período.

Status experimental e processo de contribuição

O Kitesurf continua em fase experimental e sob intenso desenvolvimento. O repositório o descreve como um endpoint CDP, e não como uma implementação completa do Chrome; alguns recursos do Chrome DevTools ainda não são compatíveis. A Cloudflare está priorizando a compatibilidade, a confiabilidade e a eficiência.

No lançamento de agosto, a Cloudflare informou que o Kitesurf ainda não era adequado para vídeo, WebGL, etapas de verificação de desafios contra bots que exigem impressões digitais TLS reais ou sessões autenticadas longas que dependem de estado persistente. Essas limitações mostram quais verificações de compatibilidade continuam importantes para as cargas de trabalho dos agentes, mesmo quando o menor consumo de recursos de um navegador mais leve é atraente.

O processo de contribuição é estruturado em torno desse trabalho contínuo. A Cloudflare pede que os possíveis colaboradores abram uma issue com uma reprodução mínima do problema ou uma abordagem proposta e obtenham o aval de um mantenedor antes de enviar uma solicitação de pull. São preferidas alterações bem delimitadas, com testes e escopo definido, mas também são bem-vindas falhas de renderização reproduzíveis, fluxos de automação que não funcionam e correções na documentação.

Para os desenvolvedores, a contrapartida é ter controle direto sobre a pilha do navegador, assumindo a responsabilidade de proteger a implantação e de lidar com a compatibilidade ainda incompleta do mecanismo com o Chrome e as plataformas web.