Dominio personalizado y TLS automático en Dockup
Dominio personalizado y TLS automático en Dockup: añade DNS, verifica la propiedad, emite HTTPS, expón puertos adicionales, valida el cambio y resuelve problemas de forma segura.
Una configuración de dominio personalizado y TLS automático tiene tres capas independientes: el servicio de Dockup debe estar operativo, el DNS debe apuntar el hostname a la plataforma y el hostname debe superar la verificación antes de que se pueda emitir un certificado. Tratar estas capas por separado hace que el cambio sea predecible y evita que los errores de DNS parezcan fallos de la aplicación.
Dockup también proporciona a cada servicio una dirección *.dockup.tech. Conserva esa dirección durante la propagación del DNS para poder probar la aplicación de forma independiente del hostname personalizado.
¿Qué debe estar listo antes de añadir un dominio personalizado de Dockup?
Empieza con un servicio que ya esté en ejecución y supere su comprobación de disponibilidad:
dockup status production/web --json
dockup health production/web --json
Abre o prueba la URL existente *.dockup.tech. Si la aplicación falla ahí, añadir un dominio no lo solucionará. Revisa primero los logs de ejecución.
Recopila la siguiente información:
| Elemento | Ejemplo | Por qué es importante |
|---|---|---|
| Destino exacto | production/web | Evita asociar el dominio al servicio equivocado |
| Hostname | app.example.com | El nombre DNS que visitarán los usuarios |
| Acceso al DNS | Registrador o proveedor de DNS | Necesario para crear el registro |
| TTL actual | 300 segundos | Controla la velocidad de propagación y rollback |
| URL canónica de la aplicación | https://app.example.com | Puede afectar a las redirecciones y las cookies |
| Ruta de health check | /health | Confirma el servicio antes del cambio |
Reduce de antemano el TTL del DNS existente cuando reemplaces un proveedor activo. No elimines el registro anterior hasta conocer el destino de Dockup, la configuración de la aplicación y el plan de rollback.
Revisa el comportamiento de la aplicación que dependa del host. Es posible que las callbacks de autenticación, las listas de CORS permitidas, los dominios de las cookies, las URL de redirección de OAuth, los destinos de los webhooks y los enlaces absolutos generados necesiten el nuevo hostname HTTPS.
¿Cómo se añade y verifica el dominio?
Primero, muestra los dominios actuales:
dockup domain list production/web --json
Añade el hostname:
dockup domain add app.example.com production/web --json
La respuesta proporciona el destino DNS que debes configurar. Crea el registro CNAME indicado en el proveedor de DNS. No inventes una dirección IP ni copies un valor de otro servicio; utiliza el destino devuelto para este dominio.
Cuando el DNS se haya propagado, verifícalo con el ID de dominio devuelto:
dockup domain verify <domainId> production/web --json
La verificación demuestra que el registro DNS público se resuelve según lo requerido. Un error suele deberse a una de estas cuatro causas:
- El nombre del registro es incorrecto.
- El destino CNAME es incorrecto.
- Sigue existiendo un registro A, AAAA o CNAME antiguo que entra en conflicto.
- Las cachés de los resolvers todavía no han recibido el nuevo valor.
Comprueba el DNS autoritativo en lugar de eliminar y volver a crear el dominio repetidamente. La propagación es un proceso de caché distribuido, no un proceso de build de Dockup.
¿Cómo se emite y mantiene el certificado HTTPS?
Cuando la verificación se complete correctamente, solicita el certificado:
dockup domain ssl <domainId> production/web --json
Dockup gestiona la emisión del certificado para el hostname verificado y sirve el dominio personalizado mediante HTTPS. La plataforma administra el ciclo de vida de TLS, por lo que el contenedor de la aplicación no necesita almacenar archivos de certificado ni ejecutar un proceso de renovación.
Valida el resultado desde fuera de la plataforma:
curl -I https://app.example.com
Confirma que:
- El certificado coincide con el hostname.
- La respuesta se sirve mediante HTTPS.
- Las redirecciones no entran en bucle.
- La aplicación devuelve el estado esperado.
- La autenticación y los flujos de callbacks utilizan el nuevo origen.
- Los assets estáticos se cargan sin errores de mixed content.
La emisión del certificado puede fallar aunque la aplicación esté funcionando correctamente. Mantén separados los diagnósticos de DNS y de servicio. Usa domain verify para la propiedad del DNS y los logs del servicio para el comportamiento de la aplicación.
El artículo sobre deployments sin downtime explica el gate independiente de disponibilidad de los releases.
¿Cómo se cambia el tráfico sin provocar una interrupción?
Un cambio seguro mantiene disponible la ruta anterior hasta que el nuevo hostname se haya validado.
- Haz deploy y verifica el servicio de Dockup en su URL de plataforma.
- Añade el dominio personalizado en Dockup.
- Crea el registro DNS.
- Verifica el DNS.
- Emite el certificado TLS.
- Prueba HTTPS directamente.
- Actualiza las callbacks, las URL canónicas y la monitorización.
- Envía una pequeña parte del tráfico operativo si la configuración DNS lo permite.
- Observa los logs y la disponibilidad.
- Retira el proveedor anterior solo cuando la nueva ruta sea estable.
Las comprobaciones de uptime de Dockup se ejecutan cada minuto e informan de estadísticas de tiempo de respuesta, incluido p95:
dockup uptime production/web --hours 24 --json
Mantén una monitorización externa independiente para los dominios críticos. Un probe de la plataforma confirma la accesibilidad pública, mientras que un monitor externo verifica la ruta del usuario desde otro sistema.
Si el dominio personalizado sustituye a un host de producción actual, conserva un registro de rollback: valor DNS anterior, TTL anterior, estado del proveedor antiguo y condición que desencadenaría la reversión.
¿Cómo funcionan los dominios para puertos adicionales?
Un servicio puede exponer un segundo puerto HTTP para una interfaz de administración, un endpoint de métricas u otro proceso web. Dockup puede crear un dominio adicional de plataforma sin DNS personalizado:
dockup port list production/web --json
dockup port add 8080 production/web --name admin --json
El dominio devuelto dirige al puerto seleccionado del contenedor. Esto es independiente del dominio personalizado principal.
No expongas un puerto simplemente porque haya un proceso escuchando en él. Pregúntate si el endpoint tiene autenticación, si contiene datos de producción y si realmente debe ser público. Una interfaz de administración solo interna no debería quedar accesible desde Internet por comodidad.
Elimina un dominio de puerto obsoleto únicamente mediante la interfaz de dominios compatible y después de verificar que ningún monitor, callback o flujo operativo siga utilizándolo. Los cambios en dominios de puertos son mutaciones y aparecen en el audit log.
¿Cómo se resuelven los errores de DNS, TLS y de la aplicación?
Usa un diagnóstico por capas:
| Síntoma | Primera comprobación | Comando de Dockup |
|---|---|---|
| El dominio no resuelve | Registro DNS y propagación | domain verify |
| No se emite el certificado | Estado de verificación del dominio | domain list, domain ssl |
| HTTPS funciona, pero la aplicación da errores | Logs de ejecución | logs --json |
| Bucle de redirección | Configuración de proxy/host de la aplicación | env list, logs de ejecución |
| La URL de plataforma funciona, pero el host personalizado falla | Capa de DNS/TLS | Comandos de dominio |
| Fallan ambas URL | Deployment y ejecución | status, logs de build/ejecución |
| Falla el puerto secundario | Mapeo del dominio de puerto y proceso | port list, logs de ejecución |
Inspecciona la salida del servicio sin mezclarla con conclusiones sobre el DNS:
dockup logs production/web --json
dockup status production/web --json
Si un cambio reciente del entorno ha añadido la URL canónica, recuerda que requiere un nuevo deploy:
dockup env set APP_URL=https://app.example.com \
-s production/web \
--json
dockup deploy production/web --wait --json
La guía de variables de entorno y secretos explica ese ciclo de vida.
Eliminación del dominio y rollback
Eliminar la asociación con Dockup es destructivo para la ruta, así que primero mueve o elimina el registro DNS público y confirma cuál será el reemplazo. Después, elimina la asociación mediante la interfaz de dominios compatible usando el ID de dominio exacto.
No elimines el dominio durante una incidencia temporal de certificado o propagación, salvo que el plan de recuperación lo requiera. Mantener la configuración permite que la verificación se complete cuando se actualicen las cachés.
Revisa las mutaciones con:
dockup audit --search domains --json
El audit trail debería mostrar quién añadió, verificó, protegió o eliminó el hostname.
Checklist de handoff a producción
Un handoff completo de dominio personalizado y TLS automático incluye el destino del servicio, el hostname, el ID de dominio, el tipo y destino del registro DNS, el resultado de la verificación, el resultado del certificado, los cambios en las callbacks de la aplicación, la URL de monitorización y el valor DNS de rollback.
No guardes ninguna clave privada de certificado en el repositorio ni en el contenedor. La frontera de TLS gestionado de Dockup existe precisamente para que el equipo de la aplicación pueda operar el hostname sin distribuir material de certificados.
Para consultar cualquier flag actual, utiliza la referencia de Dockup CLI. Para el deployment inicial antes de trabajar con el dominio, sigue Del repositorio Git a producción.
Planifica las opciones de apex y subdominio
Un subdominio como app.example.com suele ser el hostname de aplicación más sencillo, porque los proveedores de DNS pueden representarlo con un CNAME. Un apex como example.com puede requerir flattening o un comportamiento de alias específico del proveedor. Sigue el destino DNS devuelto por Dockup y las capacidades del proveedor de DNS autoritativo.
Elige un único host canónico y redirige las alternativas en la capa de aplicación o routing. Servir www y el apex sin una política canónica puede dividir las cookies, las analíticas, las entradas de caché y la indexación en buscadores.
Comprueba las condiciones de renovación del certificado
El TLS gestionado elimina la necesidad de ejecutar un cliente de renovación dentro del contenedor, pero el hostname debe seguir resolviendo correctamente. Una futura migración de DNS, un cambio de proxy o un registro eliminado pueden romper la validación.
Incluye el estado del dominio en las revisiones rutinarias:
dockup domain list production/web --json
dockup uptime production/web --hours 24 --json
El runbook de dominio personalizado y TLS automático debería indicar quién es responsable del DNS, el contacto de renovación y la fecha de la última comprobación externa del certificado. Así se evita descubrir quién es el responsable solo cuando ocurre una incidencia con el certificado.
Protege los hostnames que no sean de producción
Los hostnames de staging y preview pueden exponer funcionalidades sin terminar y datos con estructura de producción. Usa autenticación de aplicación cuando sea necesario, define una política de indexación en la capa de aplicación y limita la distribución de las URL que no sean de producción.
Las directivas para buscadores no son un mecanismo de control de acceso. Un entorno protegido sigue necesitando autenticación y un tratamiento adecuado de los datos.
Vuelve a comprobar después de la propagación
Repite las pruebas externas de HTTPS y de callbacks cuando haya transcurrido por completo el TTL DNS original.
Empieza con un deployment verificable
Asocia primero un hostname que no sea crítico, conserva la URL de plataforma durante la propagación y registra el valor DNS exacto necesario para el rollback.
Empieza gratis en app.dockup.ai. El plan Free cuesta $0 al mes, incluye $10 de crédito inicial y admite un workspace, tres bases de datos y tres deployments.
Preguntas frecuentes
¿Qué registro DNS necesita un dominio personalizado de Dockup?
Ejecuta dockup domain add y crea el registro DNS que aparece en su respuesta. Usa el destino devuelto en lugar de copiar un valor de otro servicio.
¿Cuándo puede Dockup emitir TLS para un dominio personalizado?
Cuando el registro DNS del hostname haya superado la verificación de dominio de Dockup, solicita la emisión del certificado con el comando documentado domain ssl.
¿Mi contenedor necesita almacenar certificados TLS?
No. Dockup gestiona TLS para el dominio personalizado verificado, por lo que el contenedor de la aplicación no necesita archivos de certificado ni un proceso de renovación.
¿Puede Dockup exponer un puerto adicional del contenedor?
Sí. Los comandos de puertos pueden crear un dominio independiente generado automáticamente para un puerto público adicional sin necesidad de DNS personalizado.
¿Qué debo comprobar cuando la URL de plataforma funciona, pero el dominio personalizado falla?
Céntrate en los registros DNS, la propagación, la verificación del dominio y el estado del certificado. La URL de plataforma operativa indica que probablemente la capa de aplicación funciona.