deploykit_docs

docs Dominios y SSL

Dominios y SSL

Enruta dominios personalizados a tus aplicaciones a través de Traefik, con certificados automáticos de Let's Encrypt.

Añadir dominios a una aplicación

En la pestaña Domains de una aplicación, haz clic en Add Domain e introduce el hostname y el Container Port en el que escucha tu aplicación. Añadir o eliminar dominios requiere el rol de Operator o Admin en el proyecto.

  • Una aplicación puede tener tantos dominios como quieras — dominios raíz, subdominios o ambos (example.com y www.example.com)
  • Cada dominio tiene su propio puerto de contenedor, por lo que un mismo contenedor puede servir distintos puertos en distintos hostnames
  • Los hostnames deben ser FQDN válidos; se convierten a minúsculas automáticamente
  • Los dominios añadidos desde el dashboard usan siempre HTTPS
  • Los cambios surten efecto en el siguiente despliegue — las etiquetas de enrutado se establecen al crear el contenedor, así que redespliega tras añadir o eliminar un dominio

Configuración de DNS

Apunta cada dominio a la IP pública del servidor en el que se ejecuta la aplicación y después añádelo en DeployKit:

bash
# Root domain
A      example.com       → YOUR_SERVER_IP

# Subdomain
A      api.example.com   → YOUR_SERVER_IP
# or
CNAME  api.example.com   → example.com

SSL automático con Let's Encrypt

Traefik v3 obtiene y renueva un certificado para cada dominio HTTPS usando el desafío HTTP de Let's Encrypt. Las peticiones HTTP simples al puerto 80 se redirigen a HTTPS. Para que se emita un certificado:

  • El DNS del dominio ya debe resolver al servidor
  • Los puertos 80 y 443 deben estar abiertos — el puerto 80 es necesario para el desafío aunque después el tráfico se redirija
  • Los certificados wildcard (*.example.com) no se pueden obtener con el desafío HTTP; cada hostname obtiene su propio certificado

Cómo funciona el enrutado

Cuando se despliega un contenedor, DeployKit le adjunta etiquetas de Traefik: un router y un servicio por dominio, con cada router enlazado explícitamente a su propio servicio. Traefik recoge las etiquetas y enruta el hostname al contenedor y puerto correctos. No se expone nada que no tenga un dominio.

  • Con dominio: no se publica ningún puerto del host, y Traefik reparte la carga entre las réplicas
  • Sin dominio: el puerto de la aplicación se publica en el host y solo se ejecuta una instancia — las réplicas requieren un dominio
  • El modo mantenimiento responde en los dominios de la aplicación, por lo que necesita al menos uno
  • Los stacks de Compose tienen sus propios dominios: cada dominio apunta a un servicio del stack (y puede añadir un prefijo de ruta)

¿Varios dominios devuelven 404? Antes de la v0.5.0, una aplicación o un servicio de un stack con dos o más dominios producía routers de Traefik que no estaban enlazados a un servicio, por lo que Traefik los descartaba todos (su log muestra cannot be linked automatically with multiple Services) mientras el dashboard seguía mostrando la aplicación como en ejecución. Esto está corregido, pero las etiquetas quedan fijadas al crear el contenedor: redespliega cualquier aplicación o stack que ya tuviera varios dominios después de actualizar.

El dominio propio del dashboard

El panel se enruta de la misma forma. En producción, establece DOMAIN y ACME_EMAIL en tu .env. La API responde en /api, /trpc, /socket.io y /ws de ese host; todo lo demás va al dashboard.

bash
DOMAIN=panel.yourdomain.com
ACME_EMAIL=you@yourdomain.com
# WEB_URL is derived automatically as https://${DOMAIN}

WEB_URL — la URL pública de la instancia, usada para CORS, WebSockets y las URL de webhook y callback de la GitHub App — la establece docker-compose.prod.yml como https://DOMAIN; no tienes que establecerla tú. Si más adelante cambias DOMAIN, una GitHub App registrada con anterioridad sigue apuntando a la URL antigua y debe actualizarse o registrarse de nuevo.