Cloudflare lança Worker Previews com ambiente por branch do Git

O lançamento

A Cloudflare anunciou o Worker Previews, recurso que cria um ambiente de pré-produção isolado para cada branch do Git de um Worker. Cada Preview tem seu próprio código, configuração, URL, observabilidade e estado, permitindo testar mudanças em condições próximas de produção antes do merge. O contexto é o aumento de código gerado por agentes: mudanças maiores exigem mais teste, e a Cloudflare quer dar às ferramentas de automação capacidade de cobrir mais do ciclo de desenvolvimento sem torná-lo mais lento.

Como funciona

O comando npx wrangler preview (ou push automático em Workers conectados ao Git via Workers Builds) cria um Preview rodando como uma versão real do Worker, com URL estável que persiste entre pushes da mesma branch. É possível rodar centenas de Previews simultâneos, cada um independente dos demais e da produção. No painel, a navegação entre ambientes lembra troca de branches, com produção e Previews lado a lado - diferentemente dos Wrangler environments, que exigem implantar e gerenciar Workers separados.

Isolamento de estado

Recursos com estado recebem tratamento especial. Como Durable Objects seguem um modelo de instância única por ID de objeto, compartilhar o namespace com produção poderia modificar instâncias que servem tráfego real. Por isso, cada Preview recebe automaticamente um novo namespace de Durable Objects e uma aplicação de Containers, de modo que migrações falhas ou mudanças de esquema fiquem contidas naquela branch. O código acessa os recursos por ctx.exports, que resolve para o namespace de produção em produção e para o do Preview em um Preview.

Feedback loop e observabilidade

O tráfego pode vir do terminal, de CI, de um agente ou de cliques manuais. O Workers Observability mostra eventos, erros e traces com o ciclo completo de cada requisição - chamadas de fetch, operações de binding e invocações de handlers - escopados ao Preview, sem mistura com tráfego de produção ou de outras mudanças.

Para agentes, a Cloudflare sugere usar o Browser Run para abrir a URL em navegador headless, seguir fluxos de login e capturar screenshots ou eventos de DOM reproduzíveis. Um revisor pode acompanhar em tempo real com Live View ou intervir com Human in the Loop. O fluxo descrito permite que um agente opere de forma autônoma: implantar via Playwright MCP, clicar pela interface, consultar traces pelo servidor MCP do Workers Observability, corrigir, reimplementar e verificar - tudo restrito à branch.

Configuração base e domínio próprio

A configuração base dos Previews é definida uma vez em um bloco previews no arquivo de configuração do Wrangler, copiando variáveis, secrets, bindings e configurações da mesma forma que uma branch herda do main. Qualquer configuração pode ser sobrescrita em um Preview específico - por exemplo, apontando para banco de dados próprio ou chave de teste - sem afetar produção, a base ou outros Previews. As URLs também podem ser servidas em domínio customizado (como feature-login.previews.example.com) para que provedores de autenticação, cookies, CORS e redirects de OAuth se comportem como na produção, e podem ser protegidas com Cloudflare Access.

Dogfooding e clientes

Internamente, a Cloudflare usa o recurso para construir e testar o CloudflareOS, sua plataforma open-source para conectar agentes a sistemas corporativos via Gatekeepers. Mudanças em Gatekeepers são sensíveis porque um bug pode expor dados ou permitir ações indevidas, e alguns problemas só aparecem quando callbacks de OAuth, permissões, fluxos de aprovação e estado da aplicação rodam juntos - daí a necessidade de testar o sistema completo em um Preview isolado.

Clientes citados no post reforçam a motivação: a Supermemory usa Previews para validar fluxos HTTP, incluindo rotas com Durable Objects, antes de produção; a Ramp usou o recurso para revisar e testar PRs do Inspect, seu agente de código, inclusive pelo celular.

Limitações e próximos passos

A Cloudflare esclarece que os antigos preview URLs passam a se chamar Version URLs: eles apontam para versões específicas do Worker, mas não criam ambiente isolado por branch e só podiam apontar para recursos de produção. Os próximos passos anunciados são: manter todo o caminho da requisição dentro do Preview em aplicações multi-Worker (hoje, service bindings chamam a produção do Worker vinculado), fazer com que Queue consumers e Workflows rodem dentro de cada Preview (hoje, Previews só enviam mensagens às filas e não as consomem), e suportar Previews de longa duração para ambientes de staging, QA ou por desenvolvedor que persistem entre sprints, demanda vinda de times da beta privada.

Worker Previews está disponível agora, com documentação e canais de suporte no GitHub e no Discord da Cloudflare Developers.