Docker hosting: ¿dónde debería correr realmente tu contenedor?

La verdadera pregunta no es el precio

Comparar la factura de un VPS con la suscripción de una plataforma responde a la pregunta equivocada. Todas las opciones pueden ejecutar tu contenedor; lo que cambia es cuánta de tu atención te siguen pidiendo después del primer despliegue.

Un contenedor en producción necesita un dominio y un certificado que se renueve solo, una forma de reiniciarse cuando se cae, algún sitio al que vayan los logs, un plan para actualizar sin caídas y una base de datos con copias de seguridad. Nada de eso es trabajo de Docker. Quién se encarga de ello es lo que en realidad estás eligiendo — y la comparación honesta pone precio a tus horas, no solo al servidor.

Opción 1 — un VPS que gestionas tú

Alquilas una máquina virtual, instalas Docker y ejecutas tu contenedor. Es el camino más directo y funciona de verdad, con acceso root completo y sin ninguna abstracción entre tú y la máquina.

Entonces empieza el trabajo permanente: actualizaciones de seguridad del sistema, un proxy inverso delante, certificados que hay que renovar, una política de reinicio para cuando el contenedor muera a las 4 de la mañana, el disco que se llena de logs e imágenes que nadie ha limpiado, y copias de seguridad que configuras y — esto es clave — pruebas. Un despliegue es tu propio script, y el cero downtime es algo que construyes tú mismo.

Elige esto cuando quieras root, cuando estés aprendiendo cómo encajan las piezas, o cuando ya administres servidores y uno más sea marginal. Evítalo cuando tu producto sea la aplicación y no la infraestructura que hay debajo.

Opción 2 — Kubernetes

Kubernetes resuelve problemas reales: muchos servicios, despliegues progresivos, autorreparación, autoescalado. Si operas decenas de servicios con un equipo, su complejidad se gana el sitio.

Por debajo de esa escala la proporción se invierte. Estás manteniendo un clúster, sus actualizaciones, su ingress, sus certificados y su YAML para ejecutar un puñado de contenedores — y el clúster se convierte en un sistema que exige experiencia propia. Un Kubernetes gestionado quita parte de eso, pero no el peso conceptual.

Elígelo cuando tu escala o tu equipo ya lo exijan. No lo elijas porque sea lo que usan las empresas serias; la seriedad está en ajustar la herramienta al tamaño del problema.

Opción 3 — una plataforma gestionada de contenedores

Aquí entregas el contenedor y la plataforma lo ejecuta: un dominio con HTTPS automático, reinicios, logs, un despliegue condicionado por healthcheck, y Postgres, Redis o almacenamiento compatible con S3 gestionados y conectados cuando los necesites.

En cdn.com.tr un despliegue arranca el contenedor nuevo, espera a que tu ruta de healthcheck indique que está listo, y entonces desvía el tráfico y retira el antiguo — así una build rota nunca deja el servicio fuera de línea, porque el tráfico simplemente se queda en la versión que sigue funcionando. La CDN edge se sitúa delante, con WAF y protección DDoS incluidos.

La contrapartida es real y conviene decirla: no hay root en el host, no hay instalación de paquetes a nivel de sistema operativo, y el acceso público es HTTP(S) en lugar de puertos TCP arbitrarios. Si tu aplicación necesita algo que la plataforma no expone, un VPS es la respuesta honesta.

Tres formas de entrar, según lo que tengas

La ruta correcta depende de dónde venga tu imagen.

Si ya construyes y subes imágenes a un registro, usa Container Apps: le das la referencia de la imagen y el puerto, y la despliega. Nada más cambia en tu pipeline.

Si quieres push-to-deploy desde el código fuente, usa GitHub Deploy. Se encarga del paso de build por ti — tu Dockerfile se construye en un builder aislado y se sube a nuestro registro privado, así que no necesitas ninguna cuenta de registro propia. Haces push a tu rama y la nueva versión sale detrás del healthcheck.

Si tu aplicación son varios servicios, usa Docker Compose Instant Deploy. Los servicios con una sección build: se construyen desde su Dockerfile; los servicios que referencian una image: pública (bases de datos, cachés, colas) se conectan como add-ons gestionados o como apps. Se respetan las builds multi-etapa, target: y build.args. Previsualiza el plan antes de que se cree nada, y luego aplícalo.

Previsualiza en qué se convertiría un archivo compose y después aplícalo

# see the plan first — nothing is created
cdnctl container compose preview --account <uuid> --file docker-compose.yml

# apply it when the plan looks right
cdnctl container compose apply --account <uuid> --file docker-compose.yml

Qué comprobar antes de comprometerte

Vayas por donde vayas, las preguntas que vale la pena hacer son las mismas. ¿Cómo se despliega una versión nueva — una build fallida tira el sitio, o el tráfico se queda en la última versión buena? ¿Dónde van los logs, y puedes leerlos sin SSH? ¿Qué pasa con tus datos: la base de datos está gestionada y respaldada, o es un contenedor sobre un disco del que respondes tú? ¿Puedes salir — tu imagen es portable, o te han reescrito hacia algo propietario?

Esa última pregunta es la que la gente se salta y luego lamenta. Una imagen Docker construida desde tu propio Dockerfile es portable por construcción: funciona igual en un VPS, en Kubernetes y en una plataforma gestionada. Mantenerla así es lo que hace que la decisión sea reversible.