Cloudflare Workers permite executar código de servidor sem manter um servidor tradicional ligado. Você publica um Worker, a Cloudflare o executa perto de quem faz a requisição e o código usa APIs da web, como Request, Response, fetch e WebSocket. Para quem faz vibe coding, isso reduz a quantidade de infraestrutura inicial — mas não elimina decisões de arquitetura, segurança ou dados.
No ecossistema da Escola de Aplicativos, Workers executam o Portal, o Gestor, a API e o serviço de links. O ponto importante não é “rodar tudo na edge”. É colocar cada responsabilidade no Worker certo, com bindings explícitos para KV, R2, filas, IA e Workflows.
O que é Cloudflare Workers, em termos práticos?
Cloudflare Workers é um runtime serverless baseado em isolates V8, não em uma VM ou container por requisição. Isso combina bem com APIs HTTP, autenticação, BFFs, cache, webhooks e pequenos serviços de produto. O código pode responder rapidamente sem você administrar autoscaling, sistema operacional ou balanceador.
| Opção | Melhor para | Cuidado principal |
|---|---|---|
| Cloudflare Workers | APIs, BFF, edge, webhooks, cache e automações curtas | não tratar o runtime como um servidor Node persistente |
| VPS com Node | processo sempre ligado, software legado, controle total do host | operação, patching e escala ficam com você |
| função serverless regional | integração simples em uma região | latência e modelo de execução variam por provedor |
| container | binários, dependências de sistema e jobs específicos | mais custo e operação do que um Worker puro |
Como ele se encaixa em um produto brasileiro
Imagine um SaaS de atendimento para uma clínica. O navegador chama uma API para listar conversas, um webhook recebe atualização do provedor, uma imagem de perfil precisa ser entregue e um evento de conversão deve ser enviado sem atrasar a tela. Não é necessário colocar tudo no mesmo handler.
Uma arquitetura inicial pode separar assim:
Browser → Portal Worker → API Worker → SurrealDB
├→ KV (cache e sessão)
├→ R2 (arquivos)
├→ Queue (evento assíncrono)
└→ Workflow (processo longo)Esse desenho facilita vibe coding porque o agente de IA recebe fronteiras claras. Um pedido para “adicionar upload de capa” não deveria resultar em uma chave de storage exposta no navegador; ele deve passar pela API, validar arquivo, registrar file e devolver uma URL pública controlada.
O modelo de preço que importa
Os preços mudam, então trate esta seção como fotografia de julho de 2026 e confira a tabela oficial antes de fechar uma projeção. O plano Workers Paid começa em US$ 5 por mês, inclui 10 milhões de requests e 30 milhões de milissegundos de CPU por mês. Depois disso, requests custam US$ 0,30 por milhão e CPU US$ 0,02 por milhão de ms. O plano gratuito inclui 100 mil requests por dia e 10 ms de CPU por invocação.
O erro comum é calcular apenas requests. Um endpoint que consulta serviços externos pode esperar bastante tempo sem gastar CPU; já uma serialização pesada, imagem ou loop mal desenhado consome CPU. Coloque limite de CPU e monitore antes de liberar uma funcionalidade que recebe tráfego público.
| Pergunta | O que medir |
|---|---|
| O endpoint é caro? | CPU por request, não só volume |
| O cache ajuda? | requests continuam cobrados; CPU cai quando o Worker não executa lógica no cache hit |
| O job demora? | mova-o para Queue ou Workflow |
| Há abuso? | limite CPU, valide entrada, use rate limiting e WAF |
Prós e contras
Vantagens: deploy rápido, infraestrutura global, bindings nativos, escala automática e poucas peças operacionais para começar. O mesmo runtime pode servir API, cron, consumer de Queue e integração com IA.
Limitações: não presuma memória persistente entre requests, não use APIs exclusivamente Node sem confirmar compatibilidade e não faça trabalho longo dentro de uma requisição do usuário. Também não escolha Workers apenas pela proximidade geográfica se seu banco estiver longe ou se o gargalo real for um serviço externo.
Como começar sem criar um monólito de edge
Quero criar um endpoint no Worker para gerar uma URL de upload.
Antes de alterar código:
- leia AGENTS.md e o wrangler.jsonc do serviço;
- identifique autenticação, binding de storage e validação existentes;
- proponha o menor fluxo seguro;
- não exponha token de Cloudflare, não altere produção e não crie bucket novo.
Entregue plano, arquivos afetados, riscos e testes.
Em seguida, peça uma mudança pequena: criar a rota, testar autorização e registrar logs estruturados. O deploy é a última etapa, não uma consequência automática de o código compilar.
[ CONTEÚDO_INTEGRAL_DISPONÍVEL ]
Continuar: quando usar KV para cache, sessão e links curtos CLIQUE PARA DESBLOQUEAR A LEITURA
Construindo aplicações robustas com arquitetura de alto nível e infraestrutura otimizada na edge do Cloudflare Workers com SurrealDB.
Segurança de dados e conformidade com privacidade desde o primeiro dia de código com tratamento de estados e sessões resilientes.
Métricas de performance para monitorar a experiência do usuário e otimizar custos operacionais em produção com dashboards estruturados.
Construindo aplicações robustas com arquitetura de alto nível e infraestrutura otimizada na edge do Cloudflare Workers com SurrealDB.
Segurança de dados e conformidade com privacidade desde o primeiro dia de código com tratamento de estados e sessões resilientes.
Métricas de performance para monitorar a experiência do usuário e otimizar custos operacionais em produção com dashboards estruturados.
Checklist de produção
- cada serviço tem
wrangler.jsonce bindings por ambiente; - segredos ficam em secrets, nunca no bundle ou no navegador;
- a API valida autorização antes de tocar um binding;
- CPU e falhas de dependências externas são observados;
- jobs demorados saem do request crítico;
- staging usa recursos separados de produção;
- deploy e rollback têm um caminho conhecido.
Perguntas frequentes
Workers substitui qualquer backend?
Não. Ele cobre muito bem rotas HTTP e orquestração de serviços. Casos que exigem binários, processos sempre ligados ou estado fortemente coordenado podem pedir Containers, Durable Objects ou outra infraestrutura.
Dá para usar Nuxt e Hono em Workers?
Sim. Nuxt pode gerar um servidor Nitro para o preset Cloudflare, e Hono fornece uma camada leve para APIs. O framework não remove as regras do runtime nem a necessidade de validar bindings.
Workers fica sempre mais barato?
Não automaticamente. Ele costuma reduzir custo operacional no início, mas consumo de CPU, logs, IA, storage e serviços externos continuam existindo. O bom desenho mede cada camada.
