Edge DNS Router para Sites SaaS Wildcard
Perfil:Produto interno Tyber.io
Construí um Cloudflare Worker que roteia tráfego wildcard para conteúdo por tenant armazenado em R2 — incluindo sites multi-página, sites com auth e subdomínios reservados — sem subir backend pra nada disso.
Resultados
O problema
Uma feature SaaS interna permite que usuários provisionem microsites num domínio wildcard instantaneamente: digita um nome, recebe site no ar em `<nome>.<dominio-da-plataforma>` com HTML, imagens e auth opcional. Fazer isso com arquitetura tradicional (VM por site, nginx por site, certificado por site) é dor operacional. Fazer com um backend único que faz fan-out por hostname é risco de privacidade e isolamento.
A pergunta interessante: um Cloudflare Worker mais R2 pode ser o backend inteiro?
A abordagem
Um Worker, DNS wildcard, chaves R2 determinísticas.
DNS wildcard no Cloudflare aponta o wildcard inteiro para um único Worker.
Pass-through de subdomínios reservados — uma allowlist curta de subdomínios da plataforma bypassa o Worker e vai direto para a origem original. A lista é configuração, nunca conteúdo.
Resolução de path — para qualquer outro subdomínio, o Worker lê `sites/<sub>/index.html` do R2, ou `sites/<sub>/<slug>.html` para sites multi-página, com fallback para `index.html`. Imagens ficam em `sites/<sub>/img/*.webp`.
Prefix por ambiente — `sites` em prod, `sites-dev` em dev. Mesmo Worker, mesmo código, ambiente selecionado pelo Wrangler.
Marker de auth — um objeto marcador guardado junto do conteúdo do tenant diz ao Worker que aquele site é privado; sem cookie de sessão assinado válido, a requisição vai para o fluxo de auth. Formato do token e manejo do segredo ficam de fora deste texto de propósito.
Content type, caching, headers — setados deterministicamente por extensão. WebP recebe cache de 7 dias, HTML recebe cache curto com `must-revalidate`, etc.
O router inteiro é um único arquivo Worker mais um bucket R2. Sem servidor de origem, sem provisionamento de SSL por subdomínio, sem registros DNS por tenant.
O resultado
Sites novos por tenant ficam no ar em segundos (o tempo de `PUT` de um HTML no R2). Latência p95 do Worker fica abaixo de 10ms no edge. A allowlist de reservados mantém o resto da plataforma intocada. Sites com auth funcionam pelo mesmo Worker sem infra extra.
Por que isso importa
O edge ficou bom o suficiente para que, para uma categoria real de workloads "static-ish, muitos tenants", um único Worker mais R2 seja o backend inteiro. As decisões de design interessantes são sobre as bordas chatas: quais subdomínios são reservados, como markers de auth se distinguem de conteúdo, como sites multi-página resolvem slugs, como manter prod e dev isolados num bucket só. Acerte as bordas e o resto é praticamente de graça.
Um engajamento parecido para o seu time?
Todo engajamento da Tyber.io começa pela mesma pergunta: qual problema dói mais e qual é o mais resolvível. Fale direto com o technical lead — sem funil de SDR, sem repasse pra júnior.
Falar com o technical lead