Deployment, Backup and Recovery

Configure a production release, deploy with immutable images, roll back to a recorded tag, and plan your own backup strategy.

Prepare a production release

The production authority is infrastructure/alicloud/docker-compose.core.yml, with deploy.sh and rollback.sh in the same directory. Use env.example as your template. You need to supply protected production values—not historical environments, database backups, or development defaults.

Production requires the Core database, Redis, object storage, a private mail adapter, Web, Nginx, and observability services. Configure your own domain, HTTPS, volume permissions, and network boundaries. This guide doesn't 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 aren't 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 also needs real provider configuration from its template. fake-email is for testing only. An accepted API request doesn't prove real inbox delivery.

Deploy and collect evidence

Pass quality, isolated smoke, and browser acceptance first, then publish the matching images. IMAGE_TAG must be sha- followed by the real, published 40-character lowercase hexadecimal commit. Don't 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 the 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—don't expose them for external probes.

Rollback is not database restoration

The target tag must exist in the 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 the immutable-image and health contracts. It doesn't 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 aren't complete user-data backups. Protect the database, objects, required configuration, and keys separately; define a consistent recovery point and restoration order, then rehearse in isolation. Don't 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 doesn't prove recoverability.