La fiebre por crear productos con ayuda de Claude, Cursor, Gemini o Codex ha traído una escena curiosa al mundo sysadmin: aplicaciones que nacen en horas, pero llegan a producción con decisiones de infraestructura tomadas a golpe de prompt. Y ahí aparece un patrón bastante repetido. Cuando se le pide a un agente que monte una solución “escalable” y “con buenas prácticas”, la respuesta suele incluir Docker, Terraform, CI/CD, observabilidad, Helm y, a poco que uno no vigile, también Kubernetes. La arquitectura queda impecable en el README, pero no siempre encaja con el tamaño real del proyecto.
En la práctica, buena parte de los productos pequeños y medianos no necesitan ese nivel de complejidad para funcionar bien en producción. Docker Compose sigue siendo una opción válida más allá del desarrollo local, Kamal ha ganado protagonismo como vía simple para desplegar contenedores en máquinas propias con zero-downtime, y Terraform sigue siendo la pieza más razonable cuando se quiere describir infraestructura como código y mantener una salida relativamente limpia de un proveedor concreto. La discusión real ya no es si hay que usar cloud o no, sino cuánto lock-in conviene aceptar y cuánta portabilidad merece la pena pagar por adelantado.
La regla de oro: abstracción parcial y lock-in selectivo
La experiencia operativa en 2026 sigue apuntando a una conclusión bastante poco épica, pero muy útil: intentar construir una “nube totalmente portable” desde el primer día suele salir más caro en tiempo, complejidad y deuda operativa que aceptar cierto lock-in bien elegido. Terraform ayuda precisamente a gestionar ese equilibrio porque permite definir y versionar recursos de infraestructura —desde cómputo y red hasta DNS o integraciones SaaS— y trabajar con distintos proveedores desde una misma lógica de infraestructura como código. La propia documentación de HashiCorp lo plantea como una herramienta para automatizar infraestructura “en cualquier cloud”, y sus tutoriales oficiales parten de AWS, Azure, Google Cloud, Oracle o incluso Docker.
Eso no significa que todas las piezas deban abstraerse igual. Tiene sentido encapsular cómputo, red, DNS, firewalls, variables y despliegues, porque migrar esas capas suele ser viable con un esfuerzo razonable. En cambio, asumir cierto acoplamiento en servicios gestionados como base de datos, object storage, CDN o WAF puede salir mucho más rentable si ahorra semanas de trabajo a un equipo pequeño. Cloudflare, por ejemplo, actúa como proveedor DNS y reverse proxy, y su WAF filtra tráfico HTTP y API con reglas gestionadas y personalizadas; usarlo no elimina el lock-in, pero sí reduce superficie operativa real.
Cuando Compose sigue siendo suficiente
Uno de los errores más frecuentes en proyectos nacidos con IA es despreciar demasiado pronto a Docker Compose por considerarlo “solo para desarrollo”. La documentación oficial de Docker es mucho más amplia: Compose define y ejecuta aplicaciones multi-contenedor a partir de un único archivo YAML y funciona en producción, staging, desarrollo, testing y flujos CI. No es un orquestador distribuido al estilo Kubernetes, pero para una aplicación con backend, frontend, base de datos, Redis, workers y proxy, sigue siendo una solución perfectamente válida si la carga y la topología lo permiten.
Su gran ventaja para sysadmins es que reduce fricción. Permite versionar el stack, reproducir entornos y entender de un vistazo qué corre y cómo se relaciona. Si se combina con un proxy como Traefik delante, se obtiene enrutado, service discovery y una puerta de entrada limpia para añadir más piezas después. Traefik se define oficialmente como un application proxy open source y, para muchos despliegues pequeños o medianos, da justo el punto de automatización y flexibilidad que se necesita sin arrastrar la complejidad completa de un ingress controller en Kubernetes.
Kamal, la opción intermedia que cada vez tiene más sentido
Kamal se está consolidando como una de las respuestas más interesantes al exceso de complejidad en despliegues modernos. Su propuesta es muy simple: desplegar aplicaciones contenedorizadas en bare metal o cloud VMs usando Docker y SSH, con zero-downtime deploys, rolling restarts, builds remotos y gestión de servicios auxiliares. La web oficial insiste además en uno de sus argumentos más atractivos para perfiles sysadmin: evitar quedar atrapado demasiado pronto en plataformas comerciales más caras o en Kubernetes gestionado si todavía no hace falta.
Eso convierte a Kamal en una opción muy razonable para equipos que quieren control sin caer en el bricolaje puro de scripts bash y despliegues manuales. No sustituye a un orquestador completo en todos los escenarios, pero sí cubre muy bien un espacio intermedio: máquinas propias o VPS, contenedores bien definidos, despliegues repetibles y una operativa más limpia que la de un docker compose up manual en producción.
Tabla rápida de decisiones para sysadmins
A la hora de elegir stack, el criterio más útil no suele ser “qué usa la élite DevOps”, sino qué necesita realmente el producto durante los próximos 12 o 18 meses.
┌──────────────────────────────┬───────────────────────────────┬────────────────────────────┬──────────────────────────────┐
│ Escenario │ Opción recomendada │ Ventaja principal │ Riesgo principal │
├──────────────────────────────┼───────────────────────────────┼────────────────────────────┼──────────────────────────────┤
│ MVP muy rápido │ Vercel / Railway / Render │ Velocidad de salida │ Menor control / más lock-in │
│ SaaS pequeño o mediano │ Docker + Compose + Terraform │ Simplicidad y coste │ Operación manual creciente │
│ SaaS pequeño con más mimo │ Kamal + Terraform + Traefik │ Zero-downtime sin K8s │ Menos ecosistema que K8s │
│ Backend multi-servicio │ Nomad + Terraform │ Scheduler más simple │ Menor estandarización │
│ Plataforma interna compleja │ Kubernetes + Helm + IaC │ Escalado y estandarización │ Sobrecoste operativo │
└──────────────────────────────┴───────────────────────────────┴────────────────────────────┴──────────────────────────────┘
Y si se quiere bajar eso a proveedores concretos, la fotografía actual queda bastante clara:
| Opción | Qué ofrece | Cuándo encaja mejor | Nivel de lock-in |
|---|---|---|---|
| Vercel | Despliegue desde Git, preview environments, foco fuerte en apps web y cargas IA | Frontends, SaaS web, equipos que priorizan velocidad | Alto |
| Railway | Plataforma todo en uno, CLI, despliegue rápido, entornos, dominios, volúmenes y API | Proyectos pequeños y medianos que quieren ir rápido | Medio-alto |
| Render | Servicios web, bases de datos, jobs, previews, rollbacks y monitorización | Equipos que quieren PaaS con algo más de amplitud | Medio-alto |
| Hetzner Cloud | Cloud servers, redes privadas, firewalls, API, Terraform/Kubernetes integrations y buen coste de tráfico | Equipos que quieren control y coste ajustado | Bajo-medio |
| AWS / Azure / GCP | Máximo catálogo de servicios y ecosistema | Productos complejos o corporativos | Variable, según servicios usados |
Hetzner, Cloudflare y Traefik: la receta pragmática europea
Una combinación que se repite cada vez más en equipos pequeños y medianos es Hetzner para cómputo, Cloudflare para DNS, SSL y WAF, y Traefik como proxy interno. La lógica es bastante evidente. Hetzner ofrece API, integraciones con Terraform y Kubernetes, redes privadas, firewalls sin coste adicional y una política de tráfico que la propia compañía compara favorablemente frente a los hiperescalares. Además, su oferta de localizaciones en Europa y su foco en GDPR lo convierten en una opción especialmente atractiva para proyectos europeos.
Sobre esa base, Cloudflare añade la capa edge más cómoda para muchos equipos: DNS, reverse proxy, CDN y WAF. Y Traefik resuelve la entrada a servicios internos sin necesidad de montar una plataforma mucho más pesada. El resultado no es “cloud agnóstico” en sentido puro, pero sí una arquitectura con suficientes capas abstraídas como para que cambiar de VPS o de cloud no obligue a reescribir el producto entero.
¿Y cuándo sí toca Kubernetes?
Kubernetes sigue siendo la referencia cuando se necesita un scheduler distribuido, pods, controllers y un modelo operativo preparado para varios equipos, múltiples servicios, autoescalado y un gobierno más fuerte del ciclo de vida de los workloads. La documentación oficial deja claro que las aplicaciones en Kubernetes se ejecutan dentro de pods y se gestionan mediante recursos superiores que mantienen el estado deseado. Esa potencia tiene sentido, pero no es gratis: exige más conocimiento, más observabilidad, más disciplina operativa y más tiempo de mantenimiento.
Por eso, en un medio de administración de sistemas, la recomendación más honesta sigue siendo esta: Kubernetes no es una señal de madurez por sí solo. Solo merece la pena cuando la complejidad del producto ya lo justifica. Antes de eso, Compose, Kamal o incluso Nomad pueden resolver mejor la ecuación entre coste, simplicidad y control. Nomad, de hecho, se define oficialmente como un scheduler distribuido y altamente disponible para servicios de larga duración, batch jobs y otros workloads modernos, con una superficie conceptual menor que Kubernetes en muchos despliegues.
La mejor arquitectura para una app nacida con IA no es la más impresionante sobre el papel. Es la que permite desplegar bien hoy, hacer rollback rápido mañana y seguir creciendo sin que la infraestructura se convierta en el producto principal. En ese equilibrio, la contenedorización ya no es la duda. La duda real es cuánta orquestación hace falta de verdad.
Preguntas frecuentes
¿Docker Compose sirve para producción o solo para desarrollo?
La documentación oficial de Docker indica que Compose funciona en producción, staging, desarrollo, testing y CI, además de definir y ejecutar aplicaciones multi-contenedor desde un único archivo YAML.
¿Kamal puede sustituir a Kubernetes en un SaaS pequeño?
En muchos casos sí. Kamal ofrece despliegues zero-downtime, rolling restarts y gestión de servicios auxiliares sobre Docker y SSH, lo que lo convierte en una opción muy válida para productos pequeños y medianos sin la complejidad operativa de Kubernetes.
¿Qué ventaja tiene Terraform frente a configurar todo a mano en un proveedor?
Terraform permite definir, cambiar y versionar infraestructura como código, incluyendo cómputo, red, almacenamiento, DNS y componentes SaaS, y está pensado para trabajar con múltiples clouds y proveedores.
¿Hetzner es una alternativa seria para staging y producción?
Sí. Hetzner Cloud ofrece servidores, redes privadas, firewalls, API y compatibilidad con herramientas como Terraform o Kubernetes, además de un enfoque muy competitivo en tráfico incluido y despliegues en Europa y otros mercados.
