Tutoriales de VPS
Montar Coolify como plataforma de despliegue autoalojada en un VPS (2026): Docker, despliegue automático con Git, HTTPS con Traefik y guía para evitar errores de copias de seguridad
Este tutorial explica cómo autoalojar Coolify en un VPS y convertir un servidor normal en una plataforma de despliegue similar a Vercel, Heroku o Railway. Cubre la elección de la configuración del VPS, el script oficial de instalación, puertos y dominios, HTTPS automático con Traefik, despliegue desde repositorios Git, variables de entorno, servicios de base de datos, copias de seguridad y actualizaciones, refuerzo de seguridad y problemas comunes de 502, SSL y fallos de compilación.
Ya no me gusta mucho tirar todos los proyectos pequeños a un montón de plataformas distintas.
Un proyecto Next.js en Vercel, un backend en Railway, una base de datos en Supabase, más un Redis y una tarea programada. Al principio sí ahorra trabajo, pero cuando los proyectos se multiplican, la facturación, las variables de entorno, los dominios, los logs y las copias de seguridad empiezan a dispersarse.
Coolify resuelve este problema: compras tú mismo un VPS y montas en él un panel de despliegue similar a Vercel / Heroku / Railway.
No es Kubernetes, ni tampoco un panel tradicional tipo BaoTa. Más exactamente, es un PaaS autoalojado: conectas un repositorio Git, rellenas las variables de entorno, vinculas un dominio, pulsas desplegar y Coolify se encarga de la compilación Docker, la ejecución de contenedores, el proxy inverso y HTTPS.
Este artículo lo explica como se lo contaría a un amigo: qué VPS conviene para ejecutar Coolify, cómo instalarlo, cómo poner en línea la primera aplicación y qué errores evitar de antemano.
Si solo vas a desplegar un sitio estático, Vercel y Netlify siguen siendo menos complicados. Coolify encaja realmente con estos perfiles:
| Escenario | ¿Adecuado para Coolify? | Motivo |
|---|---|---|
| Varios proyectos pequeños que deben funcionar a largo plazo | Adecuado | Un VPS gestiona varias aplicaciones, coste fijo |
| Quieres autoalojar n8n, Umami, Postgres, Redis | Adecuado | Coolify tiene plantillas de servicios, fácil de gestionar |
| Herramientas internas de empresa, paneles de administración | Adecuado | Los datos y el flujo de despliegue están en tu propio servidor |
| Solo ejecutar una web estática | No necesariamente | Puede ser más complicado que Vercel |
| Negocio grande de alta concurrencia | Con precaución | Un VPS único no es una plataforma de escalado automático |
Mi propio criterio es simple:
- Si tienes 3 o más proyectos que ejecutar, Coolify empieza a valer la pena
- Si solo quieres desplegar un blog, Docker Compose + Caddy a secas puede ser más ligero
- Si no quieres encargarte en absoluto de la seguridad del servidor ni de las copias de seguridad, entonces no lo autoalojes
Lo que Coolify ahorra es el tiempo de "escribir a mano Docker Compose, proxy inverso, certificados y variables de entorno para cada proyecto", no el mantenimiento del servidor.
Coolify en sí no consume tantos recursos; lo que realmente consume es el proceso de compilación.
Por ejemplo, cuando despliegas un proyecto Next.js, la CPU y la memoria suben de golpe durante la compilación; cuando despliegas un servicio con base de datos, también hay que dejar espacio para Postgres, Redis y los contenedores de la aplicación.
Sugiero elegir así:
| Uso | Configuración mínima | Configuración más estable |
|---|---|---|
| Pruebas, experimentación | 2 núcleos / 2GB / 30GB SSD | 2 núcleos / 4GB / 40GB SSD |
| Ejecutar 2-5 aplicaciones pequeñas | 2 núcleos / 4GB / 60GB SSD | 4 núcleos / 8GB / 80GB SSD |
| Varios proyectos de producción | 4 núcleos / 8GB para empezar | CPU dedicada es más cómoda |
Hay un punto que se pasa por alto fácilmente: un VPS barato con CPU compartida puede ejecutarlo, pero las compilaciones serán lentas.
Si tu proyecto hace con frecuencia npm install, pnpm build, la fluctuación de la CPU compartida se nota mucho. La aplicación en ejecución puede ir bien, pero esperar tanto en cada despliegue resulta molesto.
En cuanto al sistema, prioriza:
- Ubuntu 22.04 / 24.04 LTS
- Debian 12
- Un sistema limpio, sin instalar un montón de paneles antiguos
Si este VPS ya ejecuta Nginx, Caddy, BaoTa o 1Panel, piénsalo bien antes de instalar Coolify. Porque Coolify trae su propio proxy inverso, y la gestión de puertos y certificados puede chocar fácilmente con los servicios existentes.
La instalación oficial es sencilla, pero no te apresures a copiar el comando.
Primero inicia sesión por SSH en el VPS:
ssh root@your_server_ip
Actualiza el sistema:
apt update && apt upgrade -y
Comprueba el espacio en disco:
df -h
Comprueba si los puertos están ocupados:
ss -tlnp | grep -E ':80|:443|:8000|:6001|:6002'
El autoalojamiento de Coolify suele usar estos puertos:
| Puerto | Uso |
|---|---|
| 22 | Inicio de sesión SSH al servidor |
| 80 | HTTP / validación de certificados Let's Encrypt |
| 443 | Acceso HTTPS a las aplicaciones |
| 8000 | Acceso inicial al panel de Coolify |
| 6001 | Comunicación en tiempo real |
| 6002 | Web Terminal, necesario en algunas versiones |
Si ya tienes Nginx ocupando 80/443, el Traefik de Coolify no podrá hacerse cargo correctamente del tráfico público.
El método de instalación recomendado oficialmente es el script. Como usuario root puedes ejecutar:
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash
Si no eres el usuario root, usa sudo:
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash
El script de instalación hace varias cosas:
- Instala Docker y Docker Compose
- Crea los directorios relacionados con
/data/coolify/ - Descarga la imagen del contenedor de Coolify
- Inicia el panel de Coolify
- Inicia el proxy inverso predeterminado
- Configura la base de datos interna y los servicios necesarios
Tras la instalación, primero comprueba si los contenedores están levantados:
docker ps --filter "name=coolify"
Si ves los contenedores relacionados con Coolify en estado Up, significa que arrancó correctamente.
Accede desde el navegador a:
http://your_server_ip:8000
Una vez dentro, crea una cuenta de administrador. No uses una contraseña débil aquí: en cuanto alguien entra en el panel de Coolify, básicamente puede controlar las aplicaciones de tu servidor.
En fase de pruebas vale con IP + 8000, pero para uso a largo plazo hay que vincular un dominio.
Por ejemplo, si planeas:
coolify.example.com
Añade un registro A en el DNS:
coolify.example.com -> your_server_ip
Al principio sugiero dejar Cloudflare en DNS only, es decir, la nube gris. Cuando los certificados se emitan con normalidad y tanto el panel como las aplicaciones sean accesibles, entonces considera activar el proxy de nube naranja.
Luego, en los ajustes de Coolify, cambia el Instance Domain a:
https://coolify.example.com
Coolify usa Traefik como proxy inverso por defecto y gestiona HTTPS automáticamente. En condiciones normales no necesitas instalar Certbot tú mismo ni escribir configuraciones de Nginx a mano.
Si ya tienes una capa externa de Cloudflare, ten en cuenta dos cosas:
- En la primera emisión del certificado, los puertos 80/443 deben estar accesibles
- Tras activar el proxy de Cloudflare, prueba el flujo de logs del panel y el estado de despliegue para evitar problemas con WebSocket
El uso más común de Coolify es desplegar desde un repositorio Git.
El flujo aproximado es:
- Añadir una conexión de GitHub / GitLab en Coolify
- Seleccionar el repositorio y la rama
- Seleccionar el método de compilación, por ejemplo Nixpacks, Dockerfile o Docker Compose
- Rellenar las variables de entorno
- Vincular un dominio
- Pulsar Deploy
Si es un proyecto Node.js normal, Coolify suele detectarlo automáticamente.
Pero para proyectos de producción prefiero preparar mi propio Dockerfile, al menos es más controlable. Por ejemplo, una aplicación Node sencilla:
FROM node:22-alpine AS deps
WORKDIR /app
COPY package*.json ./
RUN npm ci
FROM node:22-alpine AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npm run build
FROM node:22-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production
COPY --from=builder /app .
EXPOSE 3000
CMD ["npm", "start"]
Luego, en Coolify, configura el puerto de la aplicación como 3000 y rellena el dominio:
app.example.com
Tras un despliegue correcto, Coolify redirige las peticiones del dominio público al puerto interno del contenedor.
Coolify es cómodo, pero las variables de entorno las sigues gestionando tú.
Las variables habituales incluyen:
DATABASE_URL=postgresql://user:password@host:5432/db
REDIS_URL=redis://redis:6379
APP_URL=https://app.example.com
NODE_ENV=production
Algunas recomendaciones:
- No hagas commit de
.enven el repositorio Git - Usa cadenas largas aleatorias para las contraseñas de producción
- No uses la misma contraseña para la base de datos que para el panel
- Tras cambiar variables clave, vuelve a desplegar y revisa los logs
Si la aplicación no arranca, mira primero los logs de despliegue; no reinstales a ciegas.
Coolify puede desplegar aplicaciones y también servicios, como PostgreSQL, Redis, MySQL, MongoDB, n8n, Umami y similares.
Pero no lo entiendas como "un clic y ya nunca hay que preocuparse". Lo más importante en una base de datos son las copias de seguridad.
Si despliegas PostgreSQL con Coolify, como mínimo confirma:
- Que el directorio de datos está en un Volume persistente
- Que hay copias de seguridad periódicas
- Que los archivos de copia no están solo en el mismo VPS
- Que puedes restaurar antes de actualizar
Normalmente pongo las copias en almacenamiento de objetos, por ejemplo Cloudflare R2, Backblaze B2, almacenamiento compatible con S3.
Una idea sencilla para las copias de la base de datos es:
pg_dump "$DATABASE_URL" | gzip > app-db-$(date +%F).sql.gz
Luego sincroniza al remoto con rclone:
rclone copy app-db-$(date +%F).sql.gz r2:backup-bucket/coolify/app/
No es necesariamente la forma más elegante, pero al menos es más fiable que "copias y base de datos en el mismo disco del VPS".
Si nada más instalar cierras todos los puertos, es fácil dejarte fuera.
Primero confirma el puerto SSH:
ss -tlnp | grep ssh
Luego configura UFW:
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw allow 8000/tcp
ufw allow 6001/tcp
ufw allow 6002/tcp
ufw enable
ufw status
Cuando ya accedas al panel con normalidad mediante https://coolify.example.com, normalmente 8000 ya no necesita estar expuesto a internet.
Puedes restringirlo:
ufw delete allow 8000/tcp
Si no usas el Web Terminal, también puedes restringir 6002 según el caso. Pero no copies mecánicamente: primero confirma si la versión y las funciones actuales lo necesitan.
Primero ejecuta los más importantes del enfoque de diagnóstico oficial:
docker --version
docker compose version
systemctl status docker --no-pager -l
docker ps -a --filter "name=coolify"
df -h /
ls -lt /data/coolify/source/*.log 2>/dev/null | head -5
Muchos fallos no son porque Coolify esté roto, sino por:
- El sistema es demasiado antiguo
- Docker no está bien instalado
- El disco está lleno
- El puerto 8000 está ocupado
- El script no tiene permiso para escribir en el directorio
Primero mira los contenedores:
docker ps -a --filter "name=coolify"
Luego mira los puertos:
ss -tlnp | grep 8000
Si el contenedor está en ejecución pero no puedes acceder, revisa el grupo de seguridad del proveedor cloud y UFW. Mucha gente solo abre el firewall del sistema y olvida que en la consola del proveedor cloud hay otra capa de grupo de seguridad.
La causa más común de un 502 es que el puerto de la aplicación no coincide.
Por ejemplo, tu aplicación Node escucha realmente en 3000, pero en Coolify pones 8080, y Traefik reenvía al lugar equivocado.
Entra en el contenedor para ver el puerto de escucha:
docker ps
docker logs container_name --tail=100
En la aplicación también hay que confirmar que la dirección de escucha no está vinculada solo a 127.0.0.1. En un contenedor normalmente hay que escuchar en:
0.0.0.0
Comprueba en orden:
- Si el registro A de DNS apunta a este VPS
- Si 80 y 443 están abiertos
- Si Cloudflare está temporalmente en DNS only
- Si el dominio tiene un registro AAAA que apunta a una IPv6 incorrecta
- Si el mismo dominio está ocupado por un Nginx / Caddy antiguo
No borres los contenedores de inmediato. Los problemas de certificados son casi siempre problemas de DNS y puertos.
Este tipo de problema es muy común en VPS de 2GB de memoria.
Primero mira la memoria:
free -h
Luego mira el OOM:
journalctl -k | grep -i "out of memory"
Como mitigación temporal puedes añadir swap:
fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab
Pero a largo plazo, si compilas con frecuencia proyectos frontend grandes, actualizar a 4GB u 8GB es más práctico.
Coolify admite actualizaciones, pero en producción no pulses el botón en cuanto lo veas.
Mi costumbre es:
- Primero comprobar si el negocio actual funciona con normalidad
- Hacer copia de seguridad de los datos relacionados con Coolify y de las bases de datos de las aplicaciones
- Evitar las horas punta del negocio
- Tras actualizar, probar el panel, el despliegue, el flujo de logs y HTTPS
Si lo usas para alojar varios proyectos, actualizar Coolify no es solo actualizar un panel, sino que afecta a toda la plataforma de despliegue.
Estas herramientas se comparan a menudo juntas, pero sus usos son distintos.
| Herramienta | Para qué es más adecuada |
|---|---|
| Coolify | Despliegue de aplicaciones basado en Git, PaaS, puesta en línea de proyectos autoalojados |
| 1Panel | Tienda de aplicaciones Docker, gestión de sitios web, panel de servidor |
| Portainer | Gestión de contenedores Docker, Stack, Volume |
| BaoTa / aaPanel | Sitios web PHP tradicionales, LNMP, creación visual de sitios |
Si tu necesidad principal es "desplegar en cuanto se hace push del código", Coolify es más cómodo.
Si solo quieres gestionar contenedores Docker, Portainer es más ligero.
Si eres principiante y vas a montar WordPress, 1Panel o BaoTa pueden ser más directos.
El escenario en el que Coolify más merece la pena no es ahorrar unos dólares en tarifas de plataforma, sino recuperar el control del flujo de despliegue.
Puedes ejecutar en un VPS de 4 núcleos y 8GB:
- Una aplicación frontend
- Una API backend
- Un PostgreSQL
- Un Redis
- Un n8n
- Un Umami
- Un panel de administración interno
Todo esto se gestiona en el mismo panel, con dominios, certificados, logs y registros de despliegue centralizados; la verdad es que es cómodo.
Pero el precio también es claro: la seguridad del servidor, las copias de seguridad, las actualizaciones y la monitorización pasan a ser tu responsabilidad.
Así que yo elegiría así:
- Solo para probar: un VPS de 2 núcleos y 4GB puede servir
- Para uso a largo plazo: 4 núcleos y 8GB + copias automáticas + monitorización
- Negocio central de la empresa: no dependas solo de una máquina única; como mínimo ten copias fuera del sitio y un plan de migración
Coolify es una buena herramienta, pero no es magia. Puede convertir un VPS en una plataforma de despliegue, siempre que estés dispuesto a mantener ese VPS como un entorno de producción real.