# Cloudflare Workers: do vibe coding a um produto que aguenta crescer > Entenda Cloudflare Workers para APIs, BFFs, cache, webhooks e IA: onde se encaixa, como custa, prós, limites e como usar sem criar um monólito. **Autores:** Mauro Mequelussi **Publicado:** 2026-07-23T12:00:00.000Z **Atualizado:** 2026-07-23T12:00:24.055024211Z **Tags:** arquitetura, workers, serverless, vibe-coding, cloudflare --- 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 | ::callout{type="info" title="O Worker é uma camada de produto, não apenas um endpoint"} Use o Worker para aplicar autenticação, validar entrada, acionar bindings e devolver uma resposta previsível. Banco, arquivo e trabalho demorado devem ter uma fronteira explícita. :: ## 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: ```text 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 ::prompt-snippet{title="Pedido seguro para um agente de código" model="Seu agente de IA"} Quero criar um endpoint no Worker para gerar uma URL de upload. Antes de alterar código: 1. leia AGENTS.md e o wrangler.jsonc do serviço; 2. identifique autenticação, binding de storage e validação existentes; 3. proponha o menor fluxo seguro; 4. 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. ::read-more{slug="cloudflare-kv-cache-sessoes" label="Continuar: quando usar KV para cache, sessão e links curtos" placement="mid_content"} ## Checklist de produção - [ ] cada serviço tem `wrangler.jsonc` e 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. ### Fontes e leitura recomendada - [Cloudflare Workers](https://developers.cloudflare.com/workers/) - [Preços de Workers](https://developers.cloudflare.com/workers/platform/pricing/) - [Workers e limites de CPU](https://developers.cloudflare.com/workers/platform/limits/)