Eu cheguei a pagar quase 80 dólares por mês para um WordPress aguentar um milhão de visitas. Servidor na Hetzner, painel RunCloud para não ter que administrar PHP sozinho, Cloudflare APO para cache, tema, extensão de busca, renovação anual. O site no ar. A operação, uma lista de tarefas que nunca acabava.
Saí do WordPress porque o custo real era plugin, painel, vírus, atualização e máquina acesa — não só a hospedagem. Hoje os sites rodam em Cloudflare Workers, com D1 e R2, na faixa dos 5 dólares; para a maior parte dos projetos o plano gratuito já cobre. Não é um SPA montado no Lovable, nem Vercel com Supabase: é HTML saindo do Worker, no mesmo lugar do DNS.
- Antes
- WordPress, Hetzner, RunCloud, APO e plugin pago
- Agora
- Workers + D1 + R2, US$ 5 ou o plano gratuito
- Fora da conta
- SPA, Next.js, Astro e um PaaS por serviço
cPanel, MySQL, plugin anual e a fatura de quase 80 dólares
Durante anos, ter um blog na internet era isso: WordPress, hospedagem que subia de preço, cPanel, banco MySQL, phpMyAdmin, conexão remota, tema, extensão. Plugin de busca renovado todo ano. Plugin que ninguém atualiza. Painel de admin para entrar, atualizar, limpar vírus e torcer para a próxima versão não quebrar o tema. Não era sustentável. Dava trabalho. Dava dor de cabeça.
No auge eu empilhava três contas só para o WordPress ficar de pé. A Hetzner era o servidor barato. O RunCloud era o painel que gerenciava PHP e WordPress para eu não ter que virar sysadmin. A Cloudflare, além do DNS, cobrava o APO — Automatic Platform Optimization — para o cache do WordPress na borda. Quase 80 dólares no total, para um volume na casa de um milhão de visitas no mês.
Hoje eu não pago nenhuma dessas três linhas. Os sites cabem numa hospedagem de 5 dólares. Na prática, para a maioria das pessoas, essa hospedagem vai ser gratuita. Eu não sei por quanto tempo. A Cloudflare pode subir o preço, como Vercel e Netlify já fizeram. Enquanto o plano pago de Workers continua em 5 dólares por mês, está de muito bom agrado.
Vibe coding de SPA e a PaaS que eu recusei
A inteligência artificial facilitou criar projeto na internet. Isso não autoriza qualquer vibe coding. Eu não estou falando de abrir o Lovable, gerar um site em SPA, ignorar o que o Google vai receber e achar que está arrasando. SPA nasceu para o front: o navegador monta a página. O visitante vê. O rastreador, muitas vezes, não. Não é o tipo de criação que eu ensino.
Tampouco estou falando de Vercel, Netlify, Supabase, Firebase — a prateleira de PaaS em que cada pedaço tem conta, fatura e chave. Banco num lado, front no outro, autenticação num terceiro. Se você conecta APIs diferentes, aparece dor de cabeça e exposição de credencial. Era uma das coisas que eu tinha ódio de migrar para JavaScript: deploy, npm, arquivo .env, chave no GitHub. No PHP eu arrastava o arquivo para a pasta e via funcionar.
A IA evoluiu e passou a dar conta de projeto que eu não saberia escrever sozinho — até jogo online. Isso não apaga a outra metade: se você pede um sistema sem entender arquitetura, o que entra, o que sai e o que sobra no código, vem vulnerabilidade, vem sistema pesado, vem requisição demais no banco. No modelo de pagar por uso, isso vira conta. Eu também não estou pedindo Next.js nem Astro. Framework pesado, dependência empilhada, abstração demais para o tamanho do site que a maior parte das pessoas precisa.
Cloudflare Workers: a máquina some, a visita paga
Quem usa WordPress já conhece a Cloudflare como CDN: cache no mundo, site um pouco mais rápido, algum WAF na frente. O produto vai além. Workers é serverless na borda. Não existe um CPU seu ligado 24 horas numa cidade. A pessoa entrou, solicitou, recebeu. Acabou. Você deixa de se preocupar com RAM, com máquina, com localização do servidor — a lista que me dava dor de cabeça no WordPress.
A cobrança é por uso. Site mal feito, consulta desnecessária, loop no banco: o plano gratuito acaba e a fatura aparece. Site institucional, catálogo, ferramenta local, cliente que não passa de 10 mil visitas por dia: na gravação eu disse para ficar tranquilo. O plano gratuito da Cloudflare, como o da Vercel, cobre a maioria desses casos. Na documentação oficial, Workers no plano gratuito limita 100 mil requisições por dia, com reset à meia-noite UTC. O plano pago começa em 5 dólares por mês e inclui 10 milhões de requisições.
Eu desconfio de um corte brusco do gratuito. A Cloudflare oferece CDN de graça há muitas décadas. A primeira vez que eu vi o nome, tentei conectar, achei complicado e abandonei. Três, quatro anos depois, cedi: usei como CDN, proteção e cache na borda. Workers ficou anos no menu sem eu entender para que servia.
Do ódio a JavaScript até o Codex falar Wrangler, D1 e R2
Workers e Pages me pegavam no painel. Eu só manjava de PHP. JavaScript era dependência, pasta node_modules que ninguém explica, ritual de npm no terminal. Eu tentei um CMS headless, não consegui conectar a API, a IA da época não ajudava, e isso cimentou o ódio. Codex e Claude Code mudaram a conta: eu instruo, a ferramenta executa.
Hoje eu falo para o Codex criar o site na Cloudflare com Wrangler, ligando D1 e R2. Não preciso entrar no painel para nascer o projeto. O terminal faz. Eu ainda não acho esse o caminho ideal. Prefiro — e recomendo — você criar o projeto em TypeScript ou JavaScript, hospedar no GitHub e publicar pela Cloudflare. A vantagem do conjunto é outra: D1 e R2 não pedem chave de API colada no código. Você associa o banco e o armazenamento no Worker. A comunicação fica dentro da conta.
Workers, no recorte que eu mostro, é enviar o JavaScript e a Cloudflare fazer o deploy. Pages entra na mesma família. O que o visitante carrega é o resultado desse deploy, não um PHP interpretado numa VPS.
- Crie o site em JavaScript ou TypeScript. Hono cabe se você quiser um framework leve, feito com Worker em mente.
- Suba o código no GitHub. Evite commitar .env, chave e segredo.
- Publique com Wrangler ou com a integração da Cloudflare no repositório.
- No Worker, abra associações e ligue D1, R2 ou KV. Não cole token de banco no código para conversar com o próprio D1.
- Coloque chave de API externa, se existir, em variável de ambiente do Worker — Settings, não o repositório.
Dois medos de JavaScript: buraco no back e página que o Google não lê
O primeiro medo é segurança. JavaScript no back não é a linguagem que eu considero mais sólida. Muita gente faz em Node e segue. Eu separei o back em outro Worker e coloquei Cloudflare Access na frente, contra tentativa de invasão. Quem não passa da autenticação nem chega na rota administrativa.
O segundo medo é o que o Google recebe. SPA monta a página no navegador. Para busca, isso costuma ser um problema. Os sites que eu faço no Worker saem do servidor já em HTML, CSS e JavaScript estático — o mesmo desenho do PHP, do ponto de vista de quem baixa a página. Pode haver um pouco de movimento no cliente para layout. Nada que transforme o conteúdo principal numa casca vazia esperando o script. A comparação com o PHP, aqui, é de entrega, não de linguagem.
No painel do Worker aparecem métricas, deploys (GitHub ou outro origem), associações com banco e KV, observabilidade de quem fez GET, domínios e configurações. Na observabilidade eu vejo visita batendo em caminho que não deveria existir. Variável de ambiente e chave ficam lá, longe do GitHub. Linguagem de trabalho: JavaScript e TypeScript. Dá para subir Go e Rust via WebAssembly. O runtime não é só um arquivo .js jogado na CDN.
D1, KV, R2 e o Hyperdrive que eu ainda não abri
Pelo menu de associações o Worker fala com o resto da conta, sem chave de API no meio. Modelo de IA da própria Cloudflare, cobrado por computação em vez de uma API de terceiro — às vezes sai mais barato. Armazenamento de objeto no R2, o equivalente ao S3 da Amazon, para arquivo e mídia, sem cobrança de egress na tabela oficial. Banco no D1, que é SQLite. Você cria quantos bancos quiser e associa cada um ao site. A comunicação é a associação. Não tem string de conexão viajando para um Postgres em outro continente.
Workers KV é chave-valor. Serve quando o dado muda pouco: configuração, cache, lookup. Evita abrir o SQLite para coisa que não precisa de consulta relacional. Hyperdrive eu ainda não estudei a fundo. Na documentação, é aceleração e pool de conexão para banco que já existe — Postgres, MySQL — a partir do Worker. Se o seu caso ainda pede Postgres de verdade, esse é o caminho interno da Cloudflare, não o D1 fingindo ser outro produto.
A desvantagem do SQLite, e portanto do D1, é escrita simultânea. Ele serializa: uma gravação por vez, o resto entra em fila. Leitura se comporta como qualquer banco decente. Para blog, catálogo, site institucional, e-commerce pequeno, isso é peso de menos. WordPress usa MariaDB. Para a maioria desses projetos, MariaDB é canhão. Se um dia a escrita concorrente virar requisito de produto, aí sim Postgres — e aí o Supabase volta à conversa, falando com o Worker por Hyperdrive ou pela conexão que você escolher. Não é o caso da maioria de quem está saindo do WordPress.
- D1: SQLite serverless, um banco por projeto se quiser, associado no Worker.
- KV: chave-valor para dado que quase não muda.
- R2: arquivo e mídia, no lugar de um S3 com fatura de saída.
- Hyperdrive: ponte para Postgres ou MySQL já existentes; eu não usei na gravação.
- Workers AI: modelo na própria conta, cobrado por computação.
Durable Objects, Turnstile e um painel só
Durable Objects eu usei de verdade: um jogo online em tempo real, em JavaScript. A jogada, a requisição e a gravação no banco passam pelo objeto. A pessoa não manda um POST solto fingindo estado. Se você quer um SaaS com regra no servidor — não um formulário que o cliente autentica sozinho — Durable Objects é a peça que eu apontaria. Não explorei o restante do catálogo a fundo neste vídeo.
Segurança de borda já vem no mesmo login: WAF, Turnstile no lugar do captcha do Google (sem aquele teatro de semáforo), cache, redirecionamento, velocidade no domínio. É o melhor conjunto que eu tenho hoje porque eu não preciso de conta no Supabase, conta na Vercel, conta em mais um painel. É Cloudflare. Ponto.
Quem ainda insiste no WordPress e quer um pouco da liberdade de modelar dado sem migrar de plataforma: Meta Box. Campo customizado, template com Twig, PHP misturado no HTML. Funciona. Eu não quero mais entrar em phpMyAdmin, atualizar extensão nem tirar vírus. Essa é a frase honesta, não um manifesto contra o CMS.
SK Dojo, SK Sensei e o código que eu peço hoje
O primeiro site que eu gostei de migrar foi o SK Dojo, um jogo no estilo DLE: você tenta adivinhar, tem configuração de partida, compartilhamento, embed para colar em outro lugar, conquista do dia, últimos jogos, resposta e estatística. Quase tudo isso mora no localStorage do navegador. Eu não criei usuário. Menos superfície para alguém fuçar o site. Mudança de texto ou de regra eu peço no Codex. Post dá para publicar por API. Montei um back para mídia, dado e estatística — um headless meu, ainda faltando automação, suficiente para eu dizer que consigo abandonar o WordPress.
O SK Sensei é site de japonês: modo claro e escuro, dicionário, vários idiomas. No WordPress essa liberdade de modelar o banco existia se você programasse. Aqui eu peço a estrutura e sigo. Saiu também um site de Roblox e um catálogo de impressão 3D, todos no mesmo lugar. Nenhum está especialmente bonito. Eu nunca fui bom de design, nem no WordPress. Gosto de coisa alinhada. A IA às vezes encolhe um bloco de texto no lugar errado e eu tenho que mandar corrigir. Descobri um skill de design que ajuda; conteúdo continua sendo o que eu sei fazer.
Nesses sites em JavaScript eu tiro 100 no PageSpeed com uma frequência que no WordPress era briga: velocidade, acessibilidade, o pacote. Não é mágica. É HTML enxuto, pouca dependência, arquivo no R2, Worker na borda. Eu estava criando um site por dia, ou um a cada três. Isso também é um aviso: conteúdo perdeu valor na mesma velocidade. Traduzir, gerar texto, clonar estrutura — a IA faz. Quem quer economizar num institucional ou num site de cliente local, domínio pago uma vez no ano, pouca visita, Cloudflare é o recorte. Se um dia o gratuito acabar, o histórico de CDN barata me deixa cético. Preço pode subir. Aí a conta muda.
No código eu uso Hono, framework leve focado em Workers, e Drizzle ORM em cima do D1. Next.js, Astro, Nuxt: desnecessários para esse tamanho. Dá para fazer o site sem biblioteca de npm. Eu ainda não manjo de todos os recortes, mas o processo é simples se você sabe o que pedir e como a peça se encaixa. Tem programador profissional que entrega site bagunçado porque não manja de arquitetura. Tem leigo que, com isso claro, sai na frente. Faça a migração com revisão de segurança. Entenda o que você está mandando a IA escrever. Olhe a estrutura antes de apontar o domínio.
Na sequência
- Some na calculadora o que o WordPress custa de verdade: hospedagem, painel, APO, plugin anual e as horas de atualização.
- Não troque WordPress por um SPA gerado em ferramenta de vibe coding.
- Publique JavaScript ou TypeScript no Worker, com HTML saindo do servidor.
- Associe D1, R2 e KV no painel; não cole chave desses serviços no GitHub.
- Separe o back administrativo e coloque Cloudflare Access na frente.
- Use SQLite/D1 enquanto a escrita simultânea não for o produto; Postgres entra se a fila de gravação virar problema.
- Revise o código que a IA gerou: consulta extra, dependência inútil e rota aberta custam dinheiro e incidente.
Onde isso quebra
Levar o WordPress para um PaaS de front e continuar pagando banco, autenticação e mídia em três contas.
Gerar um SPA e culpar a Cloudflare porque o Google não vê conteúdo.
Escolher Next.js ou Astro por hábito e herdar a fatura da Vercel.
Abrir escrita concorrente pesada no D1 e tratar a fila do SQLite como bug da plataforma.
Deixar chave de API no repositório porque “é só um .env”.
Pedir para a IA criar o site inteiro sem olhar arquitetura, e descobrir o custo na fatura de Workers.
Perguntas frequentes
WordPress é uma plataforma ruim?
Não. Eu saí da operação: plugin, vírus, painel, máquina e fatura. Para time que precisa do admin conhecido e edita página o dia inteiro, WordPress continua válido. Meta Box ajuda se você ficar e quiser modelar dado sem migrar.
O plano gratuito da Cloudflare aguenta um site de cliente?
Na gravação eu falei em institucional e negócio local, abaixo de 10 mil visitas por dia, sem cobrança. O teto oficial de Workers no gratuito é 100 mil requisições por dia. Site mal otimizado, com consulta a cada clique, queima a cota. Confira a tabela atual antes de prometer “grátis para sempre”.
D1 substitui o MySQL do WordPress?
Substitui para blog, catálogo e a maior parte dos sites que usam MariaDB por costume. D1 é SQLite: leitura boa, escrita em fila. Se o produto precisa de muita gravação ao mesmo tempo, o próximo passo é Postgres — com Hyperdrive ou Supabase — não insistir no D1.
Preciso de Next.js, Astro ou um CMS headless para sair do WordPress?
Não. Eu recusei essa pilha. Worker, Hono se quiser, Drizzle no D1, R2 para arquivo. CMS headless eu tentei e travei na API; hoje o admin que eu preciso cabe num Worker separado, com Access.
E a segurança de um site feito com IA em JavaScript?
JavaScript no back pede cuidado. Eu separei o administrativo, usei Access, evitei conta de usuário onde localStorage resolvia, e passo Durable Objects no que precisa de estado confiável. Migração sem revisar o que a IA escreveu é só trocar de problema.