O problema: staging custa caro

Todo time que trabalha com software em produção precisa de um ambiente de staging. Um lugar para testar deploys, validar migrações de banco, simular cenários de erro antes que cheguem ao usuário final. O problema é que manter um ambiente de staging na cloud custa dinheiro real.

Um servidor de aplicação, um banco de dados, um Redis, talvez um worker de background — replicar a stack de produção em cloud pode facilmente custar entre US$ 50 e US$ 200 por mês, dependendo do tamanho da aplicação. Para uma startup ou consultoria pequena, esse custo é difícil de justificar quando o ambiente fica ocioso a maior parte do tempo.

A alternativa mais comum é não ter staging nenhum. Testar direto em produção, fazer deploy e torcer. Funciona até o dia em que não funciona.

A decisão: dois datacenters, dois propósitos

A arquitetura que adotamos separa a infraestrutura em dois ambientes com propósitos distintos:

  • Proxmox no homelab — funciona como datacenter de staging parcial. Roda a aplicação, banco de dados e serviços auxiliares em VMs e containers LXC provisionados localmente. Custo mensal adicional: zero (o hardware já existe).
  • Vultr VPC — datacenter de produção. Servidores em Nova York com rede privada (VPC), backup automatizado e IP público. Custo previsível e escalável.

A palavra parcial é importante. O staging no homelab não replica 100% do ambiente de produção. Não tem SSL, não tem o mesmo volume de dados, não tem a mesma latência de rede. Mas replica o que importa para a maioria dos testes: o processo de deploy, a configuração de serviços, as migrações de banco e o comportamento da aplicação com dados reais (anonimizados).

A arquitetura

graph TB
  subgraph homelab["Proxmox homelab — Staging (192.168.15.0/24)"]
    A1[app-staging — VM]
    A2[wireguard — LXC]
    A3[monitoring — Docker]
  end

  subgraph vultr["Vultr VPC NY — Produção (10.1.96.0/20)"]
    B1[app — VM]
    B2[backup — VM]
    B3[vpn / WireGuard — VM]
  end

  A2 <-->|"WireGuard tunnel (10.200.200.0/24)"| B3

Os dois ambientes vivem em redes completamente separadas. O homelab usa a rede residencial (192.168.15.0/24), a Vultr usa uma VPC privada (10.1.96.0/20). A conexão entre eles é um túnel WireGuard que cria uma sub-rede virtual (10.200.200.0/24) acessível dos dois lados.

Na prática, isso significa que um serviço rodando no homelab consegue acessar recursos na Vultr (e vice-versa) como se estivessem na mesma rede, com latência de internet normal.

A cola: WireGuard

O WireGuard é o que torna essa arquitetura viável. É um protocolo VPN moderno, leve e rápido, que roda no kernel do Linux. Diferente de soluções mais pesadas como OpenVPN ou IPSec, a configuração é mínima e a performance é excelente.

O servidor WireGuard roda na Vultr (IP público, porta fixa). O cliente roda em um container LXC no Proxmox — não precisa de uma VM inteira para isso. O Proxmox 9+ já tem o módulo WireGuard no kernel, então um container LXC unprivileged é suficiente.

A configuração do peer no homelab inclui PersistentKeepalive, necessário quando o cliente está atrás de NAT residencial. Sem isso, o túnel cai após alguns minutos de inatividade.

Para que o tráfego flua entre as redes (não apenas entre os dois hosts do túnel), o servidor VPN precisa de:

  1. ip_forward habilitado
  2. Regras de iptables com MASQUERADE na interface da VPC
  3. Rotas estáticas nos demais hosts da VPC apontando para o IP do servidor VPN

Esse setup permite que qualquer máquina na VPC da Vultr alcance máquinas no homelab, e vice-versa. Útil para monitoramento centralizado, acesso a bancos de staging a partir de ferramentas em produção, ou simplesmente para SSH entre ambientes.

Camadas de automação

Conectar os dois ambientes é só metade do problema. A outra metade é garantir que a infraestrutura seja reproduzível. Ninguém quer depender de um servidor que foi configurado manualmente há seis meses e que ninguém lembra como recriar.

