Categoría: PaaS y contenedores
Coolify y Dokploy gestionados: vuestro propio Heroku o Vercel en vuestra cuenta
La comodidad de hacer push y ver la aplicación publicada, pero en servidores que pagáis vosotros, con alguien cuidando el panel, las copias y lo que corre debajo.
- Dónde se monta
- En vuestra cuenta, a vuestro nombre
- Copias
- Con restauración probada
- Actualizaciones
- Planificadas y documentadas
- Licencia
- Coolify: Apache 2.0. Dokploy: Apache 2.0, salvo su carpeta propietaria
En resumen
Coolify y Dokploy son paneles de código abierto que convierten vuestros servidores en una plataforma de despliegue al estilo de Heroku o Vercel. Los instalamos en vuestra cuenta, conectamos vuestros repositorios, dejamos las bases de datos con copias que restauramos en pruebas, protegemos el panel y mantenemos al día tanto la herramienta como los servidores que hay debajo.
¿Qué nos encargamos de mantener?
Coolify self hosted o Dokploy se instalan con un solo comando, y esa facilidad engaña: lo difícil empieza el día que el disco se llena, una base de datos sin copia se corrompe o alguien encuentra el panel abierto. Esto es lo que dejamos bajo control:
Panel
Coolify o Dokploy en su propio servidor, con acceso restringido, doble factor y usuarios por persona.
Despliegues
Repositorios conectados, variables de entorno ordenadas y vistas previas por rama donde aporten.
Servidores
Los nodos donde corren las aplicaciones: parches, Docker, cortafuegos y limpieza de imágenes viejas.
Bases de datos
PostgreSQL, MySQL, Redis o MongoDB en contenedor, con copias fuera y restauración ensayada.
Proxy y dominios
Traefik con certificados que se renuevan solos y dominios apuntados sin sorpresas.
Alertas
Despliegues fallidos, contenedores que reinician en bucle, disco y certificados a punto de caducar.
¿Cómo lo montamos?
La instalación por defecto pone el panel y las aplicaciones en la misma máquina. Sirve para probar; en producción preferimos separar responsabilidades:
Servidor del panel
Solo ejecuta Coolify o Dokploy y su base de datos interna. Pequeño, sin tráfico público salvo el acceso al panel.
Servidores de aplicaciones
El panel los gobierna por SSH: construye las imágenes, arranca los contenedores y configura el proxy.
Proxy con HTTPS
Traefik delante de cada servidor reparte el tráfico por dominio y pide los certificados.
Copias externas
Bases de datos y panel copiados a un almacenamiento compatible con S3 en otra ubicación.
Con un solo servidor de aplicaciones vale para empezar. Cuando una caída de esa máquina ya duele, añadimos un segundo nodo y repartimos lo crítico; en Dokploy, con réplicas de Swarm. Si lo que os interesa es Dokploy en concreto, lo contamos en Dokploy gestionado.
¿Qué problemas encontramos con un PaaS autoalojado?
- Disco lleno de imágenes: cada despliegue deja capas nuevas y nadie programó la limpieza.
- Bases de datos sin copia o con copia sin probar: el botón de copia estaba activado, pero nunca se restauró nada.
- Panel expuesto con usuario compartido: una sola contraseña para todo el equipo y sin doble factor.
- Todo en la misma máquina: el panel, las aplicaciones y las bases de datos caen a la vez.
- Actualizaciones automáticas del panel: una versión nueva cambia algo del proxy un viernes por la tarde.
- Variables con secretos copiadas a mano entre entornos, sin saber cuál es la buena.
¿Cómo hacemos las copias y las actualizaciones?
Hay dos copias distintas y las dos importan. La de las bases de datos de vuestras aplicaciones se programa desde el propio panel hacia un bucket compatible con S3; periódicamente restauramos una en un contenedor aparte y comprobamos que los datos están. La del panel incluye su base de datos interna y su clave de aplicación: sin esa clave, la copia no descifra los secretos guardados. La documentación de Coolify describe ese procedimiento y lo ensayamos en un servidor limpio.
Desactivamos las actualizaciones automáticas del panel. Leemos las notas de cada versión, actualizamos primero en un entorno de prueba cuando el cambio es grande y aplicamos en producción en una ventana avisada. Los parches de seguridad del sistema operativo y de Docker siguen su propio calendario, más corto.
¿Cómo es salir de Heroku o de Vercel?
Para salir de Heroku, cada aplicación pasa a construirse con Nixpacks, buildpacks o un Dockerfile, y las bases de datos se exportan e importan en una ventana corta. En Vercel, las webs estáticas y las aplicaciones de Next.js con servidor Node se trasladan bien; las funciones en el borde y algunas optimizaciones propias de la plataforma requieren revisión. Montamos la aplicación nueva en paralelo, probamos con un dominio temporal y cambiamos el DNS cuando todo responde igual.
¿Cómo protegemos el panel y los servidores?
El panel es la llave de todo: quien entra puede desplegar, leer variables y borrar bases de datos. Lo dejamos detrás de una VPN o con acceso por IP, con doble factor y usuarios nominales. Los servidores solo aceptan SSH con clave, y el cortafuegos cierra los puertos de las bases de datos al exterior. Si necesitáis varios equipos con permisos separados, lo organizamos por proyectos dentro del panel.
- GitPush o webhook
- PanelCoolify o Dokploy, en su servidor
- Servidores de aplicacionesDocker, por SSH
- TraefikHTTPS y dominios
- Bases de datosCopias 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
- Azure
- DigitalOcean
- OVH
- Servidor propio
| Proveedor | Cómo lo montamos | A tener en cuenta |
|---|---|---|
| Hetzner | Un servidor cloud pequeño para el panel y uno o varios para las aplicaciones, unidos por red privada. | La combinación más habitual en Europa. Las copias van a Object Storage de Hetzner, compatible con S3. |
| AWS | Instancias EC2 para el panel y las aplicaciones, con copias en un bucket de S3. | Si ya tenéis RDS, las aplicaciones pueden usarlo en lugar de bases de datos en contenedor. |
| Google Cloud | Máquinas de Compute Engine y copias en Cloud Storage mediante su acceso compatible con S3. | Encaja si el resto de vuestra infraestructura ya vive en Google Cloud. |
| Azure | Máquinas virtuales para el panel y las aplicaciones. | Blob Storage no habla S3 de forma nativa: las copias van a un almacenamiento compatible con S3 o pasan por un paso intermedio que preparamos. |
| DigitalOcean | Droplets para el panel y las aplicaciones, con copias en Spaces. | |
| OVH | Instancias de Public Cloud y copias en Object Storage de OVHcloud, compatible con S3. | |
| Servidor propio | El panel y las aplicaciones en vuestros servidores físicos o virtuales, con Docker. | Para publicar a internet usamos un túnel o un proxy delante; no abrimos el servidor entero. |
Qué incluye
- Panel de Coolify o Dokploy en un servidor aparte de las aplicaciones, en vuestra cuenta y a vuestro nombre.
- Repositorios conectados para desplegar al hacer push, con entornos de vista previa por rama cuando encaja.
- Proxy con certificados HTTPS automáticos y dominios propios para cada aplicación.
- Bases de datos con copias programadas a un almacenamiento de objetos compatible con S3, restauradas en pruebas.
- Copia del propio panel: su base de datos interna y su clave de aplicación, guardadas fuera del servidor.
- Acceso al panel restringido, doble factor y usuarios nominales para vuestro equipo.
- Servidores con parches del sistema, Docker al día, cortafuegos y disco vigilado.
- Migración desde Heroku, Vercel, Render o un servidor montado a mano.
Preguntas frecuentes
¿Coolify o Dokploy: cuál nos recomendáis?
Depende de lo que tengáis. Coolify trae un catálogo enorme de servicios listos para instalar y trabaja muy bien con varios servidores sueltos por SSH. Dokploy es más sobrio, se apoya en Docker Swarm y resulta cómodo si pensáis repartir réplicas entre varios nodos. Si ya usáis uno de los dos, lo normal es quedarse con él.
¿Es una alternativa real a Vercel o Heroku?
Para webs, APIs y aplicaciones en contenedor, sí: despliegues desde Git, vistas previas por rama y certificados automáticos. Lo que no tendréis es una red de distribución global ni funciones en el borde como las de Vercel. Si vuestra aplicación depende de eso, lo hablamos antes de mover nada.
¿Qué pasa si se cae el servidor del panel?
Las aplicaciones siguen funcionando, porque corren en sus propios servidores con Docker. Lo que se pierde mientras tanto es la posibilidad de desplegar. Por eso separamos el panel de las aplicaciones y guardamos su copia fuera: se reconstruye en otro servidor sin tocar lo que ya está publicado.
¿La licencia de Dokploy permite usarlo en nuestra empresa?
Sí. El código de Dokploy se publica con licencia Apache 2.0, salvo lo que hay dentro de su carpeta propietaria, que tiene una licencia aparte. Para instalarlo en vuestros servidores y usarlo en vuestra empresa no hay problema; si alguna función que necesitáis cae en la parte propietaria, lo revisamos antes.
¿Nuestros desarrolladores pueden seguir desplegando solos?
Sí, esa es la idea. Cada persona entra con su usuario y despliega sus aplicaciones desde el panel o con un push. Nosotros nos ocupamos de lo que no se ve: servidores, copias, proxy, actualizaciones y alertas.
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:
- Coolify Docs: Backup and restore your Coolify instance
- Dokploy: LICENSE.MD (Apache 2.0 y carpeta propietaria)
Revisado el