Cloudflare Workers Free: os Worker Previews são grátis?

O Cloudflare Workers Free oferece Worker Previews sem custo? Sim: são 100 Previews por Worker e 100 deployments por Preview. Isso não torna ilimitados os testes em branches; execução dinâmica, minutos de build, armazenamento, inferência de IA e Containers continuam sujeitos a limites ou preços próprios.

Com o Cloudflare Worker Previews, cada branch do Git ganha um ambiente semelhante ao de produção dentro do mesmo Worker. A resposta útil não se resume a "$0". É esta: o objeto Preview está disponível no Free, mas a branch consome ou aciona os mesmos produtos da plataforma que já precisam entrar no orçamento.

Cloudflare Workers Free inclui Worker Previews grátis?

Sim, esse direito de uso é gratuito. Os limites atuais de Preview da Cloudflare permitem 100 Previews por Worker no plano Free, 500 nos planos pagos e 100 deployments dentro de cada Preview em qualquer um dos planos.

Essa resposta tem um limite claro. Preview é um objeto de ambiente, não um pacote de runtime, armazenamento, builds ou chamadas de modelo gratuitas. A página vigente de preços do Workers ainda oferece às contas Free 100,000 requisições dinâmicas de Worker por dia e um limite de CPU de 10 milissegundos por invocação. O Workers Paid continua custando a partir de $5 por conta por mês, com 10 milhões de requisições e 30 milhões de milissegundos de CPU mensais incluídos; depois disso, aplicam-se as tarifas de excedente publicadas.

A documentação vigente de Previews e preços foi verificada em 28 de setembro de 2026. Nenhuma das páginas publica uma tarifa específica para Preview, mas também não afirma que a execução em Preview seja ilimitada ou receba uma cota de uso separada. Por isso, o orçamento prudente é: direito gratuito a Previews, consumo sujeito aos medidores normais dos produtos.

O que mudou de fato em 22 de setembro de 2026

A Cloudflare lançou o Worker Previews em 22 de setembro de 2026 para dar a cada branch seu próprio ambiente em execução, com URL de Preview estável, configuração, observabilidade e estado. Ao executar npx wrangler preview, você cria ou atualiza o Preview associado à branch atual.

Na prática, o ciclo de validação fica mais curto. Um agente de programação pode fazer o deploy de uma branch, enviar requisições, examinar logs e traces, ajustar o código e atualizar a mesma URL compartilhável de Preview antes que qualquer mudança chegue à produção. Vários agentes ou engenheiros conseguem trabalhar em paralelo, sem disputar um único Worker compartilhado de staging.

Cada branch recebe dois tipos úteis de URL. A URL de Preview sempre acompanha o deployment mais recente da branch. Já a URL de Deployment permanece vinculada a um deployment específico, o que permite reproduzir um comentário de revisão ou uma comparação de regressão.

O isolamento é relevante. A Cloudflare cria automaticamente para cada Preview um namespace e um armazenamento próprios de Durable Objects. A plataforma também pode provisionar um aplicativo de container e instâncias separados. Variáveis, secrets e bindings podem ser diferentes dos de produção, enquanto logs e traces ficam restritos à branch.

Esse fluxo é mais robusto que o antigo modelo de Version URL, mas ainda não equivale a uma cópia completa da produção. Vários bindings e triggers continuam acessando sistemas compartilhados ou de produção. Essa limitação — e não a conveniência da URL de Preview — deve definir quanta autonomia você concede a um agente.

Plano Free do Worker Previews: o que está incluído

O plano Free comporta bem um fluxo normal de branches. Um Worker pode manter 100 ambientes Preview, e cada Preview pode reter 100 deployments. O Paid eleva a quantidade de ambientes para 500, mas não aumenta o histórico de deployments de cada Preview.

São dimensões distintas. Fazer deploy várias vezes na mesma branch ainda ocupa apenas uma vaga de Preview, enquanto o histórico de deployments cresce. Várias branches com um Preview ativo em cada uma ocupam várias vagas, mesmo que nenhuma receba tráfego.

