El problema: staging cuesta caro

Todo equipo que trabaja con software en producción necesita un ambiente de staging. Un lugar para probar deploys, validar migraciones de base de datos y simular escenarios de error antes de que lleguen al usuario final. El problema es que mantener un ambiente de staging en la cloud cuesta dinero real.

Un servidor de aplicación, una base de datos, un Redis, tal vez un worker de background — replicar el stack de producción en la cloud puede costar fácilmente entre US$ 50 y US$ 200 por mes, dependiendo del tamaño de la aplicación. Para una startup o consultoría pequeña, ese costo es difícil de justificar cuando el ambiente está ocioso la mayor parte del tiempo.

La alternativa más común es no tener staging. Hacer deploy directo a producción y cruzar los dedos. Funciona hasta el día que no funciona.

La decisión: dos datacenters, dos propósitos

La arquitectura que adoptamos separa la infraestructura en dos ambientes con propósitos distintos:

  • Proxmox en el homelab — funciona como datacenter de staging parcial. Ejecuta la aplicación, base de datos y servicios auxiliares en VMs y containers LXC provisionados localmente. Costo mensual adicional: cero (el hardware ya existe).
  • Vultr VPC — datacenter de producción. Servidores en Nueva York con red privada (VPC), backup automatizado e IP público. Costo predecible y escalable.

La palabra parcial es importante. El staging en el homelab no replica el 100% del ambiente de producción. No tiene SSL, no tiene el mismo volumen de datos, no tiene la misma latencia de red. Pero replica lo que importa para la mayoría de las pruebas: el proceso de deploy, la configuración de servicios, las migraciones de base de datos y el comportamiento de la aplicación con datos reales (anonimizados).

La arquitectura

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 — Producción (10.1.96.0/20)"]
    B1[app — VM]
    B2[backup — VM]
    B3[vpn / WireGuard — VM]
  end

  A2 <-->|"Túnel WireGuard (10.200.200.0/24)"| B3

Los dos ambientes viven en redes completamente separadas. El homelab usa la red residencial (192.168.15.0/24), Vultr usa una VPC privada (10.1.96.0/20). La conexión entre ellos es un túnel WireGuard que crea una subred virtual (10.200.200.0/24) accesible desde ambos lados.

En la práctica, esto significa que un servicio ejecutándose en el homelab puede acceder a recursos en Vultr (y viceversa) como si estuvieran en la misma red, con la latencia normal de internet.

El pegamento: WireGuard

WireGuard es lo que hace viable esta arquitectura. Es un protocolo VPN moderno, liviano y rápido que se ejecuta en el kernel de Linux. A diferencia de soluciones más pesadas como OpenVPN o IPSec, la configuración es mínima y el rendimiento es excelente.

El servidor WireGuard se ejecuta en Vultr (IP público, puerto fijo). El cliente se ejecuta en un container LXC en Proxmox — no se necesita una VM entera para eso. Proxmox 9+ ya tiene el módulo WireGuard en el kernel, así que un container LXC unprivileged es suficiente.

La configuración del peer en el homelab incluye PersistentKeepalive, necesario cuando el cliente está detrás de NAT residencial. Sin esto, el túnel se cae después de algunos minutos de inactividad.

Para que el tráfico fluya entre las redes (no solo entre los dos hosts del túnel), el servidor VPN necesita:

  1. ip_forward habilitado
  2. Reglas de iptables con MASQUERADE en la interfaz de la VPC
  3. Rutas estáticas en los demás hosts de la VPC apuntando a la IP del servidor VPN

Este setup permite que cualquier máquina en la VPC de Vultr alcance máquinas en el homelab, y viceversa. Útil para monitoreo centralizado, acceso a bases de datos de staging desde herramientas en producción, o simplemente para SSH entre ambientes.

Capas de automatización

Conectar los dos ambientes es solo la mitad del problema. La otra mitad es garantizar que la infraestructura sea reproducible. Nadie quiere depender de un servidor que fue configurado manualmente hace seis meses y que nadie recuerda cómo recrear.

Terraform: lo que existe

Terraform define lo que existe en la infraestructura. En Proxmox, crea VMs a partir de templates Cloud-Init y containers LXC. En Vultr, administra servidores, redes VPC y reglas de firewall.

