Homelab: infraestrutura self-hosted como código

Problema / Contexto

Rodar infraestrutura própria em casa sem virar um zoológico de configuração manual: dois hosts físicos (um Raspberry Pi 5 e um mini-PC Ryzen 7 8845HS) precisavam hospedar dezenas de serviços (plataforma, rede, observabilidade, automação, conteúdo, finanças, media player, integração, smart home, utilidades) de forma versionada, reproduzível e com failover real, não só “funciona na minha máquina”.

Decisões de arquitetura

Fragmentos de Compose por serviço, não compose monolítico por host. Cada serviço vive em infra/<categoria>/<servico>/ e é incluído por host via include:. Isso permite declarar um serviço uma única vez e ativá-lo seletivamente onde faz sentido, sem duplicar definição entre hosts.

HA de DNS sem single point of failure. Pi-hole primário/réplica atrás de um IP virtual compartilhado via keepalived/VRRP; a resolução de nome da rede inteira sobrevive à queda de um host. Nebula Sync mantém a config das duas instâncias em sincronia automaticamente.

Roteamento dual-path, não um proxy único pra tudo. Serviço interno usa Traefik com CA própria (step-ca, ACME) emitindo TLS automático para *.homelab. Serviço público sai via Cloudflare Tunnel para *.thalespm.me, sem porta nenhuma exposta diretamente na internet; a decisão de ficar público é por label Docker, serviço a serviço, com MFA via Cloudflare Access nos administrativos.

Backup em camadas, não só “rsync de vez em quando”. Snapshot consistente de banco (SQLite/Postgres, nunca cópia a quente) orquestrado por um scheduler próprio (Dagu), complementado por backup de filesystem multi-host via Restic com retenção GFS (diário/semanal/mensal).

Fluxo técnico

1. 01

   Declaração

   Cada serviço é um fragmento de Compose reutilizável em infra/<categoria>/<servico>/, incluído seletivamente por host via include:, sem compose monolítico duplicado por máquina.

   • Docker Compose
   • IaC
2. 02

   Roteamento dual-path

   Tráfego interno (*.homelab) passa por Traefik com CA própria (step-ca, ACME) emitindo TLS automático. Tráfego público (*.thalespm.me) sai via Cloudflare Tunnel, sem porta nenhuma exposta na internet, cada serviço decide via label Docker se fica público, com MFA (Cloudflare Access) nos sensíveis.

   • Traefik
   • step-ca
   • Cloudflare Tunnel
   • Cloudflare Access
3. 03

   Alta disponibilidade de DNS

   Pi-hole primário/réplica com IP virtual compartilhado via keepalived/VRRP; falha de um host não derruba a resolução de nome da rede inteira. Sincronização de config entre as instâncias automatizada via Nebula Sync.

   • Pi-hole
   • Keepalived
   • VRRP
   • Nebula Sync
4. 04

   Observabilidade

   Métricas via Prometheus/VictoriaMetrics + Grafana, logs centralizados via Grafana Alloy → Loki, alerting e monitoramento de disponibilidade via Uptime Kuma, com checklist obrigatório de conformidade toda vez que um serviço entra ou sai.

   • Prometheus
   • VictoriaMetrics
   • Grafana
   • Loki
   • Uptime Kuma
5. 05

   Backup em camadas

   Snapshot consistente de banco (SQLite/Postgres, nunca cópia a quente) orquestrado por um scheduler próprio (Dagu), mais backup de filesystem multi-host via Restic com retenção diário/semanal/mensal (GFS).

   • Dagu
   • Restic
   • GFS
6. 06

   Segurança e acesso remoto

   CrowdSec analisa logs em tempo real e bloqueia IP malicioso. Tailscale atua como subnet router, expondo a rede local inteira sem abrir porta nenhuma.

   • CrowdSec
   • Tailscale

Stack

Resultado / uso real

Infraestrutura 100% declarada como código, documentada e operada sozinho, cobrindo design de rede, alta disponibilidade, observabilidade, segurança em profundidade e backup/disaster recovery. Também sustenta automação de negócio real: workflows n8n automatizando conciliação financeira de uma operação com integração de maquininha de cartão/PIX, não apenas experimento de homelab.