Instalación on-premise

AppArch puede ejecutarse íntegramente en su propia infraestructura. El equipo de AppArch le entrega el paquete de instalación y la licencia como parte de su contrato.

Lo que necesita antes de instalar

Elemento	Para qué sirve
Licencia	Define los límites y la vigencia de su instalación, y solo funciona en una instalación. Las instalaciones con conexión la obtienen automáticamente en el primer arranque con sus credenciales de instalación; las instalaciones aisladas reciben un archivo `apparch.lic` vinculado a su código de instalación - consulte Una licencia, una instalación.
ID de instalación	El usuario para iniciar sesión en el registro de imágenes de AppArch.
Clave de instalación	La contraseña de ese mismo inicio de sesión. Se entrega una sola vez.
Paquete de instalación	Los archivos de configuración que levantan los servicios y la guía paso a paso.

El ID y la clave pertenecen a su licencia: las imágenes no se listan públicamente y solo pueden descargarse con estas credenciales.

docker login hub.apparch.io -u <id-de-instalación> -p <clave-de-instalación>

Cuando el inicio de sesión funcione, siga los pasos de su paquete de instalación para arrancar los servicios.

Una licencia, una instalación

No hay ningún archivo de clave que colocar: la clave que demuestra que una licencia fue emitida por AppArch viene integrada en las imágenes.

Una licencia funciona en una sola instalación. La primera instalación que la obtiene en línea (ID + clave de instalación) la vincula a sí misma; otra instalación que solicite la misma licencia es rechazada con el mensaje “Esta licencia ya está en uso por otra instalación”.

Una instalación es todo lo que comparte una misma base de datos: cada pod o réplica lee el mismo código de instalación, así que escalar la Api o la UI a varios pods funciona con la misma licencia y no requiere nada de AppArch.

Las instalaciones aisladas reciben un archivo de licencia vinculado a su código de instalación:

Arranque los servicios.
Abra el paso de licencia del asistente de configuración y elija la opción de pegar un archivo de licencia o, en una instalación ya configurada, vaya a Administración → Ajustes → Licencia.
Copie el código de instalación que se muestra y envíelo a AppArch.
Coloque el archivo .lic que reciba en ./license/apparch.lic o pegue su contenido en el asistente.

Ese archivo solo funciona en esa instalación.

Traslado a un servidor nuevo: pida a AppArch que libere la licencia y luego vuelva a obtenerla desde el servidor nuevo.

Mantener la licencia vigente

