deploy.sh recreates any changed service in place (docker compose up -d --remove-orphans), which briefly interrupts the running stack, so reserve a maintenance window. Database schema changes are additive on startup; there is no automatic down migration. A code checkout alone is not a rollback. Upgrading from 1.5.2 removes Redis from the stack; see Backup & Restore, “Upgrading from 1.5.2” for the extra steps that release needs.
Before changing code
1
Record the running version
In the engine checkout, record the current commit and confirm the service responds:The health response includes a
version field. Keep both values with the change record so you know exactly what you are returning to if a restore is needed.2
Back up data and keys
Run the repository’s backup script and move its output to storage off this host:The script backs up Postgres and local uploads when present; follow Verify and Restore a Backup for a scratch-database rehearsal and recovery steps. Preserve
.env, your config.prod.yaml or other active overlay, any .key.yaml files, and compose.override.yaml in protected storage too. The script does not include those files. Keep any external object-storage bucket backed up separately.3
Review the target release
Read the target version’s notes in and its release page. Confirm that your overlay keys and provider configuration still apply. Choose the exact release tag or commit; set
TARGET_REF to that reviewed value in your shell before continuing.Upgrade and verify
1
Switch to the reviewed release
In the same checkout, fetch and inspect the selected ref, then check it out:Check
git status --short first if you keep local changes in tracked files; Git will refuse a conflicting checkout.2
Start the new stack
compose.yaml names (falling back to the docker.1ms.run mirror, or building locally from this checkout only when neither pull succeeds), then starts Postgres, the server and the worker, plus the one-shot container that fixes upload-volume ownership, and waits for them to report healthy. No Python dependencies install at boot; that only happens inside a local build. Watch for startup or schema errors with docker compose logs -f mirobody in another terminal.3
Check the result
In another terminal, run:
mirobody should be healthy and the response’s version should match the release you selected. Sign in through the public HTTPS address, open an existing record and verify one workflow your users depend on, such as file upload or an agent answer. If the service does not become healthy, use Troubleshooting and inspect docker compose logs --tail 80 mirobody.