A inteligência artificial me ajudou a tirar do papel projetos que eu antes nem começaria. Isso também me fez repensar a estrutura dos meus sites: no WordPress, servidor, painel de PHP, cache e renovações de plugins já custavam quase US$ 80 por mês, além do tempo que eu gastava mantendo tudo. Hoje uso Cloudflare Workers em vários projetos. Vou explicar o que mudou para mim e como eu avaliaria essa troca antes de mexer em um site que já está no ar.
O custo do WordPress também aparecia nas horas de manutenção
Na época, eu somava um servidor da Hetzner, o RunCloud para administrar PHP e WordPress, o APO da Cloudflare e plugins pagos com renovação anual. A conta chegou perto de US$ 80 por mês para um site que recebia algo em torno de um milhão de visitas mensais. Esse número descreve a minha configuração naquele momento; não serve como orçamento para qualquer WordPress.
A outra conta era o tempo: atualizar plugins, conferir o servidor e investigar quando alguma coisa parava de funcionar. Antes de migrar, eu colocaria no papel as duas coisas — despesas recorrentes e horas de manutenção — e perguntaria qual parte realmente incomoda. Se o painel atual resolve seu trabalho e a hospedagem está estável, talvez a troca não pague o esforço.
Workers mudou a parte da infraestrutura que eu precisava administrar
Eu já usava a Cloudflare como CDN, mas demorei para entender o que dava para fazer com Workers. Minha referência era PHP: eu subia um arquivo e via o site mudar. A primeira tentativa de conectar um CMS headless a uma API não funcionou, e o ecossistema de JavaScript parecia exigir ferramentas demais. Com Codex e outras ferramentas de programação com IA, consegui passar dessa barreira e testar projetos que antes eu deixaria de lado.
Um Worker executa o código quando recebe uma requisição; eu não mantenho uma VPS exclusiva ligada para cada site. Isso reduz o trabalho de cuidar de máquina e painel, mas o serviço ainda tem limites e cobrança conforme o uso. Para comparar custos, confira as condições atuais e estime requisições, CPU, banco e armazenamento do seu caso. Visitas não equivalem automaticamente a requisições faturáveis, então eu não usaria uma conta antiga minha como promessa de preço.
Confira a entrega das páginas e proteja o acesso administrativo
Uma dúvida comum é se um site em JavaScript consegue entregar páginas que buscadores entendem. Uma página montada só no navegador pode depender de etapas adicionais. Nos meus projetos, o servidor já entrega o HTML da página, como eu esperava quando trabalhava com PHP. Eu confiro a resposta recebida e o conteúdo de cada rota importante; escolher Workers, por si só, não garante que todas as páginas estejam prontas para serem lidas.
Segurança também exige uma decisão explícita. Eu deixo o back-end e a área administrativa protegidos, guardo credenciais fora do código público e verifico quais rotas permitem gravações. Cloudflare Access e Turnstile ajudam em partes diferentes desse trabalho, mas nenhuma ferramenta substitui a revisão do que o sistema permite fazer.
Associe o banco e os arquivos que o projeto realmente usa
A vantagem prática para mim é associar banco e arquivos ao Worker pela própria conta, em vez de configurar uma conexão separada para cada serviço. Uso D1, baseado em SQLite, em catálogos e conteúdo, e R2 para guardar arquivos e mídia. O código acessa esses recursos por bindings; se eu chamar uma API externa, ainda preciso guardar a credencial como segredo.
Cada peça resolve um tipo de problema. KV funciona para dados simples que mudam pouco; Durable Objects mantém estado coordenado, como as partidas do meu jogo; Hyperdrive conecta um banco PostgreSQL ou MySQL que já existe. Eu ainda não usei Hyperdrive nos meus projetos. Antes de escolher, verifico o volume de gravações e as necessidades do sistema: D1 atende ao que mantenho, mas não é uma resposta universal para todo banco.
Nos projetos que citei, também uso Hono para organizar rotas e Drizzle ORM para trabalhar com D1. Essa é a combinação que adotei; não é necessário copiar todas as minhas escolhas para avaliar se o modelo serve para o seu site.
Faça a migração em etapas e confira o que mudou
Antes de desligar o WordPress, eu faria um inventário de URLs, imagens, formulários e integrações. Depois, migraria uma seção ou um projeto pequeno, confirmaria que cada endereço importante abre e acompanharia erros e consumo quando o novo sistema recebesse tráfego. Assim eu descobriria um problema de rota, permissão ou custo enquanto ainda consigo voltar atrás.
Também verificaria se as páginas chegam como HTML pronto e se a área administrativa está protegida. São conferências do site em funcionamento; a escolha de JavaScript ou Workers não garante esses resultados sozinha.
Meus projetos mostram onde essa troca fez sentido
O SK Dojo foi o primeiro projeto que gostei de migrar: um jogo de adivinhar jogadores, com partidas compartilháveis e estatísticas. Guardei o histórico simples no armazenamento do navegador, sem criar uma conta só para isso, e montei um back-end para administrar dados, mídia e estatísticas. Também levei o SK Sensei, projetos de Roblox e o catálogo de impressão 3D para esse ecossistema. O desenho e alguns blocos precisaram de ajustes; a migração não resolveu essas partes automaticamente.
A IA me ajudou a dar vida a ideias, mas ainda preciso entender a arquitetura, revisar o que o sistema faz e corrigir o que ficou pesado ou inseguro. Para projetos que pedem um blog editorial com painel conhecido, equipe trabalhando em conjunto e plugins já bem mantidos, o WordPress pode continuar sendo uma escolha prática. Eu troquei porque queria menos manutenção de servidor e mais liberdade para desenvolver ferramentas próprias. Antes de fazer o mesmo, eu compararia essa meta com o trabalho real de migrar e manter o novo sistema.