Cloudflare Workers ganha CI/CD nativo e depuração com IA na atualização de agosto

Em 4 de agosto de 2026 a Cloudflare publicou três novidades para quem opera código no Workers: o @cloudflare/ci, um motor de CI/CD que roda dentro da própria conta; captura automática de traces OpenTelemetry no ambiente de desenvolvimento local; e instrumentação de agentes de IA pelo Agents SDK.

Antes do resto, um acerto de fato: não é o primeiro CI/CD nativo do Workers. O Workers Builds — integração direta com GitHub e GitLab para build e deploy automáticos — foi anunciado em open beta em 31 de outubro de 2024 e continua sendo a opção documentada para quem só quer commit virando deploy. O que chegou agora é outra coisa, e resolve outro problema.

@cloudflare/ci: pipeline como código, rodando na sua conta

O @cloudflare/ci é um pacote Apache-2.0, publicado no npm e com repositório em github.com/cloudflare/ci, que executa pipelines sobre Workflows (durável, com retry por etapa) e Sandbox (execução isolada de comandos). Não é um serviço gerenciado com painel: você importa a biblioteca, define classes de Workflow em TypeScript e faz deploy de um Worker seu. As rotas HTTP e os handlers de fila que disparam o pipeline são código seu.

O que isso muda na prática, e o que exige atenção:

• Exige a flag nodejs_compat — o runtime não é Node.js.
• Como o Workflows reexecuta etapas em caso de falha, todo comando precisa ser idempotente. Um npm publish mal isolado vai rodar duas vezes.
• A saída bruta dos comandos não passa por redação de segredos. Token vazado em log fica no log.
• O Sandbox roda sobre Containers, que exigem o Workers Paid (US$ 5/mês). A cota incluída é de 375 vCPU-minutos, 25 GiB-hora de memória e 200 GB-hora de disco por mês. Workflows, esse sim, está GA e disponível em plano gratuito e pago.

Trace local: depurar antes de subir

Rodando wrangler dev ou vite dev, o tooling passa a capturar automaticamente traces OpenTelemetry estruturados e os logs de console correlacionados de cada invocação local. Os spans cobrem a chamada do handler, os fetch() de saída e as chamadas a bindings — que é exatamente onde a maioria dos erros de Worker aparece (D1, R2, KV, Durable Objects).

Os dados ficam expostos em duas frentes: uma UI de navegador para inspecionar spans, tempos, atributos e erros; e uma API somente leitura em /cdn-cgi/explorer/api, que serve o próprio schema OpenAPI. Essa segunda parte é o ponto: é por ela que um agente de IA consulta o trace e diagnostica a falha sem que você cole log em prompt.

Agent traces e a conta que começa em 1º de outubro

O Agents SDK passou a instrumentar automaticamente aplicações de agente, além do AI SDK v6 e v7 — neste caso envolvendo o namespace com wrapAISDK(). O trace mostra cada turno do agente com as chamadas de modelo, execuções de ferramenta, aprovações, consumo de tokens e as operações do runtime do Workers. Gravar o conteúdo de mensagens e de payloads de ferramenta é opt-in explícito, via storeMessages e storeTools.

Habilitar exige mexer no Wrangler:

{
  "observability": {
    "traces": { "enabled": true, "head_sampling_rate": 0.05 }
  }
}

O tracing do Workers está em early beta, e por isso não liga sozinho. A amostragem é head-based (o default é 1, ou 100% das requisições). Os spans consomem a mesma cota dos Workers Logs: no plano gratuito, 200 mil eventos por dia e 3 dias de retenção; no pago, 20 milhões por mês inclusos, 7 dias de retenção e US$ 0,60 por milhão adicional.

Grátis durante o beta — mas a Cloudflare avisa que a partir de 1º de outubro de 2026 o tracing passa a ser cobrado. Se você ligar com amostragem em 100% num Worker de volume alto e esquecer, a conta de outubro cobra a lembrança. Ajuste o head_sampling_rate agora.

Fontes: blog da Cloudflare, changelog de tracing local e documentação de traces.