Deployment, Backup and Recovery

Prepare a production release

Production authority is infrastructure/alicloud/docker-compose.core.yml, with deploy.sh and rollback.sh in that directory. Use env.example as the template. The operator must supply protected production values, not historical environments, database backups or development defaults.

Production needs the Core database, Redis, object storage, private mail adapter, Web, Nginx and observability services. Configure your own domain, HTTPS, volume permissions and network boundaries. This guide does not prescribe another person's host, SSH identity or deployment address.

Check configuration

| Setting | Purpose and rule | | --- | --- | | CORE_DATABASE_URL, REDIS_URL | Active Core database and coordination; retired service schemas are not substitutes | | CORE_SESSION_SECRET, OTP_PEPPER, STORAGE_GRANT_SECRET, CORE_CALLBACK_SECRET | At least 32 UTF-8 bytes in production, pairwise distinct, with no development defaults | | EMAIL_PROVIDER_URL, EMAIL_PROVIDER_TOKEN | Core-to-private-mail-adapter connection; production token at least 32 bytes | | DEFAULT_USER_QUOTA_BYTES | Explicit nonnegative decimal integer allowance for new accounts | | CORE_ADMIN_EMAILS | Initial role selection for newly created accounts, not automatic updates to existing roles | | REGISTRY, IMAGE_TAG | Image registry and pinned commit tag that passed release gates |

The mail adapter additionally needs real provider configuration from its template. fake-email is for testing only. An accepted API request is not proof of real inbox delivery.

Deploy and collect evidence

Pass quality, isolated smoke and browser acceptance, then publish the matching images. IMAGE_TAG must be sha- followed by the real, published 40-character lowercase hexadecimal commit. Do not substitute main, latest or an unpublished local revision.

: "${IMAGE_TAG:?Set the tested immutable release tag}"
bash infrastructure/alicloud/deploy.sh "$IMAGE_TAG"

The script applies a release lock, resolves image digests, runs migration, starts services, checks health/version and atomically records current.env and historical manifests. Concurrent releases are rejected with exit 75. Wait for the active release instead of removing its lock.

After release, compare actual image digests with the manifest, check service health/version, then verify real email sign-in, a small upload, background finalization, equal downloaded contents and public/private access. Public /healthz only checks the Nginx boundary. /version, /live, /ready, /metrics and /api/v1/internal/* are private or operational; do not expose them for external probes.

Rollback is not database restoration

The target must exist in historical manifests. Set TARGET_TAG to that verified tag:

: "${TARGET_TAG:?Set a recorded rollback release tag}"
bash infrastructure/alicloud/rollback.sh "$TARGET_TAG"

Rollback follows immutable-image and health contracts. It does not promise to reverse migrations or restore changed files automatically. Check migration compatibility before releasing. Never delete persistent volumes to roll back.

Backups and restoration

Version lists, images and release manifests are not complete user-data backups. Protect database, objects, required configuration and keys separately; define a consistent recovery point and restoration order, then rehearse in isolation. Do not commit backups or attach them to public documentation.

These guides have no verified unified one-command backup procedure and make no zero-data-loss, fixed RPO/RTO or automatic disaster-recovery promise. Record backup scope, checksums, access controls and actual restore outcomes. Possessing a backup file does not prove recoverability.