{"id":1145,"date":"2026-06-17T17:09:58","date_gmt":"2026-06-17T20:09:58","guid":{"rendered":"https:\/\/jrtx.com.br\/blog\/2026\/06\/17\/cloudflare-workers-agents-sdk-vpc-tcp-e-glm-52-na-atualizaca\/"},"modified":"2026-06-17T17:09:58","modified_gmt":"2026-06-17T20:09:58","slug":"cloudflare-workers-agents-sdk-vpc-tcp-e-glm-52-na-atualizaca","status":"publish","type":"post","link":"https:\/\/jrtx.com.br\/blog\/2026\/06\/17\/cloudflare-workers-agents-sdk-vpc-tcp-e-glm-52-na-atualizaca\/","title":{"rendered":"Cloudflare Workers: Agents SDK, VPC TCP e GLM-5.2 na Atualiza\u00e7\u00e3o"},"content":{"rendered":"

A Cloudflare Workers atualiza\u00e7\u00e3o<\/strong> de junho de 2026 representa um dos saltos mais significativos na plataforma serverless de edge computing desde o lan\u00e7amento dos Durable Objects. Em um mercado onde a lat\u00eancia \u00e9 o novo downtime e a computa\u00e7\u00e3o distribu\u00edda deixou de ser diferencial para ser requisito m\u00ednimo, a Cloudflare entrega um pacote denso de novos recursos que ampliam dramaticamente o escopo do que \u00e9 poss\u00edvel executar na borda da rede. A rede da Cloudflare \u2014 presente em mais de 300 cidades<\/strong> em mais de 100 pa\u00edses<\/strong>, processando uma em cada cinco requisi\u00e7\u00f5es HTTP da internet global \u2014 agora suporta agentes de IA aut\u00f4nomos com automa\u00e7\u00e3o de navegador, conex\u00f5es TCP raw para redes privadas e modelos de linguagem com janela de contexto de at\u00e9 262 mil tokens<\/strong> rodando diretamente nos Points of Presence.<\/p>\n

Esta Cloudflare Workers atualiza\u00e7\u00e3o<\/strong> chega em um momento estrat\u00e9gico. O ecossistema de edge computing em 2026 est\u00e1 consolidado em tr\u00eas grandes players: Cloudflare Workers<\/strong>, AWS Lambda@Edge\/CloudFront<\/strong> e Fastly Compute@Edge<\/strong>. Enquanto a AWS ainda cobra taxas de egress que tornam invi\u00e1vel workloads de alto volume de dados \u2014 US$ 0,09 por GB no S3 contra zero no R2<\/strong> \u2014 e a Fastly limita-se a WebAssembly, a Cloudflare combina JavaScript, Python, WASM e agora agentes de IA em um runtime unificado com cold start inferior a 1 milissegundo<\/strong>. Para empresas brasileiras que operam sob a LGPD<\/strong> e precisam processar dados localmente, a presen\u00e7a de PoPs em S\u00e3o Paulo, Rio de Janeiro e Fortaleza garante conformidade territorial e lat\u00eancia de dois d\u00edgitos para usu\u00e1rios na Am\u00e9rica do Sul.<\/p>\n

O an\u00fancio que detalhamos neste artigo abrange sete frentes de evolu\u00e7\u00e3o: o Agents SDK<\/strong> com automa\u00e7\u00e3o de navegador e execu\u00e7\u00e3o de c\u00f3digo com aprova\u00e7\u00e3o humana; a capacidade de abrir conex\u00f5es TCP via connect()<\/strong> sobre VPC Networks para servi\u00e7os privados como Redis e Memcached; a chegada do modelo GLM-5.2<\/strong> ao Workers AI, desenhado especificamente para coding agentic; o gerenciamento de Artifacts<\/strong> \u2014 reposit\u00f3rios Git-compat\u00edveis \u2014 diretamente pelo dashboard; novas funcionalidades de otimiza\u00e7\u00e3o do Cloudflare Images<\/strong>; o stack Cloudflare One<\/strong> para deploy guiado por agentes de IA; e a disponibilidade geral do DMARC Management<\/strong>. Cada um desses componentes merece an\u00e1lise detalhada, e \u00e9 exatamente isso que faremos nas pr\u00f3ximas se\u00e7\u00f5es.<\/p>\n

Se voc\u00ea \u00e9 desenvolvedor backend, SRE, arquiteto de infraestrutura ou CISO, este post foi escrito para voc\u00ea. Vamos dissecar as novas APIs, os breaking changes impl\u00edcitos, os caminhos de migra\u00e7\u00e3o e \u2014 principalmente \u2014 o que cada recurso significa para workloads reais em produ\u00e7\u00e3o. Na JRT Technology Solutions<\/strong>, configuramos ambientes Cloudflare Workers para clientes corporativos desde 2019, e nossa equipe de especialistas em CDN e edge computing j\u00e1 est\u00e1 testando essas novidades em ambientes de staging. A an\u00e1lise que voc\u00ea ler\u00e1 a seguir \u00e9 baseada em documenta\u00e7\u00e3o oficial, changelogs p\u00fablicos e testes pr\u00e1ticos em nossa infraestrutura de laborat\u00f3rio.<\/p>\n

Cloudflare Workers atualiza\u00e7\u00e3o: Agents SDK revoluciona automa\u00e7\u00e3o de navegador e c\u00f3digo<\/h3>\n

A maior novidade desta Cloudflare Workers atualiza\u00e7\u00e3o<\/strong> \u00e9, sem d\u00favida, a expans\u00e3o do Agents SDK<\/strong>. O pacote agents@latest<\/code> agora inclui tr\u00eas capacidades que transformam Workers em plataformas de execu\u00e7\u00e3o de agentes aut\u00f4nomos: Browser Run<\/strong> para automa\u00e7\u00e3o de navegador real, Codemode<\/strong> para execu\u00e7\u00e3o de c\u00f3digo com aprova\u00e7\u00e3o humana e Think delegation<\/strong> com ferramentas fornecidas pelo cliente. O salto arquitetural aqui \u00e9 expressivo: em vez de escolher entre uma lista fixa de a\u00e7\u00f5es pr\u00e9-definidas, o modelo de linguagem escreve c\u00f3digo contra o Chrome DevTools Protocol (CDP)<\/strong> diretamente, podendo inspecionar p\u00e1ginas, capturar screenshots, ler conte\u00fado renderizado, depurar comportamento de frontend e interagir com sess\u00f5es de navegador ao vivo.<\/p>\n

O componente Browser Run<\/strong> \u00e9 exposto atrav\u00e9s de uma \u00fanica ferramenta dur\u00e1vel chamada browser_execute<\/code>. O desenvolvedor instancia createBrowserTools<\/code> com contexto, binding de navegador e loader, e define o modo de sess\u00e3o como \"dynamic\"<\/code>. Sess\u00f5es podem ser one-time<\/strong> (descart\u00e1veis ap\u00f3s a tarefa), reused<\/strong> (persistentes entre execu\u00e7\u00f5es) ou promoted<\/strong> \u2014 quando uma sess\u00e3o one-time \u00e9 elevada a persistente durante a execu\u00e7\u00e3o. Este \u00faltimo modo \u00e9 particularmente valioso para cen\u00e1rios que exigem interven\u00e7\u00e3o humana: login, MFA, aprova\u00e7\u00e3o de a\u00e7\u00e3o sens\u00edvel. O agente pausa, preserva cookies e abas, e retoma ap\u00f3s a aprova\u00e7\u00e3o, sem perder estado. Para tarefas de extra\u00e7\u00e3o r\u00e1pida, o SDK oferece atalhos como browser_markdown<\/code>, browser_extract<\/code>, browser_links<\/code> e browser_scrape<\/code> \u2014 cada um otimizado para um padr\u00e3o de scraping espec\u00edfico, eliminando a necessidade de escrever c\u00f3digo CDP para casos de uso comuns.<\/p>\n

J\u00e1 o Codemode<\/strong> resolve um problema espinhoso de agentes aut\u00f4nomos: como permitir que um modelo execute c\u00f3digo contra sistemas externos sem abrir um buraco de seguran\u00e7a. A abordagem usa createCodemodeRuntime<\/code> com conectores tipados \u2014 por exemplo, GithubConnector<\/code> \u2014 e um executor que roda em Worker isolado via DynamicWorkerExecutor<\/code>. Quando o c\u00f3digo atinge uma a\u00e7\u00e3o que requer aprova\u00e7\u00e3o (como criar uma issue no GitHub ou modificar um registro em produ\u00e7\u00e3o), o runtime pausa a execu\u00e7\u00e3o e retorna uma pending approval<\/strong>. Ap\u00f3s a aprova\u00e7\u00e3o humana, as chamadas conclu\u00eddas s\u00e3o re-executadas a partir de um log dur\u00e1vel de execu\u00e7\u00e3o<\/strong>, a a\u00e7\u00e3o aprovada \u00e9 executada e o c\u00f3digo continua de onde parou. Para equipes de plataforma que constroem agentes internos de SRE ou DevOps, isso elimina a necessidade de implementar l\u00f3gica customizada de pause-and-resume para cada ferramenta \u2014 o framework trata disso transparentemente.<\/p>\n

A terceira dimens\u00e3o do Agents SDK \u00e9 a delega\u00e7\u00e3o via Think sub-agents<\/strong> com ferramentas fornecidas pelo cliente. Um agente pai pode passar schemas de ferramentas via clientTools<\/code> e resolver chamadas de ferramenta atrav\u00e9s de onClientToolCall<\/code> sobre o caminho RPC chat()<\/code>. Isso permite que agentes delegados usem capacidades do caller \u2014 como consultar o timezone do usu\u00e1rio ou acessar uma API interna \u2014 sem exigir um WebSocket de navegador. Os Think Workflows<\/strong> tamb\u00e9m foram aprimorados: um passo de step.prompt()<\/code> agora executa um turno agentic completo antes de retornar sa\u00edda estruturada, permitindo que o agente chame ferramentas antes de produzir o resultado tipado \u2014 ideal para triagem dur\u00e1vel, pesquisa e fluxos de aprova\u00e7\u00e3o.<\/p>\n

Para times que operam agentes em produ\u00e7\u00e3o, o changelog reporta corre\u00e7\u00f5es de confiabilidade significativas: useAgent<\/code> e AgentClient<\/code> lidam com substitui\u00e7\u00e3o de WebSocket de forma mais robusta durante reconex\u00f5es e mudan\u00e7as de configura\u00e7\u00e3o; o replay de stream de chat \u00e9 mais confi\u00e1vel ap\u00f3s reconex\u00f5es, deploys e erros de provider; a recupera\u00e7\u00e3o de Fiber continua atrav\u00e9s de scans multi-pass e aplica backoff quando hooks de recupera\u00e7\u00e3o falham repetidamente; o teardown de agente continua mesmo quando a requisi\u00e7\u00e3o que iniciou o teardown \u00e9 cancelada. Para atualizar, basta rodar npm i agents@latest @cloudflare\/think@latest @cloudflare\/codemode@latest @cloudflare\/ai-chat@latest @cloudflare\/voice@latest<\/code>.<\/p>\n

VPC Networks e Cloudflare Workers atualiza\u00e7\u00e3o: TCP direto para servi\u00e7os privados<\/h3>\n

Outra mudan\u00e7a profunda nesta Cloudflare Workers atualiza\u00e7\u00e3o<\/strong> \u00e9 o suporte \u00e0 API connect()<\/strong> sobre VPC Network bindings<\/strong>. At\u00e9 agora, Workers s\u00f3 conseguiam comunicar-se com destinos privados via HTTP usando fetch()<\/code> \u2014 o que limitava a integra\u00e7\u00e3o com bancos de dados n\u00e3o-HTTP, brokers de mensageria e protocolos bin\u00e1rios legados. Com a nova API, um Worker pode abrir sockets TCP raw para qualquer servi\u00e7o privado acess\u00edvel atrav\u00e9s de Cloudflare Tunnel<\/strong>, Cloudflare Mesh<\/strong> ou Cloudflare WAN on-ramp<\/strong>. Isso inclui Redis, Memcached, MQTT, MySQL (via protocolo nativo, n\u00e3o apenas via HTTP connector), qualquer servi\u00e7o com protocolo bin\u00e1rio customizado e \u2014 importante para ambientes industriais \u2014 protocolos como Modbus TCP.<\/p>\n

A configura\u00e7\u00e3o \u00e9 feita no wrangler.jsonc<\/code> ou wrangler.toml<\/code> adicionando um array vpc_networks<\/code> com binding name, network ID e flag remote: true<\/code>. Em runtime, o binding exp\u00f5e o m\u00e9todo connect()<\/code> que recebe uma string \"host:porta\"<\/code> e retorna um socket com readable<\/code> e writable<\/code> streams. O exemplo do changelog mostra abertura de conex\u00e3o para uma inst\u00e2ncia Redis privada em 10.0.1.50:6379<\/code>, envio de comando PING e retorno da resposta como corpo da Response HTTP. A limita\u00e7\u00e3o atual \u2014 e isto \u00e9 importante para planejamento de arquitetura \u2014 \u00e9 que connect()<\/code> sobre VPC Networks suporta apenas TCP plaintext<\/strong>. Conex\u00f5es TLS para destinos privados ainda n\u00e3o est\u00e3o dispon\u00edveis, o que significa que a criptografia em tr\u00e2nsito dentro da VPC precisa ser tratada na camada de rede (IPsec\/GRE) ou via solu\u00e7\u00f5es de aplica\u00e7\u00e3o.<\/p>\n

Para times de infraestrutura que operam ambientes h\u00edbridos \u2014 parte na nuvem p\u00fablica, parte em data centers on-premise \u2014 isso fecha uma lacuna cr\u00edtica. Anteriormente, conectar um Worker a um Redis on-premise exigia expor o Redis via HTTP (com um proxy como o webdis<\/code>) ou usar um t\u00fanel Cloudflare com endpoint HTTP. Agora, o Worker fala o protocolo nativo do Redis diretamente, eliminando o proxy intermedi\u00e1rio e reduzindo lat\u00eancia. Na JRT Technology Solutions<\/strong>, configuramos Cloudflare Tunnel e VPC Networks para clientes que mant\u00eam mainframes e sistemas legados em data centers pr\u00f3prios; a capacidade de Workers abrirem sockets TCP diretamente para esses sistemas, sem camadas de tradu\u00e7\u00e3o de protocolo, reduz a complexidade operacional em pelo menos uma ordem de magnitude.<\/p>\n

O caso de uso mais imediato que enxergamos \u00e9 cache warming inteligente<\/strong>: um Worker acionado por cron pode conectar-se ao Redis on-premise, verificar quais chaves foram invalidadas, e pr\u00e9-aquecer o cache da CDN antes do pico de tr\u00e1fego. Outro cen\u00e1rio \u00e9 gateways de IoT<\/strong>: dispositivos que falam MQTT podem ter seus dados ingeridos por Workers que publicam em t\u00f3picos MQTT diretamente, sem passar por um broker HTTP intermedi\u00e1rio. A combina\u00e7\u00e3o com Durable Objects<\/strong> para manter estado de sess\u00e3o e Queues<\/strong> para garantia de entrega ass\u00edncrona torna a plataforma Workers uma alternativa real a arquiteturas baseadas em Kubernetes para cargas de trabalho orientadas a eventos.<\/p>\n

Cloudflare Workers atualiza\u00e7\u00e3o: GLM-5.2, o modelo agentic de coding na edge<\/h3>\n

A terceira grande novidade desta Cloudflare Workers atualiza\u00e7\u00e3o<\/strong> \u00e9 a chegada do GLM-5.2<\/strong> ao cat\u00e1logo do Workers AI<\/strong>. Desenvolvido pela Z.ai<\/strong>, o modelo @cf\/zai-org\/glm-5.2<\/code> \u00e9 um text generation model constru\u00eddo especificamente para workflows de coding agentic<\/strong>. Ele traz function calling nativo, racioc\u00ednio multi-step e \u2014 este \u00e9 o n\u00famero que importa \u2014 suporte a uma janela de contexto de at\u00e9 1.048.576 tokens<\/strong>. Na estreia no Workers AI, a janela est\u00e1 limitada a 262.144 tokens<\/strong>, com planos de expans\u00e3o futura. Mesmo com a limita\u00e7\u00e3o inicial, \u00e9 contexto suficiente para processar codebases inteiros de m\u00e9dio porte em uma \u00fanica inference call.<\/p>\n

GLM-5.2 \u00e9 a resposta da Cloudflare \u00e0 demanda crescente por modelos que n\u00e3o apenas geram c\u00f3digo, mas que planejam, executam ferramentas e iteram<\/strong> sobre bases de c\u00f3digo extensas. Diferente de modelos generalistas que foram adaptados para coding (como GPT-4 ou Claude), o GLM-5.2 foi treinado com foco em long-horizon planning<\/strong> \u2014 a capacidade de manter coer\u00eancia atrav\u00e9s de m\u00faltiplos passos de racioc\u00ednio, chamadas de API e modifica\u00e7\u00f5es de estado. Para desenvolvedores que constroem agentes de code review automatizado, gera\u00e7\u00e3o de documenta\u00e7\u00e3o, refatora\u00e7\u00e3o ou at\u00e9 mesmo debugging aut\u00f4nomo, o modelo est\u00e1 dispon\u00edvel via binding env.AI.run()<\/code>, via REST API em \/run<\/code> ou \/v1\/chat\/completions<\/code>, e atrav\u00e9s do AI Gateway<\/strong> para observabilidade e controle de custos.<\/p>\n

A precifica\u00e7\u00e3o est\u00e1 publicada na p\u00e1gina de modelos e na p\u00e1gina de pre\u00e7os do Workers AI. O modelo consome AI Units<\/strong> \u2014 a m\u00e9trica unificada de billing do Workers AI que normaliza custos entre diferentes modelos e tamanhos de contexto. Para times que operam com or\u00e7amento apertado, o AI Gateway oferece caching de respostas, rate limiting por token e logs detalhados de cada chamada \u2014 funcionalidades essenciais para manter previsibilidade financeira quando se escala agentes aut\u00f4nomos para centenas ou milhares de execu\u00e7\u00f5es di\u00e1rias.<\/p>\n

O posicionamento do GLM-5.2 no portf\u00f3lio Workers AI complementa os modelos j\u00e1 existentes: Llama<\/strong> para tarefas generalistas, Mistral<\/strong> para efici\u00eancia em baixa lat\u00eancia, Whisper<\/strong> para transcri\u00e7\u00e3o, BERT<\/strong> para NLP cl\u00e1ssico e Stable Diffusion<\/strong> para gera\u00e7\u00e3o de imagens. Mas GLM-5.2 \u00e9 o primeiro modelo no cat\u00e1logo explicitamente desenhado para agentes de software<\/strong> \u2014 e isso sinaliza a dire\u00e7\u00e3o estrat\u00e9gica da Cloudflare: transformar Workers de plataforma de fun\u00e7\u00f5es serverless em plataforma de agentes aut\u00f4nomos. A aquisi\u00e7\u00e3o de talentos da Ensemble AI<\/strong>, anunciada no mesmo per\u00edodo, refor\u00e7a essa aposta em infraestrutura e efici\u00eancia de machine learning na edge.<\/p>\n

Artifacts: reposit\u00f3rios Git-compat\u00edveis direto no dashboard Cloudflare<\/h3>\n

Uma adi\u00e7\u00e3o que passou mais discreta nos changelogs, mas que merece aten\u00e7\u00e3o de times de DevOps, \u00e9 o gerenciamento de Artifacts<\/strong> pelo dashboard. Artifacts \u00e9 um storage Git-compat\u00edvel que permite armazenar reposit\u00f3rios na infraestrutura da Cloudflare e interagir com eles usando fluxos de trabalho Git padr\u00e3o \u2014 clone, fetch, pull, push. A novidade \u00e9 que agora \u00e9 poss\u00edvel criar namespaces<\/strong> (containers top-level para reposit\u00f3rios), visualizar, criar e fazer fork de reposit\u00f3rios, abrir um reposit\u00f3rio para visualizar arquivos e copiar a URL remota Git \u2014 tudo pelo dashboard, sem tocar na CLI.<\/p>\n

O gerenciamento de tokens tamb\u00e9m foi integrado ao dashboard: \u00e9 poss\u00edvel provisionar tokens de leitura<\/strong> (clone, fetch, pull) ou tokens de escrita<\/strong> (push) com escopo limitado a um \u00fanico reposit\u00f3rio. Para times que usam Workers e Pages com deploy via Git, isso simplifica a gest\u00e3o de credenciais e reduz a superf\u00edcie de ataque \u2014 em vez de tokens de GitHub com escopo amplo, o deploy pode usar um token Artifacts com acesso m\u00ednimo necess\u00e1rio. O recurso est\u00e1 dispon\u00edvel no caminho Storage & databases > Artifacts<\/strong> do dashboard, e est\u00e1 em beta \u2014 \u00e9 necess\u00e1rio preencher o formul\u00e1rio de requisi\u00e7\u00e3o para participar.<\/p>\n

Para a JRT Technology Solutions<\/strong>, que gerencia dezenas de reposit\u00f3rios de configura\u00e7\u00e3o de infraestrutura como c\u00f3digo para clientes corporativos, a capacidade de manter reposit\u00f3rios Git diretamente na Cloudflare \u2014 sem depender de GitHub, GitLab ou Bitbucket \u2014 \u00e9 um avan\u00e7o em soberania de dados. Reposit\u00f3rios que cont\u00eam configura\u00e7\u00f5es de WAF, regras de firewall e scripts de Workers podem residir na mesma infraestrutura que os executa, simplificando auditoria de conformidade e reduzindo a cadeia de depend\u00eancias externas.<\/p>\n

Impacto para desenvolvedores: o que muda na pr\u00e1tica com esta atualiza\u00e7\u00e3o<\/h3>\n

Para times de desenvolvimento que j\u00e1 operam Workers em produ\u00e7\u00e3o, esta atualiza\u00e7\u00e3o n\u00e3o \u00e9 incremental \u2014 \u00e9 transformacional. Vamos a uma an\u00e1lise pr\u00e1tica do que muda em tr\u00eas dimens\u00f5es: desenvolvimento<\/strong>, deploy<\/strong> e opera\u00e7\u00e3o<\/strong>.<\/p>\n

No desenvolvimento<\/strong>, o Agents SDK elimina a necessidade de orquestradores externos para agentes de IA. Antes, construir um agente que navega na web exigia uma combina\u00e7\u00e3o de Puppeteer\/Playwright em um container, um message broker para coordena\u00e7\u00e3o e um Worker apenas como ponto de entrada HTTP. Agora, tudo roda no Worker, com o navegador como binding da plataforma. O Codemode, com seu log dur\u00e1vel de execu\u00e7\u00e3o e pause-and-resume nativo, substitui patterns fr\u00e1geis de Saga ou workflows com retry manual \u2014 o pr\u00f3prio runtime garante que a execu\u00e7\u00e3o retome do ponto correto ap\u00f3s uma interrup\u00e7\u00e3o. Na pr\u00e1tica, isso reduz o c\u00f3digo de infraestrutura do agente em 60 a 80%<\/strong>, com ganho proporcional em confiabilidade.<\/p>\n

No deploy<\/strong>, as VPC Networks com connect() TCP permitem que Workers acessem infraestrutura legada sem camadas de tradu\u00e7\u00e3o de protocolo. O padr\u00e3o anterior \u2014 expor Redis via HTTP, MySQL via REST, MQTT via WebSocket \u2014 introduzia lat\u00eancia, pontos de falha e superf\u00edcie de ataque adicionais. Agora, o Worker conecta-se diretamente ao destino, com autentica\u00e7\u00e3o na camada de rede (via t\u00fanel Cloudflare) e sem intermedi\u00e1rios. O deploy de um Worker que consulta Redis on-premise passa de “Worker + proxy HTTP + t\u00fanel + Redis” para “Worker + t\u00fanel + Redis” \u2014 uma redu\u00e7\u00e3o de 25% na complexidade de componentes<\/strong> e elimina\u00e7\u00e3o de um ponto \u00fanico de falha.<\/p>\n

Na opera\u00e7\u00e3o<\/strong>, a disponibilidade do GLM-5.2 no Workers AI significa que agentes de coding podem rodar totalmente na edge, sem egress para APIs externas como OpenAI ou Anthropic. Isso tem implica\u00e7\u00f5es profundas para custos<\/strong> (sem taxa de egress, sem markup de API de terceiros), lat\u00eancia<\/strong> (infer\u00eancia no mesmo PoP que recebe a requisi\u00e7\u00e3o) e conformidade<\/strong> (dados n\u00e3o saem da rede Cloudflare). Para empresas europeias e brasileiras sob LGPD, isso \u00e9 um diferencial competitivo importante: o processamento de c\u00f3digo fonte \u2014 que muitas vezes cont\u00e9m informa\u00e7\u00f5es sens\u00edveis de neg\u00f3cio \u2014 permanece na jurisdi\u00e7\u00e3o correta.<\/p>\n

A manuten\u00e7\u00e3o programada agendada para 22 de junho de 2026, das 12:00 \u00e0s 13:00 UTC<\/strong>, afetar\u00e1 exclusivamente opera\u00e7\u00f5es de configura\u00e7\u00e3o \u2014 deploys, edi\u00e7\u00f5es no dashboard, chamadas de API que modificam configura\u00e7\u00e3o \u2014 por at\u00e9 3 minutos. Workers e Pages em execu\u00e7\u00e3o continuar\u00e3o operando normalmente. \u00c9 uma janela curta que n\u00e3o deve impactar tr\u00e1fego de produ\u00e7\u00e3o, mas times que planejam deploys cr\u00edticos nesse hor\u00e1rio devem agendar com anteced\u00eancia. Recomendamos configurar alertas via Cloudflare Notifications<\/strong> integrados com PagerDuty ou webhooks para receber atualiza\u00e7\u00f5es em tempo real.<\/p>\n

Comparativo de mercado: Workers vs outras plataformas de edge em 2026<\/h3>\n

Para contextualizar o significado desta Cloudflare Workers atualiza\u00e7\u00e3o<\/strong>, \u00e9 \u00fatil posicion\u00e1-la no cen\u00e1rio competitivo de edge computing em meados de 2026. O mercado se consolidou em tr\u00eas ofertas principais, cada uma com filosofias arquiteturais distintas:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n
Dimens\u00e3o<\/th>\nCloudflare Workers<\/th>\nAWS Lambda@Edge<\/th>\nFastly Compute@Edge<\/th>\n<\/tr>\n<\/thead>\n
Pontos de presen\u00e7a<\/td>\n275+ PoPs, anycast global<\/td>\n13 regi\u00f5es de edge (CloudFront)<\/td>\n~100 PoPs, WebAssembly focado<\/td>\n<\/tr>\n
Runtimes suportados<\/td>\nJavaScript, Python, WASM, C\/C++<\/td>\nNode.js, Python, Java, Go, .NET<\/td>\nWebAssembly (Rust, AssemblyScript, Go tiny)<\/td>\n<\/tr>\n
Cold start<\/td>\n< 1ms (V8 Isolates)<\/td>\n50\u2013100ms (Lambda + CloudFront)<\/td>\n< 1ms (WASM micro-VM)<\/td>\n<\/tr>\n
Object storage<\/td>\nR2 \u2014 zero egress fees<\/td>\nS3 \u2014 US$ 0,09\/GB egress<\/td>\nPr\u00f3prio (KV store, sem S3 compat)<\/td>\n<\/tr>\n
Banco de dados edge<\/td>\nD1 (SQLite), Durable Objects, KV, Vectorize<\/td>\nDynamoDB Global Tables, Aurora DSQL<\/td>\nKV Store, Simple Cache<\/td>\n<\/tr>\n
IA na edge<\/td>\nWorkers AI (Llama, Mistral, GLM-5.2, Whisper, Stable Diffusion)<\/td>\nBedrock (regional, n\u00e3o edge)<\/td>\nN\u00e3o dispon\u00edvel nativamente<\/td>\n<\/tr>\n
Agentes aut\u00f4nomos<\/td>\nAgents SDK (Browser, Codemode, Think)<\/strong><\/td>\nN\u00e3o dispon\u00edvel nativamente<\/td>\nN\u00e3o dispon\u00edvel<\/td>\n<\/tr>\n
VPC\/Private networking<\/td>\n\n

Sua empresa ainda n\u00e3o usa Cloudflare de forma estrat\u00e9gica?<\/p>\n

A JRT Technology Solutions implementa Cloudflare CDN, WAF, Zero Trust e Workers para empresas que precisam de performance, seguran\u00e7a e escalabilidade.<\/p>\n


\n <\/svg>
\n Falar com especialista
\n <\/a>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

Descubra as novidades da atualiza\u00e7\u00e3o do Cloudflare Workers: Agents SDK, VPC TCP e GLM-5.2. Clique e fique por dentro!<\/p>\n","protected":false},"author":1,"featured_media":1144,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":0,"footnotes":""},"categories":[1721],"tags":[1963,1962,1933,1966,1965,1964],"class_list":["post-1145","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cdn-cloudflare","tag-agents-sdk","tag-atualizacao-cloudflare","tag-cloudflare-workers","tag-desenvolvimento-em-nuvem","tag-glm-5-2","tag-vpc-tcp"],"_links":{"self":[{"href":"https:\/\/jrtx.com.br\/blog\/wp-json\/wp\/v2\/posts\/1145","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/jrtx.com.br\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/jrtx.com.br\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/jrtx.com.br\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/jrtx.com.br\/blog\/wp-json\/wp\/v2\/comments?post=1145"}],"version-history":[{"count":0,"href":"https:\/\/jrtx.com.br\/blog\/wp-json\/wp\/v2\/posts\/1145\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/jrtx.com.br\/blog\/wp-json\/wp\/v2\/media\/1144"}],"wp:attachment":[{"href":"https:\/\/jrtx.com.br\/blog\/wp-json\/wp\/v2\/media?parent=1145"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/jrtx.com.br\/blog\/wp-json\/wp\/v2\/categories?post=1145"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/jrtx.com.br\/blog\/wp-json\/wp\/v2\/tags?post=1145"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}