Cloudflare Workers: o que é, como funciona e quando usar na edge

A maioria dos sites e APIs ainda funciona no modelo clássico: uma requisição chega, percorre a rede até um servidor centralizado, esse servidor processa e devolve a resposta. Funciona. Mas o custo de latência é real, especialmente quando o usuário está longe do servidor.

Cloudflare Workers resolve isso de outro jeito. O código não fica em um ponto central, ele fica distribuído em mais de 300 pontos de presença ao redor do mundo e executa no local mais próximo de quem fez a requisição.

Este artigo explica como o Cloudflare Workers funciona na prática, quais são os casos de uso reais, o que ele não é, e como comparar com alternativas antes de adotar.

O que é Cloudflare Workers

Cloudflare Workers é uma plataforma serverless de execução de código que roda na rede global da Cloudflare. Em vez de provisionar um servidor ou container, você escreve uma função JavaScript e faz o deploy direto na infraestrutura deles.

A função responde a eventos, principalmente requisições HTTP. Quando um usuário acessa uma URL configurada, o Worker intercepta e processa a requisição antes, durante ou depois de ela chegar à origem.

O modelo é serverless não só no sentido de “sem servidor para gerenciar”, mas no sentido real: você não paga por tempo ocioso, não precisa configurar escalabilidade manualmente, e o código sobe em milissegundos porque não há processo de inicialização tradicional.

Para entender o contexto mais amplo, vale ver o que é serverless como conceito e como ele se diferencia da hospedagem tradicional.

Como o Cloudflare Workers funciona

O runtime é diferente do Node.js

O Workers usa o motor JavaScript V8, o mesmo do Chrome e do Node.js, mas o ambiente de execução é próprio da Cloudflare. Não é um processo Node.js completo.

Isso significa que algumas APIs do Node não estão disponíveis por padrão. A Cloudflare oferece compatibilidade parcial via flag nodejs_compat, mas é preciso verificar se o pacote específico que você quer usar tem suporte antes de assumir que funciona.

O que está disponível nativamente são as APIs web padrão: Request, Response, fetch, Streams, Web Crypto e URL. Quem já trabalha com APIs do navegador vai reconhecer a maioria.

Isolates em vez de containers

O modelo de isolamento do Workers é diferente de funções Lambda ou containers Docker. Em vez de iniciar um processo ou container por requisição, a Cloudflare usa isolates do V8.

Um isolate é um contexto de execução leve e isolado de memória. O mesmo processo do runtime pode hospedar milhares de isolates ao mesmo tempo, o que elimina o cold start que afeta outras plataformas serverless.

Na prática: a primeira execução de um Worker em um ponto de presença pode levar alguns milissegundos. As seguintes praticamente não têm latência de inicialização.

A sintaxe atual é Module Workers

A documentação antiga mostrava addEventListener. Isso ainda funciona, mas a Cloudflare marcou essa sintaxe como deprecated. Projetos novos devem usar Module Workers com ES modules:

export default {
  async fetch(request, env, ctx) {
    const url = new URL(request.url);

    if (url.pathname === "/api/status") {
      return Response.json({ ok: true });
    }

    return new Response("Not found", { status: 404 });
  },
};

O handler fetch recebe três argumentos: request com os dados da requisição HTTP, env expondo variáveis de ambiente, secrets e bindings configurados no projeto, e ctx com acesso a métodos de ciclo de vida, como waitUntil para tarefas que podem terminar depois que a resposta já foi enviada.

CPU time não é o mesmo que duração da requisição

Um ponto importante para quem dimensiona custos: o Workers cobra por CPU time, não pela duração total da requisição.

Se o Worker faz uma chamada externa com fetch e aguarda a resposta, o tempo de espera não é cobrado. Apenas o tempo em que o código está de fato executando conta.

No plano gratuito, o limite é 10ms de CPU por requisição HTTP. No plano pago, 30ms, com possibilidade de aumentar. Para Workers com processamento mais intenso, esse é o número que precisa de atenção.

Para que serve na prática

Manipulação de requisições e respostas

O caso de uso mais direto: interceptar uma requisição, modificar headers, aplicar redirecionamentos, injetar conteúdo ou bloquear acesso antes de chegar à origem.