Una instalación en línea se comunica con AppArch cada hora (https://gateway.apparch.io, HTTPS saliente). Cada comprobación renueva su licencia; no hay que hacer nada a mano, pero el servidor debe poder llegar a esa dirección.

Una licencia con fecha de fin sigue funcionando dos semanas sin una comprobación correcta, así que un cambio en el cortafuegos o una caída no detiene nada de inmediato. Si pasan dos semanas sin ninguna, la instalación se detiene hasta que vuelva a llegar a AppArch.
Una licencia sin fecha de fin no depende de la comprobación.
Las instalaciones aisladas (air-gapped) nunca se comunican: su archivo de licencia funciona hasta su fecha de fin.

Cuando la instalación se detiene - la licencia fue revocada, la comprobación falló durante dos semanas o la licencia caducó hace más de 14 días - todas las pantallas salvo Administración muestran “Esta instalación está detenida” con el motivo, y no se analiza ni se registra nada. Los pasos de CI no fallan: el collector muestra un aviso y termina correctamente, así que una licencia nunca bloquea sus merge requests. Instalar una licencia válida en Administración → Ajustes → Licencia levanta la detención al momento, sin reiniciar.

Límites mensuales. Su licencia puede limitar los informes de ArchScan, las ejecuciones de ArchSecurity y los comentarios de ArchPilot por mes natural, para toda la instalación. Un informe por encima del límite no se guarda y el collector termina con un aviso; ArchPilot sigue registrando revisiones pero deja de publicar comentarios en las merge requests. Los límites se reinician el día 1 de cada mes; el uso actual aparece en Administración → Ajustes → Licencia.

Funciones con licencia. Tres funciones dependen de su licencia: el inicio de sesión único (acceso con LDAP), el registro de auditoría (ver Administración → Auditoría; las acciones se registran siempre) y los informes avanzados (exportación de informes y correos de informes programados). La misma página de licencia muestra cuáles incluye la suya.

Requisitos del servidor

Docker Engine 24+ con el plugin compose
PostgreSQL y Redis (incluidos en el paquete de instalación)
Una dirección HTTP(S) accesible para sus usuarios
Instalaciones en línea: HTTPS saliente hacia gateway.apparch.io (comprobación horaria de la licencia) y hub.apparch.io (imágenes)

Después de instalar

En el primer arranque aparece el asistente de configuración, donde crea la cuenta de administrador.
El esquema de base de datos se actualiza solo en cada arranque: nunca ejecuta SQL a mano.
El correo (SMTP o Postmark), el inicio de sesión LDAP y la renovación de licencia se gestionan desde el área de Administración dentro de la aplicación.

La licencia on-premise y los precios los gestiona el equipo comercial: apparch.io.

Observar un arranque

La API narra su arranque en el log del contenedor (docker compose logs -f api): conexión a la base (host y puerto, nunca credenciales), bloqueo de bootstrap, migraciones pendientes, seed de datos de referencia, carga de la licencia y, al final, Boot complete - accepting requests. Si falla, una sola línea sobre la traza nombra la fase que murió.

Puntos de salud

Ambos contenedores exponen sondas sin autenticación:

Punto	Significado
`GET /health/live`	El proceso sirve HTTP. Sin comprobación de dependencias.
`GET /health/ready`	Listo para tráfico - la API comprueba PostgreSQL y Redis, la UI comprueba la API.

El docker-compose.yml incluido los cablea como healthchecks de contenedor (la UI espera una API sana, no meramente arrancada). En Kubernetes: livenessProbe a /health/live, readinessProbe a /health/ready, con una ventana de arranque generosa para la API - el primer arranque ejecuta migraciones y seed.

Comprobaciones de informes

Comprobación del commit. Cada informe de ArchScan, ArchSecurity y SmartScan indica su commit, y la API lo busca en el repositorio del proyecto con la credencial del proyecto. Un commit que el repositorio sin duda no tiene se rechaza con 422 report_commit_not_found y el paso de CI falla: el token del proyecto se usa en el pipeline de otro repositorio o en trabajo nunca enviado. Si el commit no se puede comprobar (sin credencial, proveedor inalcanzable), el informe se guarda. COMMIT_VERIFICATION=Record solo registra, Off omite la comprobación.
Informes comprimidos. Los collectors actuales envían los informes comprimidos con gzip (un informe grande se reduce unas ocho veces); no hay nada que configurar.

Actualizaciones

Apunta las etiquetas de imagen a la nueva versión y docker compose pull && docker compose up -d. Las migraciones pendientes se aplican en orden, una a una, salte las versiones que salte - una instalación 1.0.0 que pasa a 1.0.12 aplica las doce en el primer arranque, bajo un bloqueo de base que serializa las réplicas. Haz copia de la base antes de actualizar; las migraciones solo van hacia delante.

Comprueba primero la licencia. La nueva imagen puede decir, antes de sustituir a la que está en marcha, si aceptará la licencia de esta instalación. La comprobación lee la base, no cambia nada y la versión actual sigue sirviendo:

APPARCH_API_IMAGE=hub.apparch.io/apparch/api:<nueva-version> docker compose run --rm --no-deps api --check-license

Termina con Result: safe to upgrade. (código de salida 0) o Result: do not upgrade yet. (código de salida 1) e indica qué falta: una instalación en línea necesita el id y la clave de instalación configurados y AppArch accesible; una aislada (air-gapped) necesita un archivo de licencia vinculado a su código de instalación en license/apparch.lic. Actualiza solo cuando pase.