deploy.sh recreates changed services. Back up data and keys before switching versions; schema changes have no automatic rollback. Review version-specific steps in the backup reference and .
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 a Docker Hub mirror, mirror.gcr.io or docker.1ms.run, or building locally from this checkout only when no 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. A stack that runs the local models keeps them: COMPOSE_PROFILES in .env starts the llama service again, and its models volume is reused, so nothing is downloaded a second time. 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.