Como construí este site inteiro no edge da Cloudflare

Quando decidi refazer meu site, a tentação fácil era subir um WordPress ou um Next numa VPS e seguir a vida. Mas eu queria que o próprio site respondesse uma pergunta que escuto de cliente quase toda semana: dá para rodar uma aplicação de verdade, com banco, busca e IA, sem manter servidor e sem pagar por capacidade parada? A resposta que eu defendo é sim, no edge. Então construí exatamente isso e deixei o site ser a demonstração.

O que esse site realmente faz

É comum tratar site pessoal como página estática. Este faz bem mais que isso: serve páginas de marketing prerenderizadas, um blog com conteúdo vindo de banco, uma seção de links curados com busca semântica e conexões entre conteúdos, formulários de contato e newsletter, um painel de controle com autenticação, e um servidor MCP que expõe ferramentas de leitura para agentes de IA. Cada uma dessas peças tem uma exigência diferente de latência, estado e custo, e foi isso que tornou o projeto um bom teste de arquitetura.

Por que edge, e por que Cloudflare

O Worker roda perto de quem acessa, com inicialização praticamente instantânea, então a primeira resposta já sai rápida em qualquer região. Mas o compute foi só parte da decisão. O que pesou mais foi ter banco, storage, cache, vetores e IA ali como peças nativas, acessadas por binding, sem eu subir e manter um serviço separado para cada uma. Em vez de costurar cinco provedores, eu fico dentro de um runtime só.

Cada peça no seu lugar

A maior parte das páginas é prerenderizada para HTML estático no build, e só as rotas que precisam de dados ao vivo entram em SSR sob demanda: APIs, blog, links e painel. O D1, que é SQLite no edge, guarda os posts do blog e os links curados. O R2 guarda os assets, sem custo de egress. O KV guarda as sessões de autenticação do painel. O Vectorize indexa os embeddings de posts e links, o que permite sugerir conexões semânticas entre conteúdos. O Workers AI gera esses embeddings e roda as features de IA. E há um servidor MCP no próprio Worker, além de uma ferramenta WebMCP no navegador, para que agentes consigam descobrir o que existe aqui sem precisar raspar a página.

Os trade-offs honestos

Edge tem limite, e seria desonesto vender como bala de prata. O D1 ainda é jovem e tem limites de tamanho e de escrita que pesariam numa operação de escrita intensa, então ele brilha em leitura, que é o meu caso. Debugar no edge é diferente de abrir um terminal num servidor: você depende mais de logs e observabilidade do que de anexar um profiler. O Worker tem teto de CPU por request, o que obriga a empurrar trabalho pesado para fora do caminho da resposta. Nada disso me atrapalhou aqui, mas são exatamente as perguntas que eu faço antes de recomendar esse caminho para um cliente, porque a resposta muda conforme o workload.

O que isso prova

Recomendar arquitetura é fácil no slide. O que dá peso à recomendação é estar rodando aquilo que você defende, com as cicatrizes que só aparecem em produção. Este site é esse argumento: cada escolha aqui eu já vivi de ponta a ponta, com os problemas reais que vêm junto.