Hosting Docker Compose. Twój compose, nasz serwer.

1. Docker como tipo de aplicación, no como producto adicional

Muchos proveedores de hosting consideran Docker una función reservada para planes VPS más caros o servicios cloud, porque requiere más aislamiento y control que un hosting compartido típico. En Saplo, Docker es simplemente un tipo de aplicación del catálogo, igual que WordPress o un sitio web estático, sin un umbral de precio adicional por el simple hecho de ejecutar contenedores.

En la práctica, 152 de 166 aplicaciones del catálogo de Saplo usan Docker internamente, por lo que el motor de contenedores funciona en cada Box con Docker, independientemente de si el cliente instala una configuración lista para usar del catálogo o monta su propia imagen personalizada.

Para una imagen Docker propia, existe el tipo de aplicación custom, donde puedes indicar tu propio Dockerfile o docker-compose sin limitarte a las recetas listas del catálogo, lo que ofrece total libertad para proyectos a medida.

2. Registro privado de imágenes sin coste adicional

El catálogo de aplicaciones también incluye Docker Registry: un registro privado de imágenes (imagen oficial registry:2) con una interfaz sencilla para explorar repositorios, tags y capas desde el navegador, protegido con basic auth y un usuario y una contraseña generados aleatoriamente durante la instalación.

Para un equipo que construye sus propias imágenes en CI/CD, esto significa que puedes guardar imágenes privadas sin una cuenta en Docker Hub ni los límites de pull rate que las cuentas gratuitas de los registros públicos imponen a las descargas frecuentes de imágenes durante los despliegues.

La interfaz del registro funciona como proxy inverso hacia la API del mismo registro, bajo un único dominio y sin CORS, por lo que docker login, docker push y docker pull funcionan directamente bajo el dominio de la aplicación, sin configurar puertos adicionales por separado.

3. Cuánta RAM necesitan las aplicaciones Docker

Las aplicaciones Docker típicas del catálogo de Saplo suelen declarar una memoria mínima de entre 1 y 2 GB de RAM (Baserow, Chatwoot, Flowise, n8n, Windmill y Typebot, entre 1 y 2 GB), porque el contenedor de una imagen oficial suele incluir más dependencias que una instalación ligera de PHP o una aplicación estática sencilla.

Box M (2 GB de RAM) permite alojar cómodamente una aplicación Docker típica. Box L (6 GB de RAM) permite ejecutar varias aplicaciones Docker en paralelo. Al montar un conjunto mayor de herramientas (CRM, chat y automatización a la vez), esta capacidad representa el mínimo realista para evitar que compitan por la memoria. Si necesitas un conjunto aún mayor, conviene considerar Box XL, donde 12 GB de RAM ofrecen un margen real para seguir ampliando las herramientas sin tener que comprobar a menudo qué aplicación ocupa más memoria en cada Box.

Para tus propias imágenes Docker no estándar (tipo custom), los requisitos de RAM dependen de lo que la imagen haga realmente, así que conviene medir el consumo de memoria localmente antes de elegir un Box, igual que en cualquier otro despliegue con contenedores.

4. Docker en Saplo frente a Docker en un VPS autogestionado

En un VPS vacío, tienes que instalar Docker por tu cuenta, configurar el firewall para los puertos de los contenedores y configurar manualmente un proxy inverso con SSL para cada servicio que pongas en marcha. Para alguien que no esté familiarizado con la administración de Linux, esto supone una barrera real para empezar.

En Saplo, el contenedor LXC del Box ya tiene configurado el soporte para Docker (keyctl, nesting), por lo que docker run o docker compose up funcionan de inmediato tras iniciar sesión por SSH. El panel configura el proxy inverso y el SSL de las aplicaciones públicas al conectar un dominio.

Con recursos similares, la diferencia de coste entre un VPS autogestionado y un Box con Docker suele ser pequeña, pero el tiempo necesario para lanzar el primer servicio es mucho menor en Saplo, ya que no tienes que configurar el motor de contenedores desde cero.

5. Para quién es ideal

