Cloudflare Workers Free vs Paid: bundle não exige mais upgrade

A comparação Cloudflare Workers Free vs Paid acaba de mudar: a Cloudflare eliminou o tamanho do bundle como motivo para contratar o plano pago. Em 4 de setembro de 2026, as antigas verificações de 3 MB compactados no Free e 10 MB no Paid deram lugar a um único limite de 64 MiB sem compactação nos dois planos. Agora, o orçamento de deploy segue a linha Total Upload do Wrangler, não mais o gzip.

Cloudflare Workers Free vs Paid: o que realmente mudou

O bundle de um Worker reúne o código e os módulos de apoio que a Cloudflare recebe no deploy. O Wrangler, ferramenta de linha de comando da Cloudflare, monta esse pacote com esbuild por padrão, inclui os pacotes npm importados pelo código e informa o tamanho final.

Até 4 de setembro, a Cloudflare compactava o bundle e rejeitava o envio quando o resultado ultrapassava 3 MB no Workers Free ou 10 MB no Workers Paid. Essa verificação do arquivo compactado não existe mais.

Agora, a plataforma verifica apenas se o bundle sem compactação tem no máximo 64 MiB. O limite é o mesmo para Free e Paid.

A última coluna resume toda a mudança. Total Upload mostra o tamanho sem compactação. O Wrangler ainda exibe gzip como referência, mas a Cloudflare não usa mais esse valor para aprovar ou barrar um deploy.

Não tente transformar a mudança em um multiplicador simples. Os limites antigos mediam bytes compactados em MB; o novo mede bytes sem compactação em MiB. O espaço adicional varia conforme a capacidade de compactação do JavaScript, das dependências e dos módulos binários de cada projeto.

A decisão sobre o plano de $5 mudou

O impacto imediato no orçamento é específico, mas importante. O Workers Paid tem cobrança mínima de $5 USD por conta a cada mês. Se a equipe cogitava o upgrade apenas porque o bundle ultrapassava o antigo teto de 3 MB do Free, esse motivo desapareceu — desde que o Total Upload permaneça dentro de 64 MiB.

Isso não torna os dois planos equivalentes. O Workers Free continua oferecendo 100,000 requisições por dia, 10 milissegundos de CPU por invocação e 50 subrequisições por invocação. Já o Workers Paid inclui 10 milhões de requisições e 30 milhões de milissegundos de CPU por mês, permite 10,000 subrequisições por invocação e pode executar até 5 minutos de CPU por requisição, com padrão de 30 segundos.

Com isso, a escolha fica mais objetiva. Faz sentido pagar por tráfego, CPU, subrequisições e recursos exclusivos do Paid. Não faz sentido pagar só porque um bundle fácil de compactar ficou acima de um limite do Free que já foi aposentado.

Equipes que já usam o Paid para cargas reais de produção não terão redução direta na fatura. Projetos que sempre ficaram com folga abaixo do limite antigo também não notarão diferença no fluxo de trabalho. O ganho se concentra em quem cortava dependências, dividia serviços ou fazia upgrade por causa do tamanho do deploy.

Para entender o restante das contas de plano e runtime, a análise completa da Cloudflare mostra como o Workers se encaixa nas demais cobranças por plano e uso. Os números antigos de limite do bundle são a parte substituída por esta mudança de setembro.

Quatro tipos de projeto que ficaram mais fáceis

Quem toca um SaaS sozinho pode separar a escolha do plano da escolha do framework

Imagine uma aplicação full stack publicada no Workers Free. Um adaptador de framework, o código de renderização no servidor e as dependências de produção podem gerar um bundle que, mesmo compactado, supera o antigo teto do Free — ainda que o tráfego da aplicação caiba nesse plano.

Agora, basta comparar o build com os 64 MiB de Total Upload. Se estiver dentro do limite, o tamanho do bundle, sozinho, não obriga a assumir o mínimo de $5 do Paid. A vantagem não é rodar produção de qualquer escala sem custo, e sim validar a demanda antes de pagar por um uso de runtime que ainda não existe.

Uma agência pode remover a regra errada do CI

É comum que a pessoa responsável pelos builds de uma agência tenha replicado o antigo limite de gzip em todos os repositórios de clientes. Manter essa verificação provoca falhas de build por uma regra que a Cloudflare já não aplica.

Troque-a por uma verificação do Total Upload sem compactação e defina um teto interno abaixo de 64 MiB para manter margem de segurança. Assim, os projetos falham por causa da restrição atual da plataforma, não de uma regra histórica.

Uma equipe de Rust ou WebAssembly ganha espaço, não um runtime novo

WebAssembly, geralmente abreviado como Wasm, permite que um Worker execute código binário compilado de linguagens como Rust, Go ou C. Segundo a Cloudflare, Workers em Wasm costumam ser maiores que equivalentes em JavaScript porque o binário frequentemente carrega dependências extras de runtime.

