Publicar solo la documentación en Coolify
Publica este portal como una aplicación independiente en Coolify, construida desde Git con su Dockerfile. Usa su propio dominio y recurso; el portal de firmas conserva los suyos. Este procedimiento publica documentación, no la API, la web de huéspedes ni la extensión AL. Para el sistema completo, comienza por Desplegar API, web y documentación en Coolify.
1. Preparar el repositorio y el dominio
Comprueba que la rama del repositorio remoto que seleccionará Coolify contiene estos archivos:
docs-checkin/
mkdocs.checkin.yml
docs-checkin.Dockerfile
docs-checkin.Dockerfile.dockerignore
docs.nginx.conf
requirements-docs.txt
Los cambios que solo existen en tu carpeta local, sin commit/push, no llegan al servidor. Esta guía no confirma que ya estén publicados: verifica la revisión remota antes de pulsar Deploy. Para un repositorio privado, prepara la conexión Git autorizada en Coolify.
Elige un dominio propio, por ejemplo docs-checkin.example.com, y crea su registro DNS hacia el servidor que alojará este recurso. Si Coolify administra otro servidor, no confundas esa IP con la del panel. Comprueba que cualquier registro IPv6 también alcanza el servidor correcto. Referencia oficial de DNS.
2. Crear la aplicación desde Git
En el proyecto y entorno elegidos, pulsa + New, selecciona la fuente Git disponible —repositorio público, deploy key o Git App— y elige repositorio, rama y servidor. Escoge Dockerfile como Build pack. Después de crear la aplicación, la documentación actual lo denomina Build strategy; la ubicación puede variar según tu versión. Despliegue oficial desde Dockerfile.
Pon un nombre reconocible, por ejemplo checkin-docs. El Dockerfile requiere los archivos del repositorio mediante COPY: utiliza la modalidad desde Git, no un Dockerfile pegado sin contexto de repositorio.
3. Configurar los valores del recurso
| Ajuste | Valor para este portal |
|---|---|
| Rama Git | La rama remota que contiene los archivos anteriores |
| Build pack / Build strategy | Dockerfile |
| Base Directory / raíz del repositorio | / |
| Dockerfile Location, relativa a esa raíz | docs-checkin.Dockerfile |
| Etapa de build objetivo | Dejar sin selección; se usa la etapa final |
| Ports Exposes / puerto interno | 8080 |
| Puerto del dominio, si aparece por separado | 8080 |
| Protocol | https |
| Domain | docs-checkin.example.com, sustituido por tu dominio |
| Path | Vacío; publicar en la raíz del dominio |
| Variables de aplicación | Ninguna necesaria |
| Volúmenes y base de datos | Ninguno necesario |
No elijas docs.Dockerfile: pertenece a firmas. No necesitas comandos npm, directorio dist ni buildpack Static: el Dockerfile instala las dependencias fijadas, ejecuta MkDocs strict con mkdocs.checkin.yml y copia el sitio a Nginx. Sirve en 8080 con un usuario sin privilegios.
El .dockerignore específico limita el contexto a los archivos documentales. No añadas secretos de BC, tokens o variables de la API. No se presupone una imagen GHCR publicada: Coolify construye desde las fuentes seleccionadas.
4. Configurar HTTPS y comprobar salud
En Domains, añade protocolo https, tu hostname y destino interno 8080. Si tu versión usa un campo de URL, configura ahí la misma ruta al contenedor según su interfaz. El visitante abre https://docs-checkin.example.com por el proxy; 8080 es interno. Con el proxy integrado, DNS correcto y acceso público a 80/443, Coolify gestiona el certificado TLS. Guarda los cambios. Dominios y HTTPS.
El Dockerfile ya incluye un healthcheck HTTP a http://127.0.0.1:8080/, cada 30 segundos, con timeout de 5 segundos y tres reintentos. Coolify da prioridad al HEALTHCHECK de la imagen: no hace falta duplicarlo en el panel. No cambies la comprobación interna a HTTPS. Para diagnosticarla, ejecuta en Terminal del contenedor wget -q --spider http://127.0.0.1:8080/ y revisa Runtime Logs. Healthchecks y precedencia.
5. Desplegar y verificar
Pulsa Deploy y sigue el registro: debe mostrar la revisión Git esperada, la build MkDocs estricta y el arranque de Nginx. Si aparece un enlace/ancla roto, corrige la fuente; no retires --strict para ocultarlo.
Cuando el contenedor esté sano, abre el dominio y comprueba:
- Título Check-in de huéspedes, sin navegación de firmas.
- Acceso a Web, API, Business Central, despliegue y operación, también al recargar una página interna.
- Estilos/iconos cargados y ausencia de errores 404 en assets.
- Búsqueda funcional, por ejemplo buscando
idempotencia. - Certificado HTTPS válido y recurso correcto detrás del dominio.
Anota la revisión desplegada. No basta con que termine el log: comprueba la página pública. El workflow de imágenes API/tablet no publica este portal ni actualiza automáticamente su recurso.
Actualizar y volver a una versión anterior
Para actualizar, valida la documentación, publica los cambios revisados en la rama configurada y ejecuta un nuevo despliegue de esta aplicación. Si habilitas despliegues automáticos, comprueba que su conexión/webhook apunta a esa rama. Repite las comprobaciones de navegación, búsqueda y HTTPS.
Para regresar, usa Rollback si la imagen del despliegue bueno aún está disponible; revisa la imagen elegida y sigue el log. Coolify mantiene la configuración runtime actual al usar una imagen anterior. Si se eliminó, recupera la versión de fuentes mediante el proceso Git del equipo y vuelve a construir; una entrada antigua del historial no garantiza que conserve su imagen. Rollback y retención de imágenes.
Este recurso solo contiene HTML/assets: no realiza migraciones ni modifica datos de huéspedes. Su rollback afecta al portal documental.
Problemas frecuentes
| Síntoma | Qué revisar |
|---|---|
No encuentra Dockerfile o falla un COPY |
Rama remota, archivos publicados, Base Directory / y ruta docs-checkin.Dockerfile |
| Aparece el portal de firmas | Dockerfile/recurso equivocado o dominio asociado al recurso anterior |
| Build strict falla | Primer error de MkDocs: archivo, enlace, ancla o navegación |
| Contenedor sano pero dominio incorrecto | DNS, recurso asociado al hostname, proxy y puerto interno 8080 |
No available server o contenedor unhealthy |
Runtime Logs y healthcheck HTTP / en 8080 dentro del contenedor |
| Aviso de certificado | DNS y acceso al proxy por 80/443; revisar el log del proxy |
| Página sin estilos o búsqueda | Publicación en raíz, assets y revisión desplegada; no usar prefijo de ruta sin adaptación |
| Cambios locales no aparecen | Commit remoto, rama y revisión que realmente construyó Coolify |
Los nombres del panel se contrastaron con documentación oficial el 24 de octubre de 2026; pueden cambiar entre versiones. Los valores del proyecto —Dockerfile, raíz, puerto y healthcheck— son los indicados arriba.
Anexo: validación local opcional
No necesitas instalar Python en tu equipo para que Coolify construya el portal. Si quieres revisarlo antes, desde la raíz de bc-pdf-sign, en PowerShell:
$docsVenv = Join-Path $env:TEMP 'bc-checkin-docs-venv'
python -m venv $docsVenv
$docsPython = Join-Path $docsVenv 'Scripts/python.exe'
& $docsPython -m pip install -r requirements-docs.txt
& $docsPython -m mkdocs build --strict --config-file mkdocs.checkin.yml
& $docsPython -m mkdocs serve --config-file mkdocs.checkin.yml --dev-addr 127.0.0.1:8001
Abre http://127.0.0.1:8001. En Linux usa bin/python en lugar de Scripts/python.exe. La build queda en dist/checkin-docs/; puedes cambiarla con --site-dir <directorio>. Siempre indica --config-file mkdocs.checkin.yml: el valor predeterminado construye firmas.
Opcionalmente, con Docker activo, prueba el contenedor documental:
docker build -f docs-checkin.Dockerfile -t checkin-docs:local .
docker run --rm --name checkin-docs-preview -p 127.0.0.1:8001:8080 checkin-docs:local
Detén antes la vista previa MkDocs si ocupa 8001. Estos comandos son una receta local; no confirman un despliegue en Coolify.