Si eres desarrollador y quieres desplegar tu propia imagen Docker sin montar un VPS desde cero, el tipo de aplicación custom de un Box M o L te ofrece un entorno listo para usar con soporte de Docker y SSL automático para el dominio conectado.

Para tu equipo, el Docker Registry privado del catálogo de aplicaciones te evita depender de una cuenta en un registro público y de sus límites de pull rate.

Si pruebas varias aplicaciones Docker del catálogo a la vez (por ejemplo, CRM, chat y automatización), un Box L con 6 GB de RAM te da espacio para ejecutar varias en paralelo sin que compitan por la memoria.

6. Primer despliegue de tu propia imagen Docker en Saplo

Después de elegir el tipo de aplicación custom, conéctate por SSH (disponible desde Box M) y prepara un docker-compose.yml o un Dockerfile para tu proyecto, igual que en cualquier otro entorno con Docker instalado.

Una vez conectado el dominio, configura desde el panel de Saplo el proxy inverso y el SSL del servicio público. Indica el puerto en el que escucha tu contenedor, sin configurar manualmente nginx ni el certificado.

Configura los volúmenes de datos (volumes) para que los datos de la aplicación sobrevivan a un reinicio del contenedor y estén incluidos en las copias de seguridad del Box, siempre que el plan que uses las incluya.

Para aplicaciones con varios contenedores (por ejemplo, una base de datos, una aplicación y un worker en un solo docker-compose), comprueba que la suma de la RAM de todos los contenedores quepa en el límite del Box elegido antes de iniciar todo el stack a la vez.

El Docker Registry privado del catálogo de aplicaciones te permite guardar tus propias imágenes compiladas y luego descargarlas en el Box con docker pull usando el mismo dominio, sin depender de una cuenta en un registro público.

7. CI/CD y compilación automática de imágenes Docker

El flujo CI/CD habitual consiste en compilar la imagen en un sistema externo (GitHub Actions, GitLab CI), subirla al Docker Registry privado de Saplo y después ejecutar docker pull y reiniciar el contenedor en el Box de producción.

Puedes automatizar el último paso (pull y reinicio tras desplegar una nueva imagen) con un script sencillo ejecutado por SSH o con un webhook que active un flujo de trabajo en n8n instalado en el mismo Box.

Un registro privado de imágenes elimina los límites de pull rate que imponen las cuentas gratuitas en los registros públicos. Con despliegues frecuentes (varias veces al día), esto puede convertirse en un problema real para las cuentas sin un plan de pago de un proveedor externo.

Para los equipos que trabajan en varios entornos (staging, producción), puedes mantener etiquetas distintas para las imágenes en el mismo registro privado, lo que facilita controlar qué versión de la aplicación se ejecuta en cada entorno.

8. Buenas prácticas al usar tus propias imágenes Docker en producción

Fijar una versión concreta de la imagen base (por ejemplo, node:20.11-alpine y no node:latest) evita que una actualización de la imagen base publicada por el proveedor cambie de forma inesperada el comportamiento de tu aplicación tras la siguiente recompilación del contenedor, a menudo sin un aviso claro.

La compilación en varias etapas (multi-stage build) permite mantener pequeña la imagen final de producción, sin herramientas de compilación ni dependencias de desarrollo. Esto acelera la transferencia de la imagen al registro y del registro al servidor de producción, y reduce la superficie de ataque del contenedor.

Las variables de entorno y los secretos (contraseñas, claves API) nunca deben incluirse directamente en una imagen Docker como valores escritos en el Dockerfile, sino pasarse al contenedor en tiempo de ejecución, ya que una imagen construida con un secreto dentro puede llegar a un registro y ser restaurada desde allí por cualquier persona con acceso a ese registro.

Un healthcheck configurado en la imagen o en docker-compose permite detectar automáticamente que el contenedor está en marcha, pero que la aplicación que contiene ha dejado de responder, por ejemplo, si un proceso se ha bloqueado. Sin healthcheck, el problema podría pasar desapercibido porque el contenedor seguiría activo en teoría.

Conviene enviar los logs del contenedor a la salida estándar (stdout/stderr), no a archivos dentro del contenedor. Los logs guardados en archivos se pierden cuando se elimina el contenedor, mientras que los de la salida estándar se pueden recopilar y consultar más fácilmente con las herramientas estándar de Docker.