O limite maior de deploy abre mais espaço para o módulo Wasm e o código ao redor dele. O Wrangler aceita diretamente uploads .wasm e .wasm?module. Otimizar o tamanho continua sendo importante, e a Cloudflare recomenda o wasm-opt para reduzir o binário.

Uma equipe de plataforma pode aposentar soluções de contorno

Para ficar abaixo de 10 MB compactados, uma equipe de plataforma no Workers Paid talvez tenha dividido um serviço coeso, removido uma dependência útil ou criado uma rota própria para módulos externos. Vale reavaliar essas decisões.

Algumas divisões devem continuar porque estabelecem responsabilidades ou limites de falha claros. Mas, se a única razão era a antiga verificação de upload, essa arquitetura virou complexidade sem uma exigência da plataforma que a justifique.

Confira o bundle real antes do próximo deploy

Não estime pelo tamanho de node_modules, pela pasta de código-fonte nem pelo arquivo gerado em outra etapa de build do framework. Execute o dry deploy do Wrangler dentro do projeto do Worker para produzir exatamente o artefato que a Cloudflare receberia.

1. 1

   Faça o build sem publicar

   Execute o comando de dry run documentado pela Cloudflare:

   wrangler deploy --outdir bundled/ --dry-run

   O Wrangler gera o Worker e grava a saída localmente, sem fazer o deploy.

2. 2

   Leia o Total Upload

   Procure Total Upload na saída do comando. Esse é o tamanho do bundle sem compactação que a Cloudflare compara ao limite de 64 MiB. Use gzip como contexto de diagnóstico, se for útil, mas não como critério de aprovação ou reprovação da plataforma.

3. 3

   Atualize o orçamento no CI

   Substitua qualquer regra de 3 MB compactados no Free ou 10 MB no Paid por uma regra baseada em Total Upload. Defina o teto da equipe abaixo do máximo da plataforma para que a atualização de uma dependência não consuma toda a margem disponível.

4. 4

   Acompanhe a inicialização no deploy real

   No próximo deploy normal ou upload de versão, registre o valor de startup_time_ms exibido pelo Wrangler. Um bundle pode respeitar o limite de upload e, ainda assim, falhar na verificação separada de inicialização da Cloudflare.

O erro mais comum é acompanhar o valor menor de gzip, porque antes era ele que decidia o deploy. Isso mudou: agora, a linha que define o orçamento é Total Upload.

Os limites reais não ficaram 64 MiB maiores

Bundles maiores podem levar mais tempo para serem analisados e inicializados. Código que executa tarefas pesadas no escopo global, ou seja, fora do handler de requisições, ainda pode falhar na validação com Script startup exceeded CPU time limit e o código de erro 10021. Um deploy abaixo de 64 MiB passa pela barreira de tamanho; isso não garante uma inicialização saudável.

Esse ponto pesa sobretudo em frameworks pesados e em Wasm. Antes, o limite antigo muitas vezes interrompia o upload primeiro. O novo limite permite que mais código chegue à restrição seguinte, revelando problemas de memória e de inicialização.

Se um Worker continuar grande demais, a documentação atual aponta três saídas práticas:

• Remova pacotes e dependências que o caminho executado no deploy não utiliza.
• Mantenha configurações, arquivos estáticos e dados binários em Workers Static Assets, KV, R2 ou D1, fora do bundle do Worker.
• Divida as funcionalidades entre Workers usando Service Bindings.

Chamadas por Service Binding não geram uma segunda cobrança por requisição. A Cloudflare cobra a invocação do Worker inicial e o total de tempo de CPU consumido pelos Workers envolvidos. Isso torna a divisão uma alternativa viável para controlar o tamanho, desde que a nova fronteira entre serviços seja uma escolha consciente.

O que fazer na segunda-feira

Tome uma atitude nesta semana se algum Worker falhou recentemente na antiga verificação de tamanho, se a equipe cortou dependências do framework para permanecer abaixo do limite ou se o tamanho do bundle era o único argumento para fazer upgrade ao Paid. Rode o dry deploy, registre o Total Upload e reavalie a decisão.

Espere se o Worker já estava bem abaixo do limite anterior e o pipeline de deploy não contém uma barreira fixa baseada em gzip. Nada mudou no runtime da aplicação.

Continue no Paid se o volume de requisições, o tempo de CPU, as subrequisições ou outro recurso do plano justificarem a escolha. Um limite maior de upload no Free não é motivo para transferir uma carga de produção para um plano cujas cotas operacionais não atendem ao projeto.

A ação para segunda-feira é simples: troque a verificação de build de gzip para Total Upload e escolha o plano com base no uso, não no tamanho do bundle.

Receba a próxima mudança prática de plataforma pela newsletter.