Por muito tempo, publicar um site significava contratar uma máquina, configurar o servidor, o banco, os backups e torcer para o plano aguentar as visitas. Eu passei por isso: o servidor ficava sem fôlego, o banco engasgava e eu precisava cuidar de CPU, memória e gerenciamento. Para muitos sites e ferramentas, hoje dá para publicar o código numa plataforma serverless e parar de administrar uma máquina ligada o tempo todo.
Eu queria cuidar do site, não do servidor
Uma hospedagem compartilhada pode custar pouco, mas seus recursos são divididos com outros clientes. Quando um projeto cresce, a recomendação costuma ser migrar para uma VPS ou um cloud. Aí aparecem painel de gerenciamento, Linux, atualizações, banco de dados, cópias de segurança e avisos de CPU e RAM. Eu pagava pelo RunCloud para não ter de cuidar do servidor sozinho, além do custo da própria máquina.
O pior era descobrir o problema no meio do trabalho: uma página lenta, um banco que não respondia, um erro que derrubava o carregamento. Na hospedagem serverless, eu envio o código para uma plataforma e ela executa a parte dinâmica quando chegam requisições. O que mudou para mim foi deixar de ajustar uma máquina que fica ligada mesmo quando ninguém está acessando o site.
Serverless ainda tem servidor; você não administra a máquina
“Sem servidor” é um nome meio enganoso. O site continua rodando em servidores; a diferença é que a plataforma cuida deles. Em vez de escolher uma VPS com determinada memória e CPU, você publica o projeto e acompanha o uso dos recursos cobrados pela plataforma.
A rede global também muda a entrega. Um servidor tradicional fica numa região escolhida por você. Com uma plataforma distribuída, o código pode ser executado perto de quem acessa, enquanto os arquivos estáticos ficam na rede de distribuição. Isso reduz a distância em muitos casos, mas não apaga problemas de código, banco ou lentidão na API de outra empresa.
Cloudflare Workers, Vercel e linguagens compatíveis
Eu conhecia a Cloudflare pelo CDN de sites WordPress, mas Workers faz mais do que cache: permite publicar código na rede da Cloudflare. JavaScript e TypeScript são os caminhos mais conhecidos; hoje há suporte a Python e Rust, que ainda está em beta. Isso não transforma Workers numa VPS genérica. Um site em PHP ou um programa que precisa manter um processo ativo pode pedir outra arquitetura.
A Vercel cresceu com projetos web modernos, especialmente os que usam Next.js. Eu prefiro Cloudflare para boa parte dos sites que faço porque encontro mais serviços integrados e um custo que funciona bem nos meus projetos pequenos. Mas a escolha depende do que você construiu: se o projeto usa recursos específicos do Next.js, a Vercel pode dar menos trabalho.
O site, os arquivos e o banco podem ficar em serviços diferentes
Na arquitetura que uso, a aplicação roda num Worker, arquivos vão para armazenamento de objetos como R2 ou S3, e o banco fica num serviço próprio. O D1, por exemplo, usa SQLite sem que eu precise manter um servidor de banco ligado por conta própria. Filas, tarefas agendadas e workflows também podem ficar em serviços separados, em vez de dividir a mesma máquina com tudo.
Isso pede uma mudança de hábito. Não é enviar uma pasta public por SFTP e esperar encontrar o site, os arquivos e o banco no mesmo lugar. Você escolhe o serviço de cada peça e configura como elas conversam. Em troca, deixa de manter toda essa infraestrutura dentro da VPS.
Quanto custa: visitas não são a mesma coisa que requisições
Na comparação que fiz, uma hospedagem compartilhada ficava em R$ 10 a R$ 20 por mês; uma VPS ou cloud básica começava em R$ 35 ou R$ 40, e uma máquina mais confortável ficava entre R$ 50 e R$ 100. Para um WordPress com um milhão de visitas mensais, eu estimava R$ 60 a R$ 80 de servidor. Já um site estático bem otimizado poderia atender um milhão de visitas por zero ou poucos dólares em serverless. São valores do cenário que comparei, não uma promessa para qualquer projeto.
Para calcular seu custo, conte requisições ao Worker, tempo de CPU e chamadas ao banco. Uma visita não é necessariamente uma requisição: a página pode carregar vários arquivos estáticos sem executar código, ou chamar o Worker e o banco muitas vezes. Hoje o plano gratuito do Workers inclui 100 mil requisições por dia e 10 milissegundos de CPU por execução; assets estáticos não são cobrados como invocações dinâmicas, e D1 e R2 têm cotas próprias. O plano pago de Workers parte de US$ 5 por mês.
Na Vercel, o Hobby é gratuito para projetos pessoais e não comerciais. O Pro custa US$ 20 por mês e inclui US$ 20 de crédito de uso; o que passar das cotas pode gerar cobrança adicional. Então, quando comparo as duas plataformas, olho o que o meu sistema executa e os serviços que ele precisa, não só o total de visitas.
Quando eu manteria a VPS ou a hospedagem tradicional
Não existe motivo para migrar um sistema só para seguir uma tendência. WordPress e PHP podem continuar fazendo sentido, principalmente quando o projeto já funciona e a equipe conhece bem essa stack. Programas em Elixir ou outros binários, serviços Node.js que precisam ficar ativos, cargas de trabalho longas, GPU e pacotes ligados ao sistema operacional também podem precisar de uma VPS ou de outro tipo de cloud.
Ferramentas como n8n nasceram com outro modelo de execução. Talvez seja possível reescrever partes do fluxo em Workers ou Workflows, mas isso depende dos conectores, de quanto tempo cada tarefa leva e de quem vai manter o sistema. Migração não é só trocar o destino do deploy.
Também não colocaria loja, SaaS ou uma área com login no piloto automático. Serverless não corrige falha de autenticação nem protege dados por conta própria. Dá para fazer esses projetos, mas eu revisaria sessões, pagamentos, permissões e armazenamento com cuidado antes de mudar a arquitetura.
A plataforma pode mudar; sair ficou menos trabalhoso
É razoável perguntar se a Cloudflare pode mudar o plano gratuito, subir preços ou deixar de ser a melhor opção. Isso vale para qualquer empresa. Eu não escolheria uma stack só para evitar uma migração hipotética, mas manteria o código e os dados versionados para ter como sair.
A IA já ajuda a mapear o que depende de Workers, do banco e dos serviços da plataforma e a preparar a migração para outro lugar. Eu pediria para fazer uma parte por vez e conferiria o deploy e os dados antes de cortar o ambiente antigo. Isso ficou bem mais acessível do que fazer tudo à mão, mas não torna qualquer aplicação portátil com um clique.
Para muitos sites, parar de administrar uma máquina já vale
Para site institucional, blog, página de negócio local e ferramenta pequena, eu começaria avaliando serverless, principalmente quando o conteúdo é estático e a parte dinâmica é leve. Se o projeto depende de WordPress, PHP, processo permanente, job longo ou requisitos específicos do sistema operacional, eu compararia com uma VPS antes de migrar.
E-commerce, SaaS e sistemas com login também podem rodar numa arquitetura serverless, mas eu não os colocaria no piloto automático. Autenticação, pagamentos, permissões e armazenamento continuam exigindo revisão, qualquer que seja a hospedagem. Minha decisão começa pelo que o sistema faz: se não precisa de uma máquina sempre ligada, não pago por uma só por hábito; se precisa, mantenho a VPS.