Skip to main content
This procedure is for the Docker deployment described in Deploy on a Server. deploy.sh stops the current stack before starting the new one, 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.

​
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

The script rebuilds the image if its definition changed, starts the four services and tails their logs. Watch for startup or schema errors. The first boot may reinstall Python dependencies.
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.

​
Rollback

Stop the app and worker, restore the database and any local uploads from the pre-upgrade backup, restore the matching keys and configuration, then return the checkout to the recorded commit and start it. Follow Verify and Restore a Backup for the restore commands. Treat the backup as a unit: restoring only code after a schema change can leave the old release reading a newer database.