A comparação entre o modelo antigo e o novo deixa a conta mais clara. Para espelhar cinco branches com ambientes do Wrangler, era preciso administrar cinco Workers separados. Com o Worker Previews, essas mesmas cinco branches ficam sob um Worker, como cinco objetos Preview. No Free, a ocupação da conta cai de 5% do limite de 100 Workers para 1% do limite de Workers, mais 5% da cota de Previews desse Worker. O preço-base documentado pode continuar em $0 nos dois arranjos quando o uso cabe nas cotas; o ganho está no isolamento mais simples e na redução da proliferação de ambientes, não em execução com desconto.

O Worker Previews exige Wrangler 4.135.0 ou posterior. A versão local do projeto é a que importa, pois os comandos do projeto não a substituem silenciosamente por uma instalação global mais recente. Em um repositório antigo, isso pode levar ao diagnóstico equivocado de que o recurso não está disponível.

O limite de configuração também exige atenção. Previews não herdam as definições de produção. A branch recebe o que estiver declarado no bloco previews, além dos recursos que a Cloudflare isola automaticamente. Um bloco vazio ou incompleto pode gerar um Preview cujo deploy funciona, mas que não consegue acessar o recurso esperado pelo código.

Limites do Cloudflare Preview: o que é excluído primeiro

A Cloudflare faz a limpeza automaticamente quando qualquer um dos limites de objetos é atingido. No nível do Worker, a plataforma exclui o Preview com o deployment menos recente. Dentro de um Preview, exclui o deployment mais antigo.

Assim, o 101º deployment no mesmo Preview é um evento de retenção: o deployment mais antigo sai para abrir espaço ao novo. Isso não significa que os primeiros 100 builds tenham sido gratuitos. O Workers Builds contabiliza minutos de build separadamente, tanto para builds de produção quanto para builds de Preview.

Para um agente que revisa uma branch muitas vezes, a URL estável de Preview continua valiosa porque sempre aponta para o deployment mais recente. O risco está no histórico forense. Se a equipe precisar reproduzir uma falha antiga, deve guardar a URL do deployment e os logs relevantes antes que aquele deployment se torne o item mais antigo.

A exclusão automática do objeto também não resolve toda a limpeza de recursos. Excluir um Preview remove seu registro de Preview e o namespace de Durable Objects, mas a Cloudflare alerta que um aplicativo de container gerado pode continuar visível. Um job de encerramento de branch deve excluir o Preview e, quando houver uso de Containers, verificar também os aplicativos de Container.

Preço do Cloudflare Worker Previews: quatro camadas de custo

A tabela de preços do Cloudflare Worker Previews não traz uma cobrança publicada por Preview. Na prática, a conta continua dividida em quatro camadas: execução do Worker, builds, recursos vinculados e produtos opcionais de computação ou modelos.

1. Execução do Worker

O Workers Free permite 100,000 requisições por conta por dia e limita cada invocação a 10 milissegundos de CPU. Requisições de assets estáticos são gratuitas e ilimitadas; a franquia de requisições vale para o tráfego que executa código no Worker. Por isso, um teste de branch que carrega apenas arquivos estáticos pode parecer barato, enquanto um teste intensivo de API consome a franquia dinâmica.

O Workers Paid começa em $5 por conta por mês. Ele inclui 10 milhões de requisições e 30 milhões de milissegundos de CPU mensais; depois, cobra $0.30 por milhão adicional de requisições e $0.02 por milhão adicional de milissegundos de CPU. No Paid, uma invocação HTTP tem limite-padrão de CPU de 30 segundos, configurável para até 5 minutos.

O limite de 10 milissegundos do Free costuma ser a primeira barreira. Um volume menor de requisições não compensa esse teto. Mesmo uma suíte que envia poucas requisições falha se uma única invocação dinâmica precisar, de forma consistente, de mais de 10 milissegundos de CPU.

Para avaliar a plataforma como um todo, a análise da Cloudflare separa o plano de conta do Workers de $5 dos planos de aplicação por domínio e dos demais medidores de produtos da Cloudflare.

2. Workers Builds

Os limites e preços do Workers Builds oferecem às contas Free 3,000 minutos de build por mês, um build simultâneo e timeout de 20 minutos. O Paid inclui 6,000 minutos e depois cobra $0.005 por minuto adicional, com seis builds simultâneos e o mesmo timeout. Branches criadas por agentes podem esgotar concorrência ou minutos mesmo quando a quantidade de objetos Preview continua baixa.

É por isso que “100 deployments por Preview” não pode ser interpretado como “100 builds incluídos”. O primeiro número mede o histórico de deployments retido. O outro é computação de CI.

