Assessor_2.0/docs/DEPLOYMENT.md

Parallel deployment

Environments

The Gitea workflow deploys two permanent, isolated environments on the target server. The old HTTPS installation is outside this workflow and remains unchanged until a separately approved cutover.

Branch	Compose project	VPN address	Secret
main	assessor_prod	http://10.0.0.154:4173	PROD_ENV_FILE
experimental	assessor_experimental	http://10.0.0.154:4174	STAGING_ENV_FILE

assessor_prod already exists on the server. Keep its current PROD_ENV_FILE database name, user and password unchanged so the existing PostgreSQL volume remains accessible. Do not rotate only the secret; password rotation requires a coordinated PostgreSQL role change.

STAGING_ENV_FILE contains a complete environment file with credentials that are distinct from stable:

ASSESSOR_POSTGRES_DB=assessor_experimental
ASSESSOR_POSTGRES_USER=assessor_experimental
ASSESSOR_POSTGRES_PASSWORD=replace-with-a-long-random-experimental-password

Do not reuse the stable database name, user, or password for experimental. Secret values must never be printed into an Actions log.

Optional AI Overview settings may be added only when the company-managed LiteLLM gateway is approved for the privacy-safe ASSESSOR payload:

ASSESSOR_AI_MODE=litellm
ASSESSOR_AI_BASE_URL=https://work-litellm.example/v1
ASSESSOR_AI_MODEL=approved-model-alias
ASSESSOR_AI_API_KEY=<deployment secret>
ASSESSOR_AI_TIMEOUT_MS=60000
ASSESSOR_AI_CHUNK_CHARS=80000
ASSESSOR_AI_MAX_OUTPUT_BYTES=262144
ASSESSOR_AI_MAX_CALLS=64
ASSESSOR_AI_JOB_LEASE_MS=300000

Do not place these values in the repository or expose them through client-side configuration. The workstation uses the ignored .env.postgres; staging and production use their existing complete environment-file secrets. See AI_OVERVIEW_SECURITY.md for the transmitted-data and trust-boundary contract.

To upload the licensed DIN ISO 27001 and 27002 PDFs from Data Hub, add the following values to the environment's STAGING_ENV_FILE or PROD_ENV_FILE:

ASSESSOR_QDRANT_API_KEY=<independent Qdrant secret>
ASSESSOR_RAG_EMBEDDING_BASE_URL=https://approved-embedding-gateway.example/v1
ASSESSOR_RAG_EMBEDDING_MODEL=<approved-embedding-model>
ASSESSOR_RAG_EMBEDDING_API_KEY=<embedding gateway secret>
ASSESSOR_RAG_EMBEDDING_DIMENSIONS=1024
ASSESSOR_ISO_UPLOAD_TOKEN=<independent random token of at least 32 characters>

The operator enters the upload token in Data Hub; it is checked by the backend before either PDF is read and is not saved in browser storage. Keep the LiteLLM settings above as well to enable mapping after indexing. The upload stores the generated corpus privately in the environment's artifact volume, deletes temporary original PDFs after parsing, and activates a new version only after successful embedding. No server shell or manual corpus-version environment edit is needed for this workflow. Use an embedding destination approved for the licensed ISO text. The token protects only this upload action; it does not add general user authentication.

Mandatory server inventory

Before the first push-triggered deployment, connect to the target server over SSH and perform a read-only inventory. Record only technical identifiers; do not inspect database rows, uploaded files, application pages, or report text.

docker version
docker compose version
docker ps -a --format '{{.Names}}\t{{.Image}}\t{{.Ports}}\t{{.Label "com.docker.compose.project"}}'
docker volume ls
docker network ls
docker ps --filter publish=4173 --format '{{.Names}}\t{{.Ports}}'
docker ps --filter publish=4174 --format '{{.Names}}\t{{.Ports}}'

Also identify the existing reverse proxy and firewall policy without changing them. Confirm that 10.0.0.154 is a host address, port 4174 is unused, the runner uses this Docker daemon, and assessor_experimental does not belong to an unrelated stack. Port 4173 and project assessor_prod are intentionally adopted as stable; only its expected app, postgres, and qdrant services may exist. Any other conflict blocks deployment and is never resolved by stopping or deleting the existing resource.

Deployment behavior

Pushes to a branch are serialized per environment with an atomic lock container on the shared Docker host. This is necessary because Gitea currently ignores the GitHub-compatible workflow concurrency key. A normal job removes its lock; a crashed job's --rm lock expires after two hours. The workflow installs dependencies, runs the complete test suite and production build, validates the resolved Compose configuration, checks port/project isolation, backs up an existing target environment, then builds and starts only that environment.

Compose project scoping produces independent PostgreSQL, artifact, report-archive and Qdrant volumes. The Report Engine (2.10.0) archives every report run write-once under ASSESSOR_REPORT_ARCHIVE_DIR (/var/lib/assessor/report-archive in Compose). The archive holds complete technical customer data, is deleted together with its client and must be included in backup and retention decisions like the artifact volume. The Report Engine reads PostgreSQL through its own pool with default_transaction_read_only=on; it runs no migrations and writes nothing to the database. PostgreSQL and Qdrant have no host-published ports. Qdrant is an authenticated, rebuildable regulatory index; its volume improves restart time but is not a system-of-record backup. restart: unless-stopped preserves both environments across Docker daemon and server restarts.

Feature promotion is a merge from experimental to main. Stable is rebuilt from the merged commit; databases and artifacts are never copied between the environments.

Backups and restore checks

Before every update of an existing environment, the workflow writes a custom PostgreSQL dump, an artifact archive and SHA-256 checksums to the external Docker volume assessor_deployment_backups:

<compose-project>/<UTC timestamp>/postgres.dump
<compose-project>/<UTC timestamp>/artifacts.tar.gz
<compose-project>/<UTC timestamp>/SHA256SUMS

The workflow never deletes backups. Retention and off-host copying require a separate approved operations policy. The backup volume must be included in the server's protected backup system; a volume on the same Docker host is not a complete disaster-recovery copy.

Restore tests must use an isolated temporary Compose project and synthetic data. Verify SHA256SUMS, restore postgres.dump with pg_restore --exit-on-error into a fresh database, extract the artifact archive into a fresh artifact volume, and confirm only content-free counts and health state. Never restore an experimental backup into stable or a stable backup into experimental. Never run docker compose down --volumes for either permanent environment.

Acceptance and later cutover

After deployment, verify both in-container health checks and VPN access. Import different synthetic fixtures into stable and experimental, redeploy each branch, and confirm persistence and isolation. Confirm the old HTTPS site remains available without reading its domain content.

Changing assessor.soc-ops.de is not part of the deployment workflow. After explicit production acceptance, validate the existing proxy configuration, preserve its old upstream, point it to stable, reload it, and verify TLS and health. Rollback restores the saved upstream; the archived old stack and its data must remain recoverable until a later retention decision.