A Cloudflare criou o Workers para executar JavaScript na borda e o Pages para publicar sites estáticos. Hoje, os dois caminhos se sobrepõem: Workers também serve arquivos estáticos, enquanto Pages ganhou funções. A escolha ficou menos óbvia justamente quando a plataforma começou a apontar para um deles.
Para um projeto novo, a Cloudflare recomenda Workers Static Assets. Pages continua funcionando, e um projeto existente não precisa migrar às pressas. Compare suas funções, o fluxo de deploy e as integrações antes de decidir.
Duas propostas que acabaram se cruzando
O Workers apareceu em 2017 para executar JavaScript na rede da Cloudflare. Em 2020, Pages chegou com foco em hospedar sites estáticos. Depois, Pages ganhou Functions e recursos para aplicações dinâmicas. Workers também passou a servir arquivos estáticos, e as duas plataformas começaram a cobrir trabalhos parecidos.
A mudança mais relevante para quem está escolhendo hoje é a direção do produto. A documentação atual da Cloudflare descreve Workers como sua plataforma principal para criar aplicações e recomenda Workers Static Assets para projetos novos. Pages continua disponível e funcional; a Cloudflare concentra novos recursos e otimizações em Workers.
Workers também pode hospedar um site estático
Ao criar uma aplicação Workers, você pode começar com um modelo, conectar um repositório ou enviar arquivos estáticos. Esses arquivos podem ser publicados junto do Worker. A aplicação também pode se conectar a serviços como D1 e R2, domínios, outros Workers e tarefas agendadas.
Na minha demonstração, o painel ainda mostra a opção de continuar pelo fluxo legado de Pages. O nome permanece porque há projetos e usuários que dependem dele. Para um site estático simples, Workers Static Assets pode servir os arquivos sem executar código de Worker em cada requisição. Para uma aplicação completa, você pode combinar assets e lógica no mesmo projeto.
A documentação de Workers Static Assets descreve como os arquivos são publicados e como o Worker pode processar rotas específicas.
O custo depende de assets e funções
Eu costumava pensar no Pages quando queria evitar cobrança por requisição de arquivos estáticos. A documentação atual informa que requisições para assets estáticos são gratuitas e ilimitadas tanto em Pages quanto em Workers. Quando uma requisição executa código dinâmico, as invocações de Pages Functions são cobradas segundo o modelo de Workers.
Por isso, escolher Pages apenas pela ideia de que ele sempre custa menos pode levar a uma decisão desatualizada. Confira a sua configuração: uma rota pode chamar uma Function ou Worker, e isso altera como a requisição é contabilizada. A página oficial de preços de Pages Functions explica essa diferença.
O que muda no trabalho diário
O painel atual permite criar projetos por diferentes caminhos, mas o fluxo antigo de Pages continua mais ligado à integração GitHub ou GitLab e ao envio de arquivos estáticos. Workers oferece modelos para aplicações e configuração pelo Wrangler. Há recursos como Cron Triggers, Durable Objects, ambientes e opções de observabilidade que se integram de forma mais direta ao ambiente Workers.
No vídeo, eu também mostro a publicação gradual de versões para liberar uma mudança a parte do tráfego antes de ampliar a distribuição. Pages oferece ambientes de produção e preview, que seguem úteis para validar alterações antes de publicar. Confira cada recurso no painel e na documentação do plano que você usa, porque os detalhes mudam com o tempo.
Uma diferença prática que vale conferir antes de começar: na experiência que mostrei, um projeto Pages criado com integração Git não podia ser convertido para upload direto pelo mesmo caminho. No Workers, eu pude remover a conexão Git e publicar a partir do projeto local. Confirme as opções disponíveis na sua conta antes de escolher um fluxo que você queira trocar depois.
Quando manter um projeto Pages
Se o Pages atual atende ao projeto e o deploy funciona, não há necessidade de parar tudo para migrar. A migração pode ser simples em alguns casos, mas precisa considerar rotas, Functions, variáveis, domínio, pipeline e comportamento dos assets. A Cloudflare mantém um guia de migração de Pages para Workers com os pontos que precisam de ajuste.
Para um projeto novo, eu escolheria Workers. Para um site já publicado em Pages, eu compararia o ganho de ter os recursos mais recentes com o custo de adaptar e validar o deploy. A decisão fica mais clara quando você olha para o que o projeto realmente usa, e não apenas para o nome do produto.
O que conferir
- Liste quais rotas servem assets e quais executam Functions.
- Confira limites e cobrança no plano atual.
- Revise Git, previews, variáveis e domínios antes de migrar.
O que pode dar errado
Migrar um site em produção sem testar as rotas e os bindings.
Assumir que todas as requisições têm o mesmo tratamento de cobrança.
Confundir a continuidade do Pages com a direção recomendada para projetos novos.
Perguntas frequentes
Cloudflare Pages foi encerrado?
Não. Pages continua funcionando. A Cloudflare recomenda Workers para projetos novos e concentra ali os novos recursos e otimizações.
Workers cobra por requisições a arquivos estáticos?
A documentação informa que requisições a assets estáticos são gratuitas e ilimitadas. Requisições que executam código dinâmico seguem a cobrança aplicável a Workers.
Preciso migrar meu projeto Pages agora?
Não necessariamente. Avalie as funções usadas, o deploy e os recursos que você quer adotar. Migre quando o benefício justificar revisar e testar o projeto.