3. Armazenamento e recursos vinculados

KV, D1, R2, Queues, Vectorize, Hyperdrive e outros bindings usam identificadores e medidores próprios. Dois Previews vinculados ao mesmo banco D1 ou bucket R2 compartilham esses dados. O isolamento exige um recurso separado, que ainda segue os preços do respectivo produto.

Em escala, o R2 inclui 10 GB-mês, 1 milhão de operações Class A e 10 milhões de operações Class B por mês. Além disso, o armazenamento Standard custa $0.015 por GB-mês, com Class A a $4.50 por milhão e Class B a $0.36 por milhão. O D1 Free inclui 5 milhões de linhas lidas e 100,000 linhas gravadas por dia, além de 5 GB de armazenamento total. A análise dos limites gratuitos do D1 mostra por que um banco de staging compartilhado pode se tornar um limite de disponibilidade mesmo quando ainda há objetos Preview disponíveis.

O KV tem outra franquia diária: 100,000 leituras, 1,000 gravações, 1,000 exclusões e 1,000 requisições de listagem no Free, com 1 GB armazenado. Um teste que popula ou limpa um namespace pode consumir essa cota muito mais rápido que um smoke test somente de leitura.

4. Inferência de IA e Containers

A tabela de preços do Workers AI oferece às contas Free e Paid 10,000 Neurons por dia sem cobrança. No Paid, o consumo acima dessa cota custa $0.011 por 1,000 Neurons. Portanto, um teste de branch que chama um modelo precisa orçar duas atividades: a requisição ao Worker e a inferência acionada por ela. A assinatura de um agente de programação externo ou a API de modelos de outro fornecedor gera uma cobrança à parte e não está incluída no direito de uso do Preview.

A tabela de preços de Containers não prevê franquia de Container no Free. O Workers Paid inclui 25 GiB-horas de memória, 375 minutos de vCPU e 200 GB-horas de disco por mês, além de tarifas próprias de excedente. O tráfego de Containers também usa Workers e Durable Objects; portanto, um container de Preview isolado automaticamente não depende de um único medidor.

Custo de Worker Previews para cinco branches ativas

Uma boa planilha começa pela carga de trabalho, não pelo nome do plano. Considere cinco branches ativas, cada uma recebendo 200 requisições de teste dinâmicas por dia. Isso soma 1,000 requisições diárias em cinco objetos Preview.

No Free, a quantidade de Previews é confortável e o tráfego modelado é pequeno. A conta mantém 99,000 requisições dinâmicas por dia somente se nada mais consumir a franquia. Tráfego de produção, outros Workers e os cinco ambientes de branch precisam entrar na mesma planilha operacional.

Aqui, é importante deixar claro o nível de evidência. A Cloudflare classifica 100,000 requisições diárias como um limite do plano da conta, e um Preview executa uma versão real do Worker. A documentação de Preview, porém, não declara explicitamente que o tráfego de Preview é debitado do mesmo medidor. Aplicar o medidor da conta às requisições de Preview é, portanto, uma premissa conservadora de orçamento até que uma observação de uso na conta ou uma declaração explícita da Cloudflare a confirme.

Nesta verificação, não havia credenciais de conta da Cloudflare, projeto de Worker nem instalação local do Wrangler disponíveis. Nenhum Preview descartável recebeu deploy, e nenhuma variação de uso foi coletada. A resposta sobre o direito de uso foi confirmada nas fontes; esta planilha é um modelo.

No Paid, essa carga de branches não gera excedente de requisições por si só, mas a conta ainda paga o mínimo mensal de $5. CPU e produtos vinculados podem mudar a conclusão. Com a mesma densidade de testes, todas as 100 vagas de Preview do Free gerariam 20,000 requisições por dia, ou 20% da franquia diária modelada. Todas as 500 vagas do Paid gerariam 3 milhões de requisições em um mês de 30 dias, equivalentes a 30% das requisições mensais incluídas. Nos dois exemplos controlados, o limite de objetos Preview chega antes da franquia de requisições. O tráfego de produção pode inverter essa ordem.

O que isso representa para quem desenvolve, opera e compra

Quem desenvolve ganha validação paralela em runtime, não segurança automática dos recursos