export default {
  async fetch(request, env) {
    const response = await fetch(request);
    const newResponse = new Response(response.body, response);

    newResponse.headers.set("X-Frame-Options", "DENY");
    newResponse.headers.set("X-Content-Type-Options", "nosniff");

    return newResponse;
  },
};

Esse padrão resolve casos como adicionar headers de segurança em sites que não permitem configuração direta no servidor, ou forçar redirecionamentos sem precisar alterar o código da aplicação.

APIs e endpoints leves

Workers funciona bem para APIs que não precisam de processamento pesado: validações, transformações de dados, proxies para serviços externos, webhooks.

A vantagem sobre uma função Lambda ou uma API em servidor tradicional é a latência. A resposta vem do ponto de presença mais próximo do usuário, não de us-east-1 ou de um datacenter fixo.

Autenticação na borda

Em vez de deixar requisições não autenticadas chegarem à origem, o Worker verifica o token antes de repassar. Isso reduz carga no servidor e bloqueia requisições inválidas mais cedo na cadeia.

A/B testing e personalização

Redirecionar um percentual do tráfego para variantes diferentes sem alterar o código da aplicação. O Worker decide qual versão servir com base em cookie, localização geográfica ou qualquer lógica customizada.

Sites estáticos com lógica dinâmica na borda

Esse caso interessa diretamente a quem trabalha com performance web: servir páginas estáticas via CDN enquanto o Worker adiciona comportamento dinâmico sem envolver o servidor. O resultado são Core Web Vitals melhores pelo TTFB reduzido das páginas estáticas, sem abrir mão de personalização.

Cloudflare Workers vs alternativas

Workers vs AWS Lambda

Lambda é mais maduro, tem ecossistema maior e suporte completo ao Node.js. Mas tem cold start considerável, exige configuração de VPC, IAM e API Gateway para expor endpoints HTTP, e o código roda em regiões fixas.

Workers tem cold start mínimo, configuração mais simples e latência menor para usuários distribuídos geograficamente. Para APIs públicas com audiência global, Workers leva vantagem na latência. Para lógica de negócio complexa com integrações extensas ao ecossistema AWS, Lambda faz mais sentido.

Workers vs Vercel Edge Functions

Vercel Edge Functions são baseadas no mesmo runtime do Workers, então a comparação técnica é próxima. A diferença está no ecossistema: Vercel é mais integrado com Next.js e tem deploy automático por git. Workers é mais flexível e desacoplado de framework específico.

Se o projeto já está no Vercel com Next.js, Edge Functions é a escolha natural. Se a plataforma é outra ou o projeto não usa React, Workers oferece mais controle.

Workers vs solução no próprio servidor

Para quem tem um VPS ou servidor dedicado, um middleware na aplicação resolve o mesmo problema, mas com latência maior para usuários distantes e dependência do uptime do servidor.

Workers faz sentido quando latência global importa, quando a lógica é simples o suficiente para rodar sem o servidor ou quando o objetivo é reduzir carga na origem.

Estado e armazenamento no Workers

Variáveis globais em Workers não são confiáveis para dados de usuário. O isolate pode ser removido, reiniciado ou executado em um ponto de presença diferente. Nunca use variável global para armazenar estado entre requisições.

Para dados persistentes, a Cloudflare oferece serviços integráveis via bindings:

Workers KV para chave-valor com consistência eventual. Bom para configurações e dados lidos com frequência que não precisam de consistência em tempo real.

R2 para armazenamento de objetos grandes, compatível com a API do S3. Ideal para arquivos, imagens e assets.

D1 para banco de dados SQLite na edge. Permite queries SQL direto do Worker.

Durable Objects para estado consistente e coordenação entre requisições. O caso de uso mais comum é gerenciamento de sessão ou aplicações colaborativas em tempo real.

Como criar o primeiro Worker

A ferramenta oficial é o Wrangler, CLI da Cloudflare. O C3 (Create Cloudflare CLI) gera a estrutura inicial:

npm create cloudflare@latest -- meu-worker

Para desenvolver localmente:

cd meu-worker
npx wrangler dev

