Contexto
En SherpApp necesitabamos entregar producto rapido sin hipotecar la arquitectura. El objetivo era claro:
- mantener costes controlados en etapa early,
- desplegar sin friccion en cada release,
- y tener observabilidad suficiente para dormir tranquilos.
Partiamos de una API en NestJS, frontend en Next.js y una base de datos con crecimiento progresivo.
Alternativas que evaluamos
Opcion A: plataforma full-managed desde dia uno
La ventaja era obvia: menos operacion interna. El problema era el coste recurrente y el lock-in temprano en un momento donde todavia estabamos validando producto y embudo comercial.
Opcion B: VPS simple sin contenedores
Rapida de arrancar, pero con riesgo de deriva de entorno. Cada deploy dependia mas del estado del servidor que del codigo versionado.
Opcion C: Docker + Hetzner + MongoDB (la elegida)
Fue el mejor equilibrio para nuestro caso:
- imagenes reproducibles con Docker,
- infraestructura predecible en Hetzner,
- persistencia flexible en MongoDB para evolucionar esquema sin frenar releases.
Decision tecnica
Definimos una estrategia de despliegue basada en contenedores inmutables:
- build de imagen en CI,
- versionado por tag,
- despliegue atomico por compose en servidor,
- rollback rapido al tag previo si detectamos degradacion.
Con esta base evitamos “works on my machine” y reducimos tiempo de incidente porque cada servicio tiene contrato operativo claro.
Trade-offs asumidos
No hay decisiones gratis. Estos fueron los costes que aceptamos:
- mas responsabilidad en operacion (backups, monitoreo, hardening),
- curva inicial de disciplina DevOps en el equipo,
- y mas trabajo de automatizacion que con un PaaS completo.
A cambio, ganamos control sobre coste, performance y topologia.
Resultado en produccion
En nuestros ciclos de iteracion, la combinacion funciono por tres motivos:
- despliegues consistentes entre entornos,
- tiempo de recuperacion mas corto ante fallos,
- y capacidad de ajustar recursos en funcion de uso real, no de supuestos.
Para una startup con foco en velocidad de aprendizaje, esta arquitectura nos dio una base robusta sin sobre-ingenieria.
Cuando repetiria (y cuando no)
Lo repetiria en productos con estas condiciones:
- equipo tecnico con criterio para operar infraestructura,
- necesidad de controlar burn rate,
- roadmap con cambios frecuentes de producto.
No lo repetiria si el equipo no puede absorber operacion o si la prioridad absoluta es reducir al minimo cualquier carga infra desde el dia uno.
El punto no es “Docker/Hetzner/MongoDB siempre”, sino elegir el stack que mejor encaje con la etapa del negocio y la capacidad real del equipo.