Quem desenvolve pode dar a cada branch ativa uma URL estável e um estado isolado de Durable Objects. Isso elimina a colisão de staging compartilhado em que o deploy de uma pessoa invalida a revisão de outra. Também oferece a um agente de programação um alvo concreto para curl, testes no navegador, logs e traces.

O limite está na configuração. D1, KV e R2 não se isolam só porque o código foi isolado. Se dois Previews usam o mesmo identificador, eles compartilham o recurso. O padrão seguro é um recurso exclusivo de não produção ou um recurso de staging compartilhado de forma intencional, com dados descartáveis.

A equipe de operações responde pelo orçamento compartilhado e pela limpeza

A equipe de operações deve acompanhar quatro números separadamente: objetos Preview ativos, deployments retidos por Preview, consumo dinâmico do Worker e uso dos produtos vinculados. Um único total no painel não consegue explicar os quatro.

O processo de limpeza deve fazer parte da automação do pull request. Exclua o Preview quando a branch for encerrada. Se houver uso de Containers, verifique o aplicativo de container que foi gerado. Guarde qualquer URL de deployment ou trace necessário para um incidente antes que a política de retenção o remova.

Só vale contratar o Paid quando houver um limite concreto

Não contrate o Paid só porque a palavra “Preview” parece premium. Faça o upgrade quando uma exigência identificada ultrapassar o Free: mais de 100 Previews simultâneos em um Worker, tráfego dinâmico somado ao de produção se aproximando de 100,000 requisições por dia, uma invocação que precise de mais de 10 milissegundos de CPU ou qualquer necessidade de Container.

O Paid também pode ser uma escolha racional de risco antes que o volume puro o exija. Uma equipe que atende clientes pode preferir uma franquia mensal com cobrança de excedente a um limite diário do Free, mesmo quando cinco testes de branch consomem apenas 1% da franquia diária modelada.

O que fazer de forma diferente

Aja agora se vários engenheiros ou agentes estiverem se revezando em um único Worker mutável de staging. Leve a validação de branches para Previews, defina uma política de recursos de não produção e inclua a limpeza no encerramento da branch dentro do CI. O lançamento elimina diretamente um gargalo de coordenação.

Espere se a aplicação depende de service bindings entre vários Workers, consumidores de Queue, Cron Triggers, rotas de produção ou Workflows isolados automaticamente. Hoje, esses caminhos não ficam totalmente contidos em um Preview. Ainda é possível testar a parte exposta por HTTP, mas o Preview não comprova o isolamento do sistema inteiro.

O impacto é pequeno se o projeto já tem um ambiente estável por branch em outro lugar ou se o Worker é estático e as mudanças são totalmente cobertas por verificações locais e de versão implantada. O novo objeto não gera valor apenas por existir.

A regra de decisão é simples: permaneça no Free enquanto a quantidade de objetos, a CPU por invocação, o tráfego modelado da conta e as necessidades de produtos couberem nos respectivos limites. Migre para o Paid quando qualquer uma dessas fronteiras se tornar relevante para a operação. A quantidade de requisições não é o único ponto de mudança.

Onde está o exagero

A mensagem do lançamento é mais precisa quando descreve um Worker da branch isolado. Ela se torna ampla demais se for entendida como uma cópia isolada de uma aplicação inteira na Cloudflare.

• Um service binding de um Preview chama o deployment de produção do outro Worker. Caminhos de requisição entre vários Workers não são automaticamente pareados branch a branch.
• Um binding de Workflow usa um Workflow já implantado. A Cloudflare não cria um Workflow específico para o Preview da branch.
• Um Preview pode enviar mensagens a uma Queue, mas não pode ser seu consumidor. Se ele apontar para uma Queue de produção, a produção poderá consumir as mensagens de teste.
• Cron Triggers e rotas de produção continuam direcionados à produção.
• KV, D1, R2 e vários outros recursos só ficam isolados quando você vincula um identificador de recurso diferente.
• As URLs de Preview são públicas por padrão. O formato workers.dev envia X-Robots-Tag: noindex, mas um Preview em domínio personalizado deve ser protegido com Cloudflare Access quando um trabalho ainda não lançado precisa permanecer privado.
• O suporte a Containers é parcial, e a exclusão pode deixar o aplicativo gerado visível até que ele seja limpo separadamente.

