Durante anos o ritual era o mesmo: contratar um plano, apontar o domínio e torcer para a máquina continuar de pé. Se o projeto crescesse, vinha a VPS, o painel, o Linux, o servidor web, o banco, o backup e aquela lista de configuração que ninguém realmente entende — só coloca para rodar. Isso está mudando. Em muitos projetos você envia o código e uma plataforma como a Cloudflare executa quando alguém acessa. Não estou dizendo que o servidor tradicional vai desaparecer. Estou dizendo que, para uma fatia enorme de site e ferramenta, você não precisa mais ficar de plantão nele.
Serverless não é ausência de servidor: é deixar de alugar uma máquina 24 horas. Para site em JavaScript ou TypeScript, com arquivo em R2 e banco leve, Cloudflare e Vercel cobram por requisição e o plano gratuito da Cloudflare aguenta volume que, na hospedagem compartilhada, já pediria upgrade. PHP, WordPress, Elixir, processo sempre ligado e loja com login ainda pedem outro desenho.
- O que some
- RAM, CPU e painel da VPS no dia a dia
- O que você paga
- Requisição, leitura de banco e serviço extra
- O que não some
- Linguagem antiga, binário e sistema sempre ligado
O problema de manter o servidor aceso o dia inteiro
Numa hospedagem tradicional você paga para a máquina existir, mesmo sem visita. O plano barato costuma ser compartilhado: um vizinho barulhento derruba o desempenho do seu site. Quando o projeto cresce, a conversa vira cloud ou VPS, e aí entra o custo de gerenciamento. Eu paguei RunCloud para não ter que encarar o servidor sozinho. O servidor em si também não era barato.
A rotina era outra: banco que não aguentava, página lenta, aviso de 90% de CPU e de RAM, caçada ao erro que tinha derrubado o carregamento. Eu sofri bastante com isso até cair na hospedagem serverless. Sumiu a configuração de servidor. Até a parte de domínio e DNS ficou mais simples na Cloudflare.
A máquina numa cidade só também é um problema de distância
Hospedagem tradicional é alugar servidor em algum lugar do mundo. A distância entre o visitante e essa caixa aparece no tempo de resposta. Serverless já nasce com CDN e pode executar em vários pontos. O site se duplica. Quem acessa cai perto.
Isso não é mágica de “sem servidor”. O nome serverless engana. O site tem servidor. A diferença é que você não aluga uma máquina para deixar PHP, Python, ASP.NET ou um binário de Elixir rodando 24 horas. Você manda o código para uma plataforma — Cloudflare ou Vercel — e ela gerencia. RAM e CPU deixam de ser a sua planilha.
Pagar por uso não é o mesmo PaaS de dez anos atrás
A cobrança por recurso já existia. Google Cloud e Amazon já vendiam máquina em que você usava PHP e linguagens tradicionais e pagava CPU e RAM consumidos. No recorte do vídeo, Cloudflare Workers e as hospedagens serverless próximas disso cobram por request, leitura de banco e algumas funções extras. Você não fica olhando memória.
O receio de que “pagar por acesso sai mais caro” não bateu com o que eu vi. O plano gratuito da Cloudflare, na época da gravação, era o mais generoso. Dá para ter site dinâmico, com banco, recebendo até meio milhão de visitas no mês sem pagar nada — o tipo de volume de um site local. Eu não sei até quando isso permanece 100% de graça. A aposta da gravação é que o custo para a empresa é baixo: o código fica em disco e executa por poucos segundos de CPU, diferente de um PHP e um banco acesos o dia inteiro.
Na documentação oficial, o plano gratuito de Workers limita 100 mil requisições por dia, com reset à meia-noite UTC. Meio milhão de visitas no mês cabe nesse teto se cada visita não disparar uma rajada de requests. Banco, KV, fila e CPU têm cota própria e mudam. Confira a tabela da Cloudflare antes de prometer “grátis para sempre” a um cliente.
Por que eu fico com a Cloudflare, e o preço da linguagem
Muita gente conhece a Cloudflare só como CDN de WordPress: cache no mundo e alguma proteção. O produto é bem maior, e no Brasil isso ainda é pouco falado. Quando JavaScript e TypeScript explodiram, a Vercel cresceu como hospedagem serverless. Para mim a Cloudflare é melhor: mais função, principalmente no plano gratuito. Se o site nasce em linguagem moderna, eu recomendo ela com pouca hesitação. A entrega é na borda. A hospedagem tradicional fica presa na localidade que você escolheu.
A desvantagem é o recorte de linguagem. Serverless, neste desenho, aceita JavaScript, TypeScript, Python e Rust. PHP e o resto da prateleira antiga continuam na hospedagem tradicional. Quem precisa de Elixir em binário continua precisando de cloud ou VPS. Até Node.js, dependendo do que o processo faz, ainda pede servidor ligado.
O fluxo de publicação também muda. Antes: SFTP numa pasta public. No serverless que eu uso, as peças não dividem o mesmo ambiente: o site; os arquivos num CDN de objeto como R2 ou o S3 da Amazon; o banco, em geral SQLite, porque não exige um servidor de banco aceso o tempo todo. Em volta disso entram cache, fila, tarefa programada, workflow e dado temporário. Na hospedagem tradicional, cada um desses itens ou não existia ou virava mais um serviço 24 horas pesando a mesma máquina.
Quanto custa lado a lado, na época da gravação
Compartilhada: R$ 10 a R$ 20 por mês. VPS ou cloud mais fraco: a partir de R$ 35 a R$ 40; o confortável ficava entre R$ 50 e R$ 100. WordPress com mais de um milhão de visitas no mês pedia servidor na casa das dezenas — eu falei em uns 60, 80 para ter desempenho. No serverless, se o site for estático e bem feito, um milhão de visitas pode sair a zero ou no máximo uns US$ 5. Você paga request, leitura de banco e o extra que estiver fora da cota. As cotas, de novo, são generosas. Site institucional e negócio local praticamente não pagam.
Isso muda a conta de quem faz site para cliente. Dá para incluir a hospedagem no valor anual e ficar com a margem, em vez de repassar para a empresa de plano compartilhado. O servidor não cai por RAM ou CPU. Pode haver falha temporária da Cloudflare, como em qualquer plataforma. O site ainda pode ter erro e vulnerabilidade — essa parte continua sua. Só que gerir um site sem máquina ficou bem mais tranquilo, ainda mais com IA escrevendo e revisando código.
A Vercel, no plano pago, começava em US$ 20 na gravação. É a casa natural de quem construiu tudo em Next.js. Também é o exemplo clássico de ficar preso a um jeito de fazer o site.
Quando o serverless não substitui a VPS
O título do vídeo é uma provocação, não um atestado de óbito da VPS. Cloud, VPS e compartilhada não vão morrer no curto prazo. Tem gente presa no WordPress. Tem gente que prefere PHP — e, em alguns casos, PHP ainda é vantagem de segurança em relação a JavaScript. Tem linguagem que precisa de processo contínuo. Elixir em binário é o exemplo que eu usei. Node.js com daemon, worker interno, fila na própria máquina ou um runtime que assume o sistema operacional continua pedindo servidor.
Plataformas como n8n também nasceram para viver numa máquina. No vídeo eu digo que talvez valha abandonar esse modelo e ir para serverless, porque a IA hoje reescreve o projeto com uma velocidade que antigamente não existia. “Talvez” é a palavra honesta. Se o fluxo precisa de dezenas de conectores visuais, de um editor que a equipe não-programadora opera, ou de um processo que não cabe no tempo de CPU de um Worker, a VPS ainda é o chão. Há um guia no blog sobre avaliar Cloudflare Workflows como caminho paralelo ao n8n; não é o mesmo que desligar a VPS amanhã.
E-commerce, SaaS e site com login e usuário eu não recomendo no piloto automático. A ressalva da gravação é segurança. Se você programa e consegue mandar a IA revisar o código, o recorte afrouxa. A Cloudflare ainda oferece camadas para reduzir vazamento de API e abuso. Mesmo assim, sessão, pagamento e dado de pessoa não são o primeiro projeto para aprender Workers.
Fica de fora, na prática: painel que exige SSH o dia inteiro, software que só roda em Linux com pacote específico, GPU, banco pesado com escrita concorrente de verdade, e qualquer coisa que precise de um binário escutando porta como um sistema operacional comum. Nesses casos você não “migrou mal”. Você escolheu a ferramenta errada para o problema.
- PHP, WordPress e CMS que assumem Apache ou Nginx o tempo todo.
- Elixir e outros binários que precisam de processo contínuo.
- Node.js quando o sistema é um servidor sempre ligado, não uma função por request.
- n8n e afins, se a equipe depende do editor visual e dos conectores no estado atual.
- Loja, SaaS e área logada, a menos que você saiba revisar autenticação e dado sensível.
- Carga que estoura CPU curta, GPU, ou pacote que só existe no sistema operacional da VPS.
E se a Cloudflare encarecer, falhar ou prender o seu site?
A pergunta justa: a hospedagem serverless é gerenciada por uma empresa. E se ela cortar o plano gratuito, subir o preço, complicar a vida ou falir? Você construiu tudo naquele ecossistema. Pode acontecer. A Cloudflare oferece CDN grátis há mais de dez anos e nunca tirou; isso me deixa cético quanto a um corte brusco. Preço pode subir. Pode aparecer tecnologia melhor. Você pode ter escolhido um framework que só se dá bem ali — o caso do Next.js na Vercel é o mais citado.
O que mudou é o custo de sair. Migração de site, de linguagem e de banco ficou muito mais rápida com IA. Não precisa de um texto enorme de instrução: você descreve o caso, manda o código e pede a mudança. Se um dia a Cloudflare, a Vercel ou qualquer PaaS deixar de fazer sentido, a conversa com o modelo faz o trabalho que antigamente levava semanas.
O conselho da gravação, para quem já paga Codex, GPT ou Claude: leve o site para JavaScript ou TypeScript e publique nesse modelo. Menos dor de cabeça de servidor. Com o recorte de e-commerce, SaaS e login ainda no colo. ChatGPT até hospeda site agora, o que diz alguma coisa sobre o mercado de quem só vende máquina. Os dias ficaram mais difíceis para esse produto. Diminuir não é o mesmo que acabar.
Na sequência
- Confira se o projeto cabe em JavaScript, TypeScript, Python ou Rust na borda.
- Separe página, arquivo estático e banco: Worker, R2 ou S3, SQLite/D1.
- Estime requests e leituras com o tráfego real, não só com o marketing do plano gratuito.
- Se ainda há PHP, WordPress, binário ou processo 24 horas, mantenha VPS ou cloud para essa parte.
- Não jogue loja ou área logada para serverless sem revisar autenticação e segredo.
- Guarde um caminho de saída: código versionado e um desenho que a IA consiga migrar.
Onde isso quebra
Achar que serverless elimina servidor. Ele elimina a máquina que você administra.
Levar um WordPress ou um PHP legado para Workers e culpar a plataforma pelo runtime que não existe.
Prometer hospedagem grátis ilimitada para cliente sem ler a cota de request, banco e CPU.
Construir o site inteiro em Next.js só porque a Vercel “é o lugar do Next”, e depois reclamar do preço.
Ignorar login, pagamento e dado de usuário porque “a Cloudflare já protege”.
Perguntas frequentes
Serverless significa que o site não tem servidor?
Não. Significa que você não aluga uma máquina 24 horas. A plataforma executa o código no acesso e cobra por uso. Ainda existe servidor; ele não é o seu problema operacional.
Cloudflare Workers substitui qualquer VPS?
Não. Substitui bem site e ferramenta em JavaScript ou TypeScript, com arquivo em objeto e banco leve. Não substitui PHP, WordPress, Elixir, GPU, nem todo sistema Node que precisa ficar escutando o tempo todo.
O plano gratuito da Cloudflare aguenta um site de verdade?
Para site local e institucional, na gravação eu falei em até meio milhão de visitas no mês. O teto oficial de Workers no plano gratuito é 100 mil requisições por dia. Volume, tipo de request e leitura de banco decidem se isso sobra ou aperta.
E se eu ficar preso na Cloudflare ou na Vercel?
Pode acontecer, principalmente se o site nascer amarrado a um framework. A mitigação hoje é migração com IA: o código versionado sai de um runtime para outro em horas, não em um projeto de meses.