Categoría: PaaS y contenedores
Dokploy gestionado: despliegues con Docker Swarm en vuestros servidores
Despliegues desde Git o con Docker Compose repartidos entre varios servidores, con alguien que cuida el clúster de Swarm, las copias y las actualizaciones del panel.
- Dónde se monta
- En vuestra cuenta, a vuestro nombre
- Copias
- Con restauración probada
- Actualizaciones
- Planificadas y documentadas
- Licencia
- Apache 2.0, salvo su carpeta propietaria
En resumen
Dokploy es un panel de despliegue de código abierto que se apoya en Docker, Docker Swarm y Traefik para publicar aplicaciones, bases de datos y proyectos de Docker Compose en vuestros servidores. Lo instalamos en vuestra cuenta, organizamos los nodos del clúster, programamos copias de bases de datos y volúmenes que restauramos en pruebas, protegemos el panel y lo mantenemos al día.
¿Qué nos encargamos de mantener?
Dokploy se instala con un solo comando y en una tarde tenéis aplicaciones publicadas. Lo que viene después es lo que se olvida: nodos que nadie actualiza, volúmenes sin copia, un manager de Swarm solo y el panel abierto con una contraseña compartida. Esto es lo que dejamos bajo control:
Panel
Dokploy en su propio servidor, con acceso restringido, doble factor y permisos por proyecto.
Clúster de Swarm
Managers y workers con quórum, etiquetas de nodo y restricciones para que cada servicio caiga donde debe.
Despliegues
Aplicaciones desde Git, imágenes y proyectos de Compose con variables ordenadas y vuelta atrás.
Copias
Bases de datos y volúmenes copiados a S3 en otra ubicación, con restauración ensayada.
Traefik
Certificados que se renuevan solos, dominios y cabeceras de seguridad.
Alertas
Despliegues fallidos, servicios sin réplicas sanas, disco de los nodos y certificados a punto de caducar.
¿Cómo lo montamos en varios servidores?
La instalación por defecto deja el panel, Traefik y las aplicaciones en la misma máquina. Para producción con más de un servidor, lo repartimos así:
Servidor del panel
Ejecuta Dokploy y su base de datos interna. Pequeño y sin tráfico público salvo el acceso al panel, por VPN o por IP.
Managers de Swarm
Tres nodos manager para que el clúster mantenga el quórum si uno cae; con uno solo, su caída deja el clúster sin gobierno.
Workers
Los nodos que ejecutan las aplicaciones, con etiquetas para separar lo que necesita disco rápido o más memoria.
Datos fuera de los nodos
Bases de datos en un nodo fijado o en el servicio gestionado del proveedor, y copias a S3 en otra cuenta.
Swarm reparte réplicas de servicios sin estado con mucha facilidad. Las bases de datos son otra historia: un volumen local no viaja con el contenedor a otro nodo, así que las fijamos a una máquina concreta o las sacamos del clúster.
¿Qué problemas encontramos más a menudo?
- Un único manager: si esa máquina cae, los servicios siguen, pero no se puede desplegar ni recolocar nada.
- Bases de datos que saltan de nodo: Swarm mueve el contenedor y arranca con un volumen vacío en otra máquina.
- Compose con puertos publicados: bases de datos accesibles desde internet porque el archivo original las exponía.
- Copias activadas sin destino externo o sin una sola restauración de prueba.
- Disco lleno de imágenes y registros de contenedores en los workers.
- Panel en la misma máquina que las aplicaciones y con un usuario para todo el equipo.
¿Cómo hacemos las copias y las actualizaciones?
Configuramos en Dokploy un destino compatible con S3 en otra cuenta o en otro proveedor y programamos las copias de cada base de datos y de los volúmenes que guardan datos. Periódicamente restauramos una en un servicio aparte y comprobamos que los datos están; el tiempo que tarda va al informe. El panel tiene su propia copia, que guardamos fuera del servidor para poder reconstruirlo en otra máquina sin tocar lo que ya está publicado.
Las versiones del panel las leemos antes de aplicarlas y, cuando el cambio es grande, las probamos primero en un entorno de ensayo. Docker y el sistema operativo de los nodos se actualizan nodo a nodo: drenar, parchear, reiniciar y devolver al clúster, para que las réplicas sigan sirviendo mientras tanto.
¿Para quién tiene sentido?
- Un equipo de producto con varias aplicaciones y APIs que quiere desplegar con un push sin montar Kubernetes.
- Una empresa que ya trabaja con Docker Compose y necesita pasar de un servidor a varios sin rehacer sus archivos.
- Quien sale de un PaaS de pago y quiere servidores a su nombre, con alguien que responda de las copias y del clúster.
Si comparáis con Coolify o planeáis salir de Heroku o Vercel, lo contamos en Coolify y Dokploy gestionados. Si el número de servicios crece mucho o necesitáis autoescalado, quizá os encaje mejor Kubernetes en Hetzner.
¿Cómo protegemos el panel y el clúster?
Quien entra en Dokploy puede desplegar, leer variables de entorno y borrar bases de datos, así que el panel va detrás de una VPN o con acceso por IP, con doble factor y un usuario por persona. Los puertos de gestión de Swarm solo escuchan en la red privada, los nodos aceptan SSH únicamente con clave y el cortafuegos cierra al exterior todo lo que no sea Traefik. Los secretos van en las variables del panel o en un gestor de secretos, nunca en el repositorio.
- GitPush, webhook o imagen
- DokployPanel en su servidor
- Docker SwarmNodos manager y worker
- TraefikHTTPS y dominios
- CopiasBases de datos y volúmenes a S3
¿Dónde lo montamos?
En vuestra cuenta, en el proveedor que ya uséis o en el que mejor encaje. Si los datos tienen que quedarse en la UE, Hetzner y OVHcloud son las opciones europeas.
Proveedores en los que lo montamos
- Hetzner
- AWS
- Google Cloud
- DigitalOcean
- OVH
- Servidor propio
| Proveedor | Cómo lo montamos | A tener en cuenta |
|---|---|---|
| Hetzner | Un servidor cloud pequeño para el panel y varios para el clúster de Swarm, unidos por red privada. Copias en Object Storage de Hetzner, compatible con S3. | El tráfico entre nodos de Swarm va por la red privada; solo Traefik queda expuesto. |
| AWS | Instancias EC2 en una VPC para el panel y los nodos, con copias en un bucket de S3. | Si ya usáis RDS, las aplicaciones pueden conectarse a él en lugar de a bases de datos en contenedor. |
| Google Cloud | Máquinas de Compute Engine y copias en Cloud Storage a través de su acceso compatible con S3. | |
| DigitalOcean | Droplets en una VPC para el panel y los nodos, con copias en Spaces. | |
| OVH | Instancias de Public Cloud con red privada y copias en Object Storage de OVHcloud. | |
| Servidor propio | Dokploy y los nodos de Swarm en vuestros servidores físicos o máquinas virtuales. | Para publicar a internet usamos un proxy o un túnel delante; no abrimos los puertos de gestión de Swarm. |
Qué incluye
- Panel de Dokploy en un servidor propio, separado de las cargas, en vuestra cuenta y a vuestro nombre.
- Servidores remotos o nodos de Docker Swarm añadidos al panel, con etiquetas para decidir qué corre dónde.
- Aplicaciones desplegadas desde Git, desde una imagen o desde un docker-compose.yml, con variables de entorno ordenadas por entorno.
- Traefik con certificados HTTPS automáticos y dominios propios para cada servicio.
- Copias programadas de bases de datos y volúmenes a un destino compatible con S3, restauradas en pruebas.
- Copia del propio panel y de su base de datos interna, guardada fuera del servidor.
- Acceso al panel restringido, doble factor y usuarios por persona con permisos por proyecto.
- Actualizaciones del panel leídas y ensayadas, y servidores con parches, Docker al día y disco vigilado.
Preguntas frecuentes
¿Necesitamos Docker Swarm para usar Dokploy?
No. Dokploy funciona con un único servidor o con varios servidores remotos gobernados por SSH, cada uno por su cuenta. Swarm entra cuando queréis repartir réplicas de un mismo servicio entre varios nodos y que se recoloquen solas si uno cae. Lo proponemos cuando una caída de una máquina ya os cuesta dinero.
¿Podemos desplegar nuestros docker-compose.yml tal cual?
Casi siempre. Dokploy acepta proyectos de Compose y los publica detrás de Traefik. Revisamos antes los volúmenes, las redes y los puertos publicados, porque lo que funciona en un portátil a veces expone una base de datos o guarda datos donde no se copian.
¿Qué copia y qué no copia Dokploy por sí solo?
Programa copias de las bases de datos que crea desde el panel y de volúmenes hacia un destino compatible con S3. Lo que no garantiza es que esas copias se puedan restaurar ni que cubran datos que viven fuera de esos volúmenes. Por eso restauramos una de vez en cuando en un entorno aparte y apuntamos el resultado.
¿Dokploy o Coolify?
Los dos resuelven lo mismo con enfoques distintos. La comparación detallada, y cómo salir de Heroku o Vercel, está en la página de Coolify y Dokploy. Si ya usáis Dokploy, lo normal es quedarse con él y ordenarlo.
Contadnos vuestro caso
En una llamada gratuita de 20 minutos vemos dónde estáis y por dónde empezar. Sin compromiso.
Documentación oficial consultada
Los datos técnicos de esta página se basan en:
Revisado el