O que uma única pessoa consegue operar de fato: o caso do Stelae

O Stelae é um serviço pequeno: cada cliente ganha uma instância privada de WordPress, que vira HTML estático e é publicada numa conta do próprio cliente (repositório git, Cloudflare ou statichost.eu). O autor é o único operador, sem equipe nem plantão. A decisão central é nunca hospedar o site publicado. Se o Stelae cair, os sites continuam no ar. O custo é abrir mão da receita recorrente típica de hospedagem, e o autor assume isso de propósito.

Na operação, em vez de orquestração, um reconciliador roda a cada quinze minutos e compara pares de estados que podem divergir (Docker, provedor de pagamento, máquinas de estado), corrigindo a diferença. As passadas têm teto (50 faturas, 20 remoções por TTL, 20 arquivos órfãos) para que o pior caso seja lento, não barulhento. Cada site tem três máquinas de estado separadas (site, assinatura e contêiner), porque falham separadamente. Os alertas vão por push (ntfy) com e-mail de reserva, há lembrete a cada hora para intervenção humana e um heartbeat externo, o único monitor que sobreviveria ao desaparecimento da máquina principal. Os backups passam por checagem de integridade do SQLite antes de serem aceitos. Na partida, o código lê de volta os pragmas do SQLite (WAL, chaves estrangeiras, busy timeout) e se recusa a subir se não baterem, pois drivers Go ignoram parâmetros desconhecidos em silêncio.

Para quem toca um produto sozinho ou com time minúsculo, o caso sustenta uma pergunta prática: o que acontece quando ninguém está olhando? A resposta do Stelae é reduzir o que depende de você (o site público fica fora da sua infraestrutura), limitar o dano das falhas e tornar o silêncio um sinal. É uma leitura editorial, não receita universal: o próprio autor diz que não é a arquitetura certa para uma empresa com equipe de operações, e que o modelo não serve para lojas, por perder comentários nativos e checkout.