2.0 KiB
Fresh production setup
Production uses main, /home/zak/magent-production on AMS-DEV01 and
docker-compose.production.yml. The legacy prod deployment and beta are not
overwritten. Main runs CI verification; production activation is deliberately
manual during the initial cutover.
Only API connection URLs/credentials and SMTP configuration are exported by
scripts/prepare_production_settings.py. It reads the source's effective settings,
uses an explicit allowlist, refuses existing output directories, and creates
private files. It never copies a database, users, invite codes, issues, history,
tokens, sessions, branding or notification templates. A new bootstrap admin and
JWT secret are generated. Retrieve the bootstrap credentials from the protected
bootstrap-admin.json on the server; never commit them.
The initial production .env enables MAGENT_COMING_SOON=true and disables
BACKGROUND_TASKS_ENABLED. This presents the cover at / and pauses automatic
imports and repair emails. The cover is not an authentication/security boundary;
normal API authentication remains in force. Administrators can use /login.
Run docker compose -f docker-compose.production.yml up -d --build from the
production directory. Caddy should proxy this hostname to 10.30.1.32:3200;
Next forwards /api internally. The backend health port is localhost-only at
8200. Do not alter beta's route or other Caddy sites.
Before public activation, validate Caddy config, save its existing configuration, verify HTTPS, admin login, connection diagnostics and the empty-client-data state. Do not send SMTP tests without approval. Keep the old upstream for rollback.
At launch, set MAGENT_COMING_SOON=false and BACKGROUND_TASKS_ENABLED=true,
then recreate the container. External service records can then be imported through
normal synchronization; no beta client data is migrated. Review quality profiles,
root folders, invite policy and notification rules in admin settings before use.