2.7 KiB
Deployment V1
Target control plane: Portainer at https://docker.cin.su.
Recommended V1 deployment topology:
assistant-core-runtimeassistant-continuity-runtimeassistant-commit-runtime(isolated privileged runtime)assistant-cognitive-worker(replaceable, no canonical ownership)- PostgreSQL 18.6
- NATS as replaceable integration transport
Temporal is intentionally not the canonical owner of future obligations. If/when Temporal is added, loss of Temporal must be recoverable from canonical continuity state.
The initial stack definition is deploy/docker-compose.prod.yml. Portainer may deploy it from Git after the repository has been pushed.
Credentials/API deployment automation is deliberately not embedded. Use PORTAINER_API_KEY from an external secret source or deploy through Portainer UI/API after authenticating.
The single Creator login is configured with external CREATOR_USERNAME and CREATOR_PASSWORD values. They issue the same bounded Creator session and never select Actor, Principal, Scope or Authority. Keep CREATOR_BOOTSTRAP_TOKEN as a separate recovery/automation credential; none of these values belongs in Git, compose defaults for production, image layers or logs.
In production, CREATOR_PASSWORD, CREATOR_BOOTSTRAP_TOKEN, and CREATOR_SESSION_SIGNING_KEY are materialized as files in the external assistant_core_secrets Docker volume. core-runtime receives only the corresponding _FILE paths and mounts that volume read-only. Direct environment values remain a development compatibility path and fail closed if combined with _FILE.
PostgreSQL recovery
Production backups run only on docker.cin.su; this project must not use the shared docker-test host. deploy/backup-postgres.sh creates an atomic, mode-0600 logical backup under /home/m/assistant-backups/postgres. Each completed directory contains the application database, cluster roles without role passwords, database/owner metadata, and SHA256SUMS. Partial output is never promoted to a completed backup directory, and no automatic retention deletion is performed.
deploy/verify-postgres-restore.sh <backup-directory> verifies all hashes and restores into an isolated PostgreSQL 18.6 container backed by tmpfs. It never mounts or writes assistant_assistant_pg, and removes its temporary container on exit. A backup is operationally accepted only after this restore check passes.
The production user crontab installs the single entry from deploy/cron/assistant-postgres-backup.crontab. It runs the backup and restore check daily at 00:15 UTC (03:15 Europe/Moscow), survives host reboot without a persistent login session, and writes a private operational log beside the backups.