Para um agente, esses pontos não são casos extremos. Eles marcam a diferença entre “o agente pode testar a própria branch” e “o agente não consegue tocar na produção”. A matriz atual de isolamento de recursos deve ser tratada como um documento de autorização, não como leitura opcional de configuração.

O outro exagero é financeiro: 100 Previews no Free não representam 100 ambientes completos e gratuitos de staging. Significam que a Cloudflare permite a um Worker manter essa quantidade de objetos Preview. O orçamento depende dos recursos usados por trás deles.

Confira o direito de uso e depois siga o guia de configuração

A checagem do direito de uso exige apenas quatro perguntas:

1. A conta está no Workers Free ou no Paid?
2. Quantos Previews ativos esse Worker já tem?
3. Quanto a produção e os outros Workers já consomem do orçamento de requisições e CPU da conta?
4. O projeto fixa o Wrangler 4.135.0 ou posterior?

Se as respostas couberem nos limites, siga o guia oficial de configuração do Worker Previews para configurar e fazer o deploy. Mantenha a análise de custos separada: liste cada recurso vinculado, caminho de build, chamada de modelo e Container antes que um agente comece a gerar branches.

FAQ sobre Cloudflare Worker Previews

Posso usar Cloudflare Workers de graça?

Sim. O Workers Free custa $0, inclui 100,000 requisições dinâmicas de Worker por dia e aceita até 100 Previews por Worker. Cada invocação ainda tem limite de CPU de 10 milissegundos, e os produtos vinculados mantêm franquias próprias.

Quanto custa um Cloudflare Worker?

O Workers Free custa $0. O Workers Paid começa em $5 por conta por mês, inclui 10 milhões de requisições e 30 milhões de milissegundos de CPU e depois cobra as tarifas de excedente publicadas. Um Preview não tem preço-base separado publicado.

Quantos Cloudflare Workers posso usar de graça?

O Workers Free permite 100 Workers por conta. Esse limite é separado do Worker Previews, que permite 100 Previews dentro de cada Worker no Free.

Quanto custa o Cloudflare Workers AI?

O Workers AI inclui 10,000 Neurons por dia sem cobrança. No Workers Paid, o uso acima da cota diária custa $0.011 por 1,000 Neurons.

O Cloudflare Workers AI é gratuito?

O Workers AI oferece uma cota diária gratuita de 10,000 Neurons no Workers Free e no Workers Paid. As contas Free deixam de processar ao atingir a cota; as contas Paid podem continuar por $0.011 a cada 1,000 Neurons excedentes.

Qual é o maior concorrente da Cloudflare?

Não existe um único concorrente para todos os produtos de rede, segurança, computação, armazenamento e desenvolvimento da Cloudflare. Compare a camada específica que você pretende substituir, em vez de tratar a empresa inteira como um único produto.

Por que a Cloudflare está caindo?

A pergunta é ambígua e sensível ao tempo: pode se referir ao preço da ação, ao status do serviço, ao tráfego ou a outra métrica. Nenhuma dessas interpretações altera os limites do Worker Previews verificados na documentação vigente da Cloudflare em 28 de setembro de 2026.

A Cloudflare é uma empresa russa?

Não. A apresentação institucional da Cloudflare aponta San Francisco como sua sede e informa que a Cloudflare, Inc. é negociada publicamente na Bolsa de Valores de Nova York como NET.

Por que o FBI usa a Cloudflare?

Este artigo não comprova que o FBI use a Cloudflare e não faz afirmações sobre os fornecedores de uma agência. A pergunta não tem relação com o direito de uso e os limites documentados do Worker Previews.

O próximo passo

Comece com cinco branches, limite cada uma a 200 requisições dinâmicas de teste por dia e identifique as 1,000 requisições diárias resultantes como uma premissa de uso do medidor compartilhado no orçamento. Quando houver acesso ao faturamento, registre o uso de requisições da conta antes e depois do piloto. Se a variação confirmar o modelo, mantenha a planilha; se não, substitua a premissa pela observação.

Ao mesmo tempo, faça o inventário de cada binding no bloco previews. Classifique-o como isolamento automático, recurso dedicado de teste, compartilhado intencionalmente ou com acesso à produção. Não permita que um agente faça deploy até que cada linha com acesso à produção tenha uma justificativa explícita.

Quer transformar o próximo lançamento de infraestrutura em uma decisão de orçamento e operação? Assine a newsletter.