Un punto importante: si la infraestructura de producción ya existía antes de Terraform (caso común), es posible importarla sin destruir nada. El flujo es:

  1. Escribir definiciones aproximadas de los recursos existentes
  2. Ejecutar terraform import para cada recurso
  3. Verificar que terraform plan no muestre destrucciones
  4. Usar lifecycle { ignore_changes } para atributos que fuerzan recreación (como os_id o hostname en Vultr)

Esto permite codificar la infraestructura existente de forma incremental, sin el riesgo de tumbar producción.

Ansible: cómo está configurado

Ansible define cómo cada máquina está configurada. Instala Docker, configura el firewall (UFW), administra llaves SSH, instala y configura WireGuard. Mientras Terraform maneja el provisionamiento (crear/destruir recursos), Ansible maneja la configuración (lo que se ejecuta dentro de cada recurso).

La separación es importante. Terraform no sabe instalar paquetes. Ansible no sabe crear VMs. Cada herramienta hace lo que hace bien, y el resultado es un pipeline de provisionamiento que va de “nada” a “ambiente funcional” de forma automatizada:

Terraform (crea VM/LXC) → Ansible (configura SO, Docker, VPN) → Deploy (aplicación)

Lo que funciona y lo que no

Funciona bien

  • Proceso de deploy idéntico: staging y producción usan el mismo flujo de deploy. Si el deploy funciona en staging, funciona en producción.
  • Migraciones de base de datos: probar migraciones con datos reales (anonimizados) antes de ejecutarlas en producción evita sorpresas.
  • Costo cero de staging: el hardware del homelab ya está ahí. No hay costo adicional por mes.
  • Iteración rápida: las VMs en Proxmox se crean y destruyen en segundos. ¿Configuración incorrecta? Destruir y recrear.

No funciona tan bien

  • Latencia de red: el homelab está en tu red residencial. La latencia entre staging y cualquier servicio externo es diferente de la latencia en producción (datacenter).
  • Disponibilidad: si se corta la luz en tu casa, staging se cae con ella. Para staging, esto es aceptable. Para producción, no lo sería.
  • SSL y dominios: staging no tiene certificado SSL ni dominio público. Pruebas que dependen de HTTPS o webhooks externos necesitan workarounds.
  • Escala: el homelab tiene recursos limitados. Si la aplicación necesita pruebas de carga realistas, el homelab no va a reproducir el comportamiento de producción.

Ninguno de estos puntos es un deal-breaker para staging. El objetivo no es replicar producción con 100% de fidelidad — es validar lo que se rompe con más frecuencia: deploys, migraciones y configuración de servicios.

Cuándo esta estrategia tiene sentido

Esta arquitectura funciona bien en escenarios específicos:

  • Equipos pequeños (1-5 personas) donde el costo de staging en cloud es proporcionalmente alto
  • Aplicaciones monolíticas o con pocos servicios, donde replicar el stack es viable en hardware limitado
  • Equipos con conocimiento de infra, capaces de mantener Terraform, Ansible y Proxmox
  • Proyectos en fase inicial, donde la inversión en staging cloud no se justifica todavía

No tiene sentido cuando:

  • La aplicación depende de servicios administrados de la cloud (RDS, SQS, Lambda) que no tienen equivalente local
  • El equipo no tiene conocimiento de infraestructura y la curva de aprendizaje sería un cuello de botella
  • El ambiente de staging necesita estar disponible 24/7 para CI/CD automatizado (aunque un UPS e IP fijo resuelven parte de eso)

Consideraciones finales

Usar un homelab como staging no es la solución ideal para todos. Pero para equipos pequeños que necesitan un ambiente de pruebas sin aumentar el costo mensual de infraestructura, es un enfoque pragmático que funciona en la práctica.

El punto central no es Proxmox, Terraform o Ansible específicamente. Es la idea de que staging no necesita ser una copia perfecta de producción para ser útil. Necesita ser lo suficientemente bueno para validar lo que se rompe con más frecuencia — y lo suficientemente barato para no ser eliminado en el próximo recorte de presupuesto.

Referencias