Revisar periódicamente qué imágenes y etiquetas del registro privado siguen en uso ayuda a mantener todo organizado y liberar el espacio en disco que ocupan las versiones antiguas, ya innecesarias tras sucesivos despliegues de CI/CD.

9. El ecosistema de Docker Hub y las imágenes de la comunidad como punto de partida

La enorme cantidad de imágenes Docker oficiales y listas para usar disponibles públicamente (bases de datos, servidores de aplicaciones, herramientas auxiliares) permite desplegar la mayoría de los servicios habituales en Saplo sin escribir un Dockerfile desde cero, aprovechando imágenes ya probadas y mantenidas activamente.

El catálogo de aplicaciones de Saplo incluye configuraciones listas basadas en muchas de esas imágenes oficiales (por ejemplo, prestashop/prestashop, n8nio/n8n, flowiseai/flowise). Para el cliente, esto significa que ni siquiera necesita saber que la aplicación funciona en Docker, porque toda la configuración ya está preparada.

Para necesidades propias y a medida (tipo de aplicación custom), el acceso al ecosistema completo de Docker Hub y a otros registros públicos de imágenes permite utilizar imágenes listas como punto de partida y adaptarlas a tus necesidades mediante un Dockerfile propio basado en una imagen base.

El Docker Registry privado del catálogo de aplicaciones de Saplo completa este ecosistema y ofrece un lugar para guardar tus propias imágenes compiladas sin necesidad de publicarlas en Docker Hub, algo que puede ser un requisito de seguridad importante en proyectos comerciales de código cerrado.

Para los equipos técnicos que siguen la evolución del ecosistema de contenedores (nuevas herramientas de orquestación, nuevas prácticas de compilación de imágenes), el acceso SSH completo al contenedor LXC del Box con soporte de Docker en Saplo no impone restricciones frente a lo que puedes hacer en un servidor clásico con Docker que administras por tu cuenta.

10. Pruebas de imágenes Docker antes de desplegarlas en producción

Conviene probar una imagen Docker nueva de forma local o en un contenedor temporal del mismo Box antes de sustituir el contenedor de producción que está funcionando, ya que un error en la nueva imagen (por ejemplo, una versión incompatible de una dependencia) puede dejar el servicio indisponible hasta que se revierta el cambio.

Etiquetar las imágenes del registro privado con una versión, y no solo con latest, te permite volver fácilmente a la versión anterior que funcionaba si la nueva versión causa problemas tras el despliegue en producción.

En aplicaciones con varios contenedores (docker-compose con una base de datos, la aplicación y un worker), conviene probar el cambio completo como un conjunto, no solo el contenedor modificado. Las incompatibilidades de versión entre contenedores conectados son una causa habitual de problemas que no aparecen al probar un único elemento de forma aislada.

Un healthcheck configurado en la imagen ayuda a detectar automáticamente que el nuevo contenedor no funciona correctamente tras el despliegue. Junto con un script sencillo para volver a la etiqueta anterior de la imagen, esto te permite revertir rápidamente un cambio problemático sin una larga interrupción del servicio. Este sencillo mecanismo de pruebas y reversión, aunque no sea un sistema CI/CD completo, ya reduce significativamente el riesgo de una interrupción prolongada causada por un único despliegue sin probar correctamente.

11. Resumen: Docker es un estándar, no una función premium

Tratar Docker como un elemento de infraestructura estándar, disponible en cada Box y no como una función reservada para los planes más altos y caros, refleja lo habitual que se ha vuelto este método de empaquetar aplicaciones en los últimos años. Elijas una plantilla del catálogo o despliegues una imagen personalizada mediante una aplicación de tipo custom, el motor de contenedores ya está configurado y listo para funcionar desde el primer día en tu Box. Para los equipos técnicos habituados a trabajar con Docker en sus propias máquinas de desarrollo, migrar a Saplo no exige cambiar los hábitos, sino trasladar el mismo método de trabajo al entorno de producción, con el soporte de dominios y certificados SSL ya integrado.