Em 2026, a computação na borda deixou de ser promessa de marketing e se tornou o padrão para aplicações que exigem baixa latência, resiliência global e segurança integrada. A Cloudflare, com sua rede de mais de 300 cidades em mais de 100 países, processa cerca de uma em cada cinco requisições HTTP da internet e sustenta um dos maiores sistemas autônomos do mundo (AS13335). Dentro desse ecossistema, a plataforma Cloudflare Workers Workers evoluiu de um runtime simples de JavaScript na edge para uma suíte completa de computação, armazenamento, inteligência artificial e orquestração de fluxos de trabalho. Para profissionais de infraestrutura, segurança e desenvolvimento, entender as novas capacidades desse ambiente é fundamental para projetar arquiteturas escaláveis sem herdar a complexidade operacional de clusters regionais ou o custo imprevisível de egress em provedores tradicionais.
O contexto de 2026 é marcado por três forças: a explosão de aplicações baseadas em IA generativa, a necessidade de conformidade com regulações como a LGPD no Brasil e o aumento de ataques sofisticados no client-side. A Cloudflare respondeu com uma sequência de anúncios que afeta diretamente a operação de workloads serverless. Entre eles, destacam-se o controle de acesso granular para Workers, a exclusão de instâncias de Workflows em lote, o rastreamento automático de chamadas JavaScript RPC entre Workers e Durable Objects, o suporte a Python Workers com Hyperdrive para PostgreSQL e MySQL, e a opção rejectIfBusy para rejeitar requisições síncronas de inferência quando a capacidade de Workers AI está indisponível. Esses recursos mudam a forma como times operam, depuram e governam aplicações distribuídas na edge.
Historicamente, o Workers nasceu em 2017 como uma aposta da Cloudflare para executar código JavaScript diretamente nos seus Points of Presence (PoPs), sem servidores dedicados ou contêineres. O modelo de isolamento baseado em V8 isolates permitiu eliminar o problema clássico de cold start das arquiteturas FaaS, reduzindo o tempo de inicialização para menos de 1 milissegundo. Ao longo dos anos, a plataforma recebeu suporte a WebAssembly, Python, bindings para KV, D1, R2, Durable Objects, Queues e, mais recentemente, AI Gateway, Vectorize e Workflows. Essa evolução transformou o Workers em uma plataforma de desenvolvimento completa, concorrendo não apenas com funções serverless, mas também com microsserviços inteiros.
O objetivo deste artigo é apresentar, com profundidade técnica, o que mudou na plataforma Cloudflare Workers Workers, como essas novidades se conectam aos desafios de empresas brasileiras e quais cenários justificam a migração de cargas de trabalho para a edge. Você vai encontrar comparações de custo e performance com AWS, GCP e Vercel Edge, exemplos de arquitetura sem código malicioso, comandos de configuração prontos para uso e recomendações práticas baseadas na operação diária de ambientes corporativos. Na JRT Technology Solutions, configuramos o Cloudflare para clientes que precisam de CDN, WAF, Zero Trust e Workers com alto desempenho e conformidade regulatória. Nossos especialistas em infraestrutura CDN recomendam que a adoção de edge computing comece por casos bem definidos, e é exatamente isso que vamos detalhar nas próximas seções.
1. O que aconteceu no Cloudflare Workers Workers: novos controles, tracers e Python
No ciclo de atualizações de setembro de 2026, a Cloudflare anunciou uma série de melhorias voltadas para reduzir riscos operacionais e ampliar a observabilidade do ambiente Cloudflare Workers Workers. Um dos anúncios mais relevantes para empresas que adotam GitOps e automação é a possibilidade de escopar o acesso a Workers individuais e atribuir funções mais granulares na Developer Platform. Agora, membros de equipe, tokens de CI e agentes automatizados podem receber permissões específicas para depurar, implantar ou monitorar apenas os Workers que fazem parte do seu escopo, sem expor toda a conta ou organização. Isso atende diretamente a requisitos de segregação de funções em ambientes com múltiplos times e pipelines de deploy.
Outra mudança importante apareceu na API de Workflows, o serviço de orquestração de tarefas com estado. A versão Wrangler 4.125.0 trouxe a capacidade de excluir instâncias de Workflow individualmente ou em lotes de até 100 instâncias. Antes, a limpeza de execuções concluídas ou abandonadas podia ser um processo manual e propenso a erro. Agora, é possível chamar instance.delete() para uma instância específica ou env.MY_WORKFLOW.deleteBatch([...]) para remover múltiplas instâncias, liberando o estado armazenado e interrompendo a execução atual. A cobrança de armazenamento do Workflows continua baseada no pico diário médio, portanto a exclusão proativa de instâncias antigas tem impacto direto na otimização de custos.
No campo da observabilidade, os traces do Workers agora incluem automaticamente spans de sessão JavaScript RPC. Antes, um trace parava no limite da chamada RPC do chamador, deixando invisível o tempo gasto dentro do Worker de destino ou de um Durable Object. Com a mudança, o dashboard mostra a sessão no lado do chamador, as chamadas de método individuais, a invocação no callee, chamadas aninhadas e callbacks para outro Worker. Cada span usa cores para distinguir os entrypoints envolvidos e setas para indicar chamadas de saída e entrada. Para ativar, basta habilitar observability.traces.enabled no arquivo de configuração do Wrangler; nenhuma alteração de código ou SDK adicional é necessária.
O ecossistema Python também avançou: Python Workers agora podem se conectar a bancos PostgreSQL e MySQL por meio do Hyperdrive. Isso permite que aplicações Python executadas na edge reutilizem os pools de conexão gerenciados pelo Hyperdrive, reduzindo a latência de conexão e a complexidade de gerenciamento de sessões com bancos de dados regionais ou globais. Complementando as melhorias, o Workers AI introduziu a opção rejectIfBusy: quando a capacidade de inferência síncrona está esgotada, a requisição falha imediatamente em vez de aguardar em fila. Esse comportamento é útil para aplicações sensíveis a timeout ou que preferem degradar graciosamente em picos de demanda.
Fora do escopo direto do runtime, a Cloudflare também atualizou a postura de segurança com políticas de remediação automática no CASB, usando a própria Developer Platform para revogar compartilhamentos de risco e enviar webhooks sem intervenção manual. Além disso, o lançamento de controles para permanecer indexável em mecanismos de busca enquanto bloqueia o treinamento de IA e a validação de DNSSEC pós-quântico no 1.1.1.1 mostram como a empresa está conectando infraestrutura, segurança e conformidade em um único plano de controle. Para operadores de plataformas serverless, o destaque continua sendo a maturidade do Cloudflare Workers Workers como camada de execução e orquestração.
2. O que é o Cloudflare Workers Workers e como funciona na edge
O termo Cloudflare Workers Workers pode soar redundante, mas reflete a amplitude de uma plataforma que hoje ultrapassa a definição original de “função na borda”. O Workers é um runtime serverless que executa código em isolados V8 — o mesmo motor JavaScript do Chrome — distribuídos nos mais de 275 PoPs da Cloudflare. Como não há contêineres nem máquinas virtuais para provisionar, o tempo de inicialização fica abaixo de 1 ms, e a escalada acontece automaticamente conforme o tráfego. Essa arquitetura elimina o problema de cold start que afeta plataformas baseadas em instâncias dedicadas, como o AWS Lambda tradicional, especialmente em regiões com menor densidade de servidores.
Um Worker pode ser escrito em JavaScript, TypeScript, Python ou WebAssembly e implantado globalmente com um único comando. Ele intercepta requisições HTTP, transforma respostas, consulta bancos de dados, chama APIs externas, executa modelos de IA e mantém estado por meio de Durable Objects. As bindings conectam o código a serviços como KV, D1, R2, Queues e Vectorize, sem que o desenvolvedor precise gerenciar credenciais ou endpoints de baixo nível. A tabela a seguir resume os principais componentes da Developer Platform e sua função dentro de uma arquitetura de borda.
Além dos serviços de dados, o Cloudflare Workers Workers se beneficia do roteamento anycast em toda a rede, o que significa que uma requisição entra no PoP mais próximo do usuário e é atendida localmente, sem depender de região central. O código é replicado em todos os PoPs em segundos, e as métricas de execução, erros e logs são consolidadas em tempo real. Essa capilaridade é um dos motivos pelos quais aplicações de comércio eletrônico, APIs públicas e microsserviços de autenticação conseguem manter p99 de latência abaixo de 50 ms em muitos mercados, inclusive no Brasil.
Do ponto de vista de segurança, o Workers roda em um sandbox multitenant com isolamento forte entre inquilinos. O tráfego passa primeiro pelo WAF, Bot Management e proteção DDoS da Cloudflare antes de chegar ao código, o que reduz drasticamente a superfície de ataque. A integração com Zero Trust permite que apenas usuários autenticados via Access alcancem endpoints privados, enquanto o Gateway filtra DNS e HTTPS para dispositivos remotos. Essa convergência entre edge computing e SASE é um diferencial que plataformas tradicionais de função como serviço não oferecem nativamente.
3. Por que o Cloudflare Workers Workers importa para desenvolvedores e empresas
Para desenvolvedores, o valor imediato do Cloudflare Workers Workers está na redução do tempo entre escrever código e tê-lo em produção. O fluxo com Wrangler permite criar um Worker, testar localmente com wrangler dev e publicar globalmente em menos de um minuto. Não há configuração de VPC, security groups, subnets ou balanceadores de carga; a infraestrutura é abstraída, mas ainda observável. A nova granularidade de papéis anunciada em setembro de 2026 reforça esse benefício para times grandes: engenheiros de QA podem receber acesso somente de leitura em um Worker de staging, enquanto o token de CI de produção tem permissão para implantar apenas um conjunto limitado de Workers.
Para empresas, o principal atrativo é a previsibilidade de custos. Em provedores como AWS, o custo de egress de dados é um dos itens mais imprevisíveis e caros — no S3, por exemplo, a transferência de 1 TB pode custar dezenas de dólares. No Cloudflare, o R2 elimina a taxa de egress, e o plano gratuito do Workers inclui 100.000 requisições por dia. Mesmo no plano pago, o modelo é baseado em milhões de requisições e milissegundos de CPU, sem cobranças ocultas por transferência entre serviços. A tabela abaixo compara os principais critérios operacionais.