Coolify

Coolify implementa el docker/compose.yaml del repositorio directamente.

Instalar la stack de Compose (recomendado)

1. Nuevo recurso → Docker Compose y apúntelo a este repositorio (o pega el docker/compose.yaml).
2. Configura los secretos como variables de entorno en la interfaz de usuario de Coolify:
   • MASTER_KEY — openssl rand -base64 48
   • ENCRYPTION_KEYRING — p.ej. {"primary":"<openssl rand -hex 32>"}
   • ACTIVE_ENCRYPTION_KEY_ID — primary
3. Implementar. Los paquetes postgres y redis se ejecutan dentro de la red privada del stack y el gateway aplica las migraciones pendientes en el arranque antes de abrirse en el puerto interno 4000.
4. Configura dominios solo para servicios HTTP de larga duración:
   • gateway — por ejemplo https://api.example.com:4000
   • panel (opcional): su dominio propio: https://dash.example.com:3001

El panel es un producto separado en un dominio separado, por lo que Coolify lo trata como cualquier otro servicio: un nombre de host, un puerto de contenedor, listo. No hay ningún prefijo de ruta que conservar.

Necesita una configuración: GATEWAY_URL, apuntando al gateway. Dentro de un stack Coolify está el nombre del servicio, http://gateway:4000, lo que significa que el gateway no necesita ningún dominio a menos que desee que se publique la API. Panel del operador → Compruébalo tiene una curvatura que le indica si el panel puede alcanzarlo.

El sufijo de puerto en un dominio Coolify selecciona el puerto interno del contenedor; TLS todavía usa el puerto HTTPS público normal. Postgres y Redis deben permanecer internos.

El archivo Compose base usa expose, no ports, por lo que ninguno de estos servicios omite el proxy de Coolify ni publica un puerto de host sin formato.

Debido a que Postgres/Redis vive en la red Compose y el gateway se conecta a través de texto sin formato (postgres://gateway:gateway@postgres:5432/ai_gateway, redis://redis:6379), no hay TLS y, por lo tanto, no hay Solución de problemas.

Deployments y tiempo de inactividad

Coolify no realiza actualizaciones continuas para los recursos de Docker Compose: docker compose up concilia los servicios por sí mismo, deteniendo e iniciando cada uno de los modificados. El gateway drena SIGTERM en lugar de descartar las solicitudes en curso, pero eso solo funciona si Coolify lo espera: aumente Detener período de gracia arriba de DRAIN_DELAY_MS + SHUTDOWN_TIMEOUT_MS.

Compose es la elección correcta cuando desea que todo se implemente como una sola unidad. Para actualizaciones continuas, ejecuta cada aplicación como su propio recurso Docker Image y mantén solo Postgres y Redis en un stack: Rollouts cubre ambas topologías y las configuraciones que cada una necesita.

Uso de la base de datos independiente de Coolify/servicios Redis

Si, en cambio, crea los servicios Postgres y Redis independientes de Coolify y les conecta el gateway, Coolify los expone con certificados autofirmados, que el TLS de Bun puede rechazar (consulta Solución de problemas). La configuración más sencilla es ejecutar ambos sin TLS en la red privada:

• Deshabilitar SSL en ambos servicios: desmarque Habilitar SSL en los servicios Postgres y Redis.
• Conéctese a través del nombre de host interno con postgres://… y redis://… (no sslmode, no rediss://). En la red privada de Coolify, el enlace está protegido por aislamiento de red, no por TLS.

No exponga la base de datos públicamente en texto sin formato; consulta la nota de seguridad. Para una base de datos fuera de la red, prefiera un proveedor administrado con un certificado de CA pública.