Upgrade Jetrepo

Back up, rebuild, migrate, verify, and plan for rollback limits.

Upgrade between trusted revisions through docker-compose.prod.yaml. Migrations move forward; the repository does not provide automatic database downgrade or a compatibility matrix.

Access

You need host, deployment-secret, database, storage, backup, and change administration.

Prepare the release

Review target changes or release notes when available; do not assume every revision supplies release notes.
Record current and target source revisions, resolved image digests, configuration, and baseline smoke-test results.
Prove an isolated restore of the recovery point you will use.
Stage the exact release pair with representative restored data.

No exact-release upgrade, migration-failure recovery, clean-host rollback, or old/new schema pairing has been project-drilled.

Build and deploy

From the target trusted checkout, validate without printing secrets and build the production images.

docker compose -f docker-compose.prod.yaml config --quiet
docker compose -f docker-compose.prod.yaml build

Freeze writes and take the tested, coordinated Postgres/object recovery point. Preserve or explicitly omit Redis according to the recorded recovery policy. Follow Backup and restore; keep public ingress in maintenance.
Start the target stack.
```
docker compose -f docker-compose.prod.yaml up -d
docker compose -f docker-compose.prod.yaml ps -a
docker compose -f docker-compose.prod.yaml logs --tail=200 migrate
```
up recreates the migration one-shot. Core API, Delivery API, and Worker wait for it to exit 0. Admin app does not wait for migration, so do not reopen ingress merely because Admin is running.
Stop on migration failure. Do not force dependent services past the migration gate.
Before reopening ingress, test sign-in, a safe content read and write, published delivery, upload, Worker metadata, preview, public original download, and a signed image transform.

Choose the return path

Migration did not run: return to the prior trusted checkout, images, and coherent configuration, then recreate and verify the prior stack.
Schema migrated: if backward compatibility for this exact release pair is not proven, restore Postgres, objects, and selected Redis state from the pre-upgrade set before starting prior applications.
Restore fails in isolation: do not cut over; preserve the known recovery set and diagnose the failed target.

The production definition uses floating tags for the Image service and object-setup client. Record resolved digests because those dependencies can change without a Jetrepo source revision.