O Wrangler sobe um servidor em localhost:8787 com hot reload. Você testa o Worker antes de qualquer deploy.

Para publicar:

npx wrangler deploy

O projeto recebe um endereço *.workers.dev. Para usar um domínio próprio, configure a rota no painel da Cloudflare ou no wrangler.jsonc.

O arquivo wrangler.jsonc controla a configuração do projeto, incluindo compatibility_date, que fixa o comportamento do runtime. A Cloudflare recomenda usar a data atual em projetos novos e atualizar com testes para adotar mudanças futuras.

Limites do plano gratuito e pago

Os valores abaixo refletem o estado atual da plataforma. Como a Cloudflare atualiza os planos com frequência, sempre verifique a página oficial de limites antes de planejar arquitetura.

Plano gratuito: 100 mil requisições por dia, 10ms de CPU por requisição HTTP, 128MB de memória e bundle comprimido de até 3MB.

Plano Workers Paid: sem limite de requisições incluídas (cobrança por excedente), 30ms de CPU por requisição HTTP, com possibilidade de aumentar para casos específicos.

Vale entender a diferença entre CPU time e wall time. Uma requisição que aguarda uma chamada externa por 500ms pode consumir apenas 5ms de CPU. O limite que importa para dimensionamento é o CPU time, não a duração total.

O que considerar antes de adotar

Compatibilidade de pacotes. Se o projeto depende de pacotes npm que usam APIs específicas do Node indisponíveis no runtime do Workers, vai ter problema. Verifique antes de comprometer a arquitetura.

Lógica de negócio complexa. Workers é ótimo para lógica simples e rápida na borda. Processamento pesado, filas complexas ou operações que precisam de estado consistente entre muitas requisições pedem uma solução diferente.

Debugging. O ambiente local com Wrangler é funcional, mas debugging em produção na edge tem mais fricção do que em um servidor tradicional. O Workers tem suporte a logs e tracing, mas exige configuração adicional para observabilidade completa.

Vendor lock-in. O runtime é específico da Cloudflare, mesmo sendo baseado em APIs web padrão. Migrar para outra plataforma no futuro exige avaliação do que precisa ser adaptado.

Perguntas frequentes sobre Cloudflare Workers

Cloudflare Workers substitui um servidor backend? Não para a maioria dos casos. Workers é melhor entendido como uma camada intermediária entre o usuário e o servidor, não como substituto completo. Para lógica de negócio complexa, banco de dados relacional com muitas tabelas ou processamento pesado, um servidor backend ainda faz mais sentido.

Dá para usar Cloudflare Workers com WordPress? Sim. Workers pode ficar na frente de um site WordPress para adicionar headers de segurança, aplicar redirecionamentos, fazer A/B testing ou servir resposta em cache antes de chegar ao PHP. O WordPress continua como origem; o Worker atua na borda.

Workers é grátis? O plano gratuito existe com 100 mil requisições por dia. Para projetos com mais volume ou que precisam de mais CPU time por requisição, o plano pago começa em cinco dólares por mês com cobrança por uso acima do incluído.

Qual é a diferença entre Cloudflare Workers e Cloudflare Pages Functions? Pages Functions rodam no mesmo runtime do Workers, mas são integradas ao fluxo de deploy do Cloudflare Pages, a plataforma de sites estáticos. Para projetos fora do Pages, Workers com Wrangler é a abordagem direta. Os dois podem ser integrados via bindings.

Cloudflare Workers tem suporte a TypeScript? Sim. O Wrangler compila TypeScript automaticamente. Os tipos oficiais estão disponíveis no pacote @cloudflare/workers-types e cobrem todos os bindings e APIs do runtime.

É possível conectar banco de dados externo no Worker? Sim, via fetch para APIs externas ou usando drivers que funcionam no ambiente do Workers. Para bancos relacionais no ecossistema da própria Cloudflare, o D1 é a opção nativa. Conexões diretas via TCP não são suportadas no plano padrão, mas a Cloudflare está expandindo esse suporte gradualmente.

Referências

• Documentação oficial
• Funcionamento do runtime
• Limites da plataforma
• Migração para Module Workers
• Opções de armazenamento