{"id":2929,"date":"2026-09-16T16:49:06","date_gmt":"2026-09-16T19:49:06","guid":{"rendered":"https:\/\/jrtx.com.br\/blog\/2026\/09\/16\/cloudflare-workers-atualizacao-acesso-granular-e-nodejs-64-m\/"},"modified":"2026-09-16T16:49:06","modified_gmt":"2026-09-16T19:49:06","slug":"cloudflare-workers-atualizacao-acesso-granular-e-nodejs-64-m","status":"publish","type":"post","link":"https:\/\/jrtx.com.br\/blog\/2026\/09\/16\/cloudflare-workers-atualizacao-acesso-granular-e-nodejs-64-m\/","title":{"rendered":"Cloudflare Workers atualiza\u00e7\u00e3o: acesso granular e Node.js 64 MiB"},"content":{"rendered":"

A Cloudflare Workers atualiza\u00e7\u00e3o<\/strong> mais recente muda o jogo para times de plataforma e desenvolvedores que operam na edge. A Cloudflare, Inc. (NYSE: NET) segue expandindo sua rede global \u2014 hoje presente em mais de 300 cidades<\/strong>, em mais de 100 pa\u00edses<\/strong>, processando aproximadamente 1 em cada 5 requisi\u00e7\u00f5es HTTP<\/strong> da internet. O AS13335 se consolidou como um dos maiores autonomous systems do mundo, e o Workers, carro-chefe da developer platform, recebe agora um pacote de mudan\u00e7as que vai desde controle de acesso granular por Worker<\/strong> at\u00e9 compatibilidade Node.js habilitada por padr\u00e3o<\/strong> com bin\u00e1rios de at\u00e9 64 MiB<\/strong>. Para o leitor brasileiro, isso significa menor lat\u00eancia a partir de data centers na Am\u00e9rica do Sul, integra\u00e7\u00e3o mais simples com stacks Python e JavaScript e um modelo de seguran\u00e7a mais refinado para pipelines de CI\/CD. Neste post t\u00e9cnico, voc\u00ea vai conhecer em detalhes cada mudan\u00e7a, o impacto pr\u00e1tico para administradores e desenvolvedores, os caminhos de migra\u00e7\u00e3o e como a JRT Technology Solutions<\/strong> recomenda implantar essas atualiza\u00e7\u00f5es em ambientes corporativos.<\/p>\n

O contexto de edge computing em 2026 n\u00e3o \u00e9 mais uma promessa: \u00e9 infraestrutura cr\u00edtica. Empresas que dependem de APIs de baixa lat\u00eancia, personaliza\u00e7\u00e3o em tempo real, prote\u00e7\u00e3o contra bots e distribui\u00e7\u00e3o global de conte\u00fado precisam de runtimes que executem c\u00f3digo o mais pr\u00f3ximo poss\u00edvel do usu\u00e1rio final. Enquanto provedores tradicionais como Akamai<\/strong> evolu\u00edram de CDN puro para edge compute com solu\u00e7\u00f5es como EdgeWorkers, e a AWS CloudFront<\/strong> aposta na integra\u00e7\u00e3o com Lambda@Edge e CloudFront Functions, o Cloudflare Workers<\/strong> se destaca por um modelo de precifica\u00e7\u00e3o baseado em requisi\u00e7\u00f5es, cold start inferior a 1 ms<\/strong> e presen\u00e7a em mais de 275 pontos de presen\u00e7a<\/strong>. A Fastly<\/strong>, por sua vez, oferece o Compute@Edge com VCL e WebAssembly, mas a Cloudflare amplia a vantagem ao unificar CDN, WAF, Zero Trust e storage na mesma plataforma. A atualiza\u00e7\u00e3o que destrinchamos aqui refor\u00e7a esse posicionamento.<\/p>\n

Historicamente, o Workers nasceu em 2017 como um runtime de JavaScript na edge e evoluiu para suportar WebAssembly, Python e, agora, compatibilidade Node.js mais profunda. O an\u00fancio mais recente, extra\u00eddo do Cloudflare Blog<\/strong> e dos Cloudflare changelogs<\/strong>, mostra que a empresa reconstruiu o module registry<\/strong> do Workers para compatibilidade com Node.js, habilitou Worker access scoped<\/strong> para pap\u00e9is de Developer Platform e liberou Hyperdrive para Python Workers<\/strong> conectando a PostgreSQL e MySQL. Al\u00e9m disso, os Workflows<\/strong> ganharam streaming de eventos via .subscribe()<\/code>, eliminando a necessidade de polling. H\u00e1 tamb\u00e9m mudan\u00e7as relevantes fora do escopo estrito do Workers: novos controles para disallow AI training<\/strong> mantendo indexa\u00e7\u00e3o em buscadores, pol\u00edticas autom\u00e1ticas de remedia\u00e7\u00e3o no CASB<\/strong> e novas detec\u00e7\u00f5es de WAF para SSRF e command injection.<\/p>\n

Para quem opera infraestrutura no Brasil, o timing \u00e9 relevante. A Cloudflare tem data centers em S\u00e3o Paulo<\/strong>, Rio de Janeiro<\/strong>, Porto Alegre<\/strong>, Curitiba<\/strong>, Fortaleza<\/strong> e outros pontos, o que reduz a lat\u00eancia para aplica\u00e7\u00f5es servidas a partir da edge. As manuten\u00e7\u00f5es programadas anunciadas para PER (Perth)<\/strong>, BNE (Brisbane)<\/strong>, KUL (Kuala Lumpur)<\/strong> e ADL (Adelaide)<\/strong> entre 22 e 23 de setembro de 2026 refor\u00e7am a import\u00e2ncia de entender como o tr\u00e1fego \u00e9 reroteado na rede global. A atualiza\u00e7\u00e3o do Workers tamb\u00e9m conversa com a LGPD<\/strong>: o controle fino de acesso e a possibilidade de impedir treinamento de IA em conte\u00fado p\u00fablico sem perder descoberta org\u00e2nica s\u00e3o ferramentas de governan\u00e7a de dados que times de seguran\u00e7a brasileiros j\u00e1 deveriam avaliar. Ao final deste artigo, voc\u00ea ter\u00e1 um mapa claro para adotar cada recurso e saber\u00e1 quando vale a pena acionar um parceiro de implementa\u00e7\u00e3o como a JRT Technology Solutions<\/strong>, que configura Cloudflare Workers, WAF, Zero Trust e CDN para clientes corporativos.<\/p>\n

O que h\u00e1 de novo na Cloudflare Workers atualiza\u00e7\u00e3o<\/h3>\n

A Cloudflare Workers atualiza\u00e7\u00e3o<\/strong> de setembro de 2026 vem carregada de an\u00fancios que, juntos, atendem a tr\u00eas dores cl\u00e1ssicas de times de engenharia: seguran\u00e7a de acesso<\/strong>, compatibilidade de runtime<\/strong> e observabilidade de workflows ass\u00edncronos<\/strong>. O primeiro grande destaque \u00e9 o scoped access para Workers individuais<\/strong>. Antes, as permiss\u00f5es de Developer Platform eram amplas e n\u00e3o permitiam granularidade fina por recurso. Agora \u00e9 poss\u00edvel atribuir pap\u00e9is mais restritos para que teammates, CI tokens<\/strong> e agentes automatizados recebam apenas o acesso necess\u00e1rio para depurar, implantar ou monitorar um Worker espec\u00edfico. Isso reduz a superf\u00edcie de ataque em ambientes com dezenas ou centenas de fun\u00e7\u00f5es edge.<\/p>\n

O segundo destaque \u00e9 a reconstru\u00e7\u00e3o do module registry<\/strong> do Workers para compatibilidade com Node.js. A Cloudflare habilitou a Node.js compatibility por padr\u00e3o<\/strong>, suportando aplica\u00e7\u00f5es de at\u00e9 64 mebibytes<\/strong> e introduzindo um URL-based module registry<\/strong> com import.meta<\/code>, lazy compilation<\/strong>, shared code caches<\/strong> e mensagens de erro mais claras. Na pr\u00e1tica, desenvolvedores que mant\u00eam bibliotecas Node.js legadas conseguem port\u00e1-las para a edge com muito menos atrito. O terceiro destaque \u00e9 o Hyperdrive support para Python Workers<\/strong>: fun\u00e7\u00f5es Python agora podem conectar-se a PostgreSQL<\/strong> e MySQL<\/strong> por meio do Hyperdrive, que faz pooling de conex\u00f5es e reduz a lat\u00eancia de banco de dados a partir da edge.<\/p>\n

O quarto an\u00fancio relevante \u00e9 o WorkflowInstance.subscribe()<\/strong>. Antes, acompanhar o progresso de um Workflow exigia polling constante do status da inst\u00e2ncia. Agora, Workers e clientes HTTP podem assinar um stream de eventos \u2014 incluindo attempts<\/strong>, sleeps<\/strong>, waits<\/strong> e rollbacks<\/strong> \u2014 reagindo em tempo real a cada mudan\u00e7a de estado. Uma assinatura primeiro transmite todo o hist\u00f3rico de eventos da inst\u00e2ncia e, em seguida, aguarda novos eventos conforme a execu\u00e7\u00e3o avan\u00e7a, com suporte a filtros<\/strong> e cursores<\/strong>. Isso \u00e9 especialmente \u00fatil para dashboards user-facing, notifica\u00e7\u00f5es de conclus\u00e3o de etapas e disparo de trabalhos subsequentes.<\/p>\n

Fora do Workers, mas igualmente importante para o ecossistema, a Cloudflare lan\u00e7ou controles para que donos de sites permane\u00e7am descobertos em buscadores<\/strong> enquanto bloqueiam o uso de conte\u00fado para treinamento de IA. A designa\u00e7\u00e3o Accountable<\/strong> estabelece um modelo compartilhado com Apple<\/strong>, Google<\/strong> e Microsoft<\/strong>, criando um padr\u00e3o de sinaliza\u00e7\u00e3o que respeita a vontade do publisher. O CASB<\/strong> ganhou pol\u00edticas de remedia\u00e7\u00e3o autom\u00e1tica<\/strong> constru\u00eddas diretamente sobre a developer platform, permitindo revogar compartilhamentos arriscados de arquivos SaaS e enviar webhooks sem interven\u00e7\u00e3o manual. E o WAF<\/strong> recebeu novas detec\u00e7\u00f5es de SSRF<\/strong> (incluindo payloads de loopback HTTP com jar), command injection<\/strong> e information disclosure em hist\u00f3rico de version control<\/strong>, com libera\u00e7\u00e3o inicial em modo Log<\/strong> e posterior transi\u00e7\u00e3o para Block<\/strong>.<\/p>\n

Tabela de mudan\u00e7as da Cloudflare Workers atualiza\u00e7\u00e3o<\/h3>\n

Para organizar o que muda, preparamos uma tabela de changelog com os recursos mais impactantes. Cada linha compara o comportamento anterior com o novo e descreve o impacto pr\u00e1tico para operadores e desenvolvedores. Note que nem todas as mudan\u00e7as s\u00e3o breaking changes<\/em>; a maioria \u00e9 aditiva, mas o acesso granular exige revis\u00e3o de pol\u00edticas de IAM existentes.<\/p>\n\n\n\n\n\n\n\n\n\n\n
Recurso<\/th>\nAntes<\/th>\nDepois<\/th>\nImpacto<\/th>\n<\/tr>\n<\/thead>\n
Developer Platform roles<\/td>\nPap\u00e9is amplos, sem escopo por Worker individual<\/td>\nAcesso escopado a Workers individuais e pap\u00e9is mais restritos para teammates, CI tokens e agentes<\/td>\nMenor superf\u00edcie de ataque; conformidade com princ\u00edpio do menor privil\u00e9gio; pipeline de deploy mais seguro<\/td>\n<\/tr>\n
Node.js compatibility<\/td>\nOpt-in, com limita\u00e7\u00f5es de tamanho e resolu\u00e7\u00e3o de m\u00f3dulos<\/td>\nCompatibilidade por padr\u00e3o, aplica\u00e7\u00f5es de at\u00e9 64 MiB, URL-based module registry com import.meta, lazy compilation e shared code caches<\/td>\nPortabilidade de bibliotecas Node.js para a edge; builds maiores; erros mais claros; menor duplica\u00e7\u00e3o de c\u00f3digo<\/td>\n<\/tr>\n
Hyperdrive para Python<\/td>\nIndispon\u00edvel para Python Workers<\/td>\nPython Workers conectam a PostgreSQL e MySQL via Hyperdrive<\/td>\nAcelera\u00e7\u00e3o de acesso a dados relacionais a partir da edge; redu\u00e7\u00e3o de lat\u00eancia para APIs Python<\/td>\n<\/tr>\n
Workflows .subscribe()<\/td>\nPolling de status da inst\u00e2ncia para acompanhar execu\u00e7\u00e3o<\/td>\nStreaming de eventos via WorkflowInstance.subscribe() e endpoint GET \/subscribe, com filtros e cursores<\/td>\nObservabilidade em tempo real; rea\u00e7\u00e3o imediata a tentativas, sleeps, waits e rollbacks; menos chamadas de rede<\/td>\n<\/tr>\n
AI training controls<\/td>\nSem padr\u00e3o claro para bloquear treinamento de IA sem perder SEO<\/td>\nNovos controles e designa\u00e7\u00e3o Accountable com Apple, Google e Microsoft<\/td>\nGovernan\u00e7a de conte\u00fado; prote\u00e7\u00e3o de propriedade intelectual; manuten\u00e7\u00e3o de descoberta org\u00e2nica<\/td>\n<\/tr>\n
WAF Managed Rules<\/td>\nCobertura limitada para SSRF cloud, command injection e vazamento em version control<\/td>\nNovas detec\u00e7\u00f5es: SSRF – Cloud 3, Version Control – Information Disclosure – Beta, Command Injection – Generic 10, entre outras<\/td>\nProte\u00e7\u00e3o proativa contra explora\u00e7\u00e3o de metadata de nuvem, inje\u00e7\u00e3o de comandos e exposi\u00e7\u00e3o de dados sens\u00edveis<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

A tabela acima resume o n\u00facleo da atualiza\u00e7\u00e3o, mas h\u00e1 nuances importantes. Os novos pap\u00e9is de Developer Platform n\u00e3o s\u00e3o retroativos: contas que hoje possuem permiss\u00f5es amplas continuar\u00e3o funcionando at\u00e9 que voc\u00ea revise e aplique os pap\u00e9is restritos. O Node.js compatibility<\/strong> por padr\u00e3o \u00e9 uma mudan\u00e7a de comportamento, mas a Cloudflare projetou o novo module registry para ser backward compatible<\/em> com a maioria dos projetos existentes \u2014 vale testar em staging antes de subir para produ\u00e7\u00e3o. No caso do Hyperdrive para Python, as limita\u00e7\u00f5es de setup e exemplos de c\u00f3digo est\u00e3o documentados em Use Hyperdrive from Python Workers<\/strong>, e recomendamos que equipes que j\u00e1 usam D1<\/strong> ou Durable Objects<\/strong> avaliem o impacto de adicionar conex\u00f5es relacionais edge-to-cloud.<\/p>\n

Node.js compatibility e o module registry de 64 MiB<\/h3>\n

A Cloudflare Workers atualiza\u00e7\u00e3o<\/strong> do module registry \u00e9 provavelmente a mudan\u00e7a mais estrutural para desenvolvedores JavaScript. O Workers sempre teve um modelo de m\u00f3dulos pr\u00f3prio, inspirado em Web Workers, mas isso criava fric\u00e7\u00e3o para quem vinha do ecossistema Node.js. Com o novo URL-based module registry<\/strong>, os imports s\u00e3o resolvidos de forma mais pr\u00f3xima ao comportamento do Node, incluindo suporte a import.meta<\/code>. Isso significa que padr\u00f5es como import.meta.url<\/code> e resolu\u00e7\u00e3o de caminhos relativos funcionam de maneira mais previs\u00edvel, reduzindo a necessidade de shims e bundlers customizados.<\/p>\n

O aumento do tamanho m\u00e1ximo de aplica\u00e7\u00e3o para 64 MiB<\/strong> merece aten\u00e7\u00e3o. Antes, o limite mais restrito obrigava equipes a quebrar fun\u00e7\u00f5es em m\u00faltiplos Workers ou a usar t\u00e9cnicas agressivas de tree shaking. Agora, aplica\u00e7\u00f5es monol\u00edticas moderadas podem ser empacotadas em um \u00fanico deploy, o que simplifica a opera\u00e7\u00e3o de fun\u00e7\u00f5es edge maiores, como APIs de back-office, processamento de webhooks e integra\u00e7\u00f5es com gateways de pagamento. O limite de 64 MiB \u00e9 especialmente \u00fatil para projetos que dependem de bibliotecas nativas compiladas para WebAssembly ou de SDKs corporativos volumosos.<\/p>\n

Outros dois componentes t\u00e9cnicos do novo registry merecem destaque: lazy compilation<\/strong> e shared code caches<\/strong>. A lazy compilation adia a compila\u00e7\u00e3o de m\u00f3dulos at\u00e9 que eles sejam efetivamente importados por uma requisi\u00e7\u00e3o, o que reduz o tempo de inicializa\u00e7\u00e3o a frio em aplica\u00e7\u00f5es com muitos pontos de entrada. O shared code caches<\/strong> permite que trechos de c\u00f3digo id\u00eanticos entre aplica\u00e7\u00f5es diferentes sejam compilados e armazenados uma \u00fanica vez, diminuindo o uso de mem\u00f3ria e acelerando cold starts em contas com dezenas de Workers. Por fim, as mensagens de erro mais claras do module registry ajudam a depurar incompatibilidades de vers\u00e3o, imports circulares e m\u00f3dulos n\u00e3o encontrados, um ganho de produtividade imediato para times que operam com CI\/CD avan\u00e7ado.<\/p>\n

Do ponto de vista de migra\u00e7\u00e3o, a Cloudflare recomenda testar projetos existentes com a compatibilidade Node.js habilitada por padr\u00e3o. Em nossa experi\u00eancia na JRT Technology Solutions<\/strong>, configuramos ambientes de staging com Wrangler<\/strong> e vari\u00e1veis de ambiente para validar imports legados antes de qualquer promo\u00e7\u00e3o. O novo limite de 64 MiB n\u00e3o \u00e9 um convite para abandonar boas pr\u00e1ticas de modulariza\u00e7\u00e3o; pelo contr\u00e1rio, a observabilidade de m\u00e9tricas de CPU e mem\u00f3ria no dashboard do Workers continua essencial para evitar timeouts<\/em> e custos inesperados. Para quem usa Pages<\/strong> com SSR em Next.js ou SvelteKit, a integra\u00e7\u00e3o com o novo registry tamb\u00e9m melhora o build serverless de fun\u00e7\u00f5es edge, especialmente em rotas din\u00e2micas que dependem de APIs externas.<\/p>\n

Workflows com .subscribe(): streaming de eventos na edge<\/h3>\n

Os Workflows<\/strong> do Cloudflare Workers s\u00e3o a ferramenta nativa para orquestrar tarefas ass\u00edncronas e de longa dura\u00e7\u00e3o na edge, como processamento de pedidos, pipelines de ETL leve e sincroniza\u00e7\u00e3o de dados entre sistemas. Antes desta atualiza\u00e7\u00e3o, acompanhar o estado de uma inst\u00e2ncia exigia chamadas repetidas de polling<\/em>, o que gerava lat\u00eancia extra, custos de requisi\u00e7\u00e3o e complexidade de c\u00f3digo. O novo WorkflowInstance.subscribe()<\/code> resolve isso com um stream de eventos<\/strong> que combina hist\u00f3rico retrospectivo e eventos em tempo real em uma \u00fanica conex\u00e3o.<\/p>\n

O comportamento \u00e9 elegante: ao chamar .subscribe()<\/code>, a assinatura primeiro transmite todo o hist\u00f3rico de eventos<\/strong> da inst\u00e2ncia \u2014 para que nenhum evento seja perdido \u2014 e, em seguida, aguarda novos eventos conforme a execu\u00e7\u00e3o avan\u00e7a. Os tipos de evento incluem attempts<\/strong> (tentativas de execu\u00e7\u00e3o), sleeps<\/strong> (pausas programadas), waits<\/strong> (esperas por condi\u00e7\u00f5es externas) e rollbacks<\/strong> (revers\u00f5es de etapas). \u00c9 poss\u00edvel usar filter<\/code> para receber apenas tipos espec\u00edficos ou cursor<\/code> para iniciar a assinatura em um evento determinado, \u00fatil quando um cliente se reconecta ap\u00f3s uma queda de rede.<\/p>\n

Segue um exemplo de uso direto em um Worker, baseado na documenta\u00e7\u00e3o oficial:<\/p>\n

const instance = await env.MY_WORKFLOW.get(\"report-123\");\n\nusing subscription = await instance.subscribe();\n\nwhile (true) {\n  const { value, done } = await subscription.next();\n  if (done) {\n    break;\n  }\n\n  console.log(value.type, value);\n}<\/code><\/pre>\n
O mesmo padr\u00e3o pode ser consumido via endpoint GET \/subscribe<\/strong>, permitindo que clientes HTTP externos \u2014 n\u00e3o apenas Workers \u2014 reajam a eventos do Workflow. Isso abre portas para integra\u00e7\u00f5es com sistemas legados, webhooks de notifica\u00e7\u00e3o e dashboards operacionais. Na pr\u00e1tica, um time de opera\u00e7\u00f5es pode atualizar o status de um pedido em um portal do cliente no momento exato em que um step do Workflow \u00e9 conclu\u00eddo, sem depender de cron jobs de polling. A possibilidade de filtrar por tipo de evento reduz o volume de dados transmitidos e o processamento desnecess\u00e1rio no cliente.<\/p>\n
Para quem j\u00e1 opera Workflows em produ\u00e7\u00e3o, a migra\u00e7\u00e3o \u00e9 direta: o m\u00e9todo .subscribe()<\/code> convive com as APIs existentes de consulta de status, ent\u00e3o voc\u00ea pode adotar o streaming incrementalmente. A JRT Technology Solutions<\/strong> recomenda usar .subscribe()<\/code> em cen\u00e1rios de alta interatividade, como rastreamento de pedidos, filas de processamento e sincroniza\u00e7\u00e3o de dados entre microsservi\u00e7os. Em conjunto com Queues<\/strong> e Durable Objects<\/strong>, os Workflows agora oferecem uma base mais s\u00f3lida<\/p>\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":"
A Cloudflare Workers atualiza\u00e7\u00e3o mais recente muda o jogo para times de plataforma e desenvolvedores que operam na edge. A Cloudflare, Inc. (NYSE: NET) segue expandindo sua rede global \u2014 hoje presente em mais de 300 cidades, em mais de 100 pa\u00edses, processando aproximadamente 1 em cada 5 requisi\u00e7\u00f5es HTTP da internet. O AS13335 se … Ler mais<\/a><\/p>\n","protected":false},"author":1,"featured_media":2928,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"iawp_total_views":0,"footnotes":""},"categories":[1721],"tags":[3466],"class_list":["post-2929","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cdn-cloudflare","tag-cloudflare-workers-product-update"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t