Terraform: o que existe

O Terraform define o que existe na infraestrutura. No Proxmox, ele cria VMs a partir de templates Cloud-Init e containers LXC. Na Vultr, ele gerencia servidores, redes VPC e regras de firewall.

Um ponto importante: se a infraestrutura de produção já existia antes do Terraform (caso comum), é possível importá-la sem destruir nada. O fluxo é:

  1. Escrever definições aproximadas dos recursos existentes
  2. Executar terraform import para cada recurso
  3. Verificar que terraform plan não mostra destruições
  4. Usar lifecycle { ignore_changes } para atributos que forçam recriação (como os_id ou hostname na Vultr)

Isso permite codificar a infraestrutura existente de forma incremental, sem o risco de derrubar produção.

Ansible: como está configurado

O Ansible define como cada máquina está configurada. Instala Docker, configura firewall (UFW), gerencia chaves SSH, instala e configura o WireGuard. Enquanto o Terraform lida com o provisionamento (criar/destruir recursos), o Ansible lida com a configuração (o que roda dentro de cada recurso).

A separação é importante. O Terraform não sabe instalar pacotes. O Ansible não sabe criar VMs. Cada ferramenta faz o que faz bem, e o resultado é uma pipeline de provisionamento que vai de “nada” a “ambiente funcional” de forma automatizada:

Terraform (cria VM/LXC) → Ansible (configura SO, Docker, VPN) → Deploy (aplicação)

O que funciona e o que não funciona

Funciona bem

  • Processo de deploy idêntico: staging e produção usam o mesmo fluxo de deploy. Se o deploy funciona no staging, funciona em produção.
  • Migrações de banco: testar migrações com dados reais (anonimizados) antes de rodar em produção evita surpresas.
  • Custo zero de staging: o hardware do homelab já está lá. Não há custo adicional por mês.
  • Iteração rápida: VMs no Proxmox são criadas e destruídas em segundos. Errou a configuração? Destrói e recria.

Não funciona tão bem

  • Latência de rede: o homelab está na sua rede residencial. A latência entre staging e qualquer serviço externo é diferente da latência em produção (datacenter).
  • Disponibilidade: se a energia da sua casa cai, staging cai junto. Para staging, isso é aceitável. Para produção, não seria.
  • SSL e domínios: staging não tem certificado SSL nem domínio público. Testes que dependem de HTTPS ou webhooks externos precisam de workarounds.
  • Escala: o homelab tem recursos limitados. Se a aplicação precisa de testes de carga realistas, o homelab não vai reproduzir o comportamento de produção.

Nenhum desses pontos é um deal-breaker para staging. O objetivo não é replicar produção com 100% de fidelidade — é validar o que quebra com mais frequência: deploys, migrações e configuração de serviços.

Quando essa abordagem faz sentido

Essa arquitetura funciona bem em cenários específicos:

  • Times pequenos (1-5 pessoas) onde o custo de staging em cloud é proporcionalmente alto
  • Aplicações monolíticas ou com poucos serviços, onde replicar a stack é viável em hardware limitado
  • Equipes com conhecimento de infra, capazes de manter Terraform, Ansible e Proxmox
  • Projetos em fase inicial, onde o investimento em staging cloud não se justifica ainda

Não faz sentido quando:

  • A aplicação depende de serviços gerenciados da cloud (RDS, SQS, Lambda) que não têm equivalente local
  • O time não tem conhecimento de infraestrutura e a curva de aprendizado seria um gargalo
  • O ambiente de staging precisa estar disponível 24/7 para CI/CD automatizado (embora um no-break e IP fixo resolvam parte disso)

Considerações finais

Usar um homelab como staging não é a solução ideal para todo mundo. Mas para times pequenos que precisam de um ambiente de testes sem aumentar o custo mensal de infraestrutura, é uma abordagem pragmática que funciona na prática.

O ponto central não é o Proxmox, o Terraform ou o Ansible especificamente. É a ideia de que staging não precisa ser uma cópia perfeita de produção para ser útil. Precisa ser bom o suficiente para validar o que quebra com mais frequência — e barato o suficiente para não ser cortado no próximo corte de custos.

Referências