Release

A read-only view of this deployment's release posture: app and image version, the schema version of each schema (config/jobs/results) against what this release requires, recent migration history, the last backup, the scanner fleet's version and protocol distribution, and the most recent preflight result.

Fields & columns

Name	Description
`App version`	The release version this manager image was built from (the compatibility manifest's appVersion).
`Image SHA`	The commit SHA the running containers were deployed from. Shows "unknown" on a dev stack that was not deployed via the release tooling.
`Schema version`	Per schema (config, jobs, results in the one cluster): the version currently applied vs. the version this release requires. "behind" means the migrator must run; "ahead" means the schema is newer than this image; "unknown" means that schema could not be read.
`Migration history`	The most recent migrations applied to each schema, newest first, with the timestamp and who applied them.
`Last backup`	The timestamp of the most recent database backup bundle, read from the backup service.
`Scanner fleet`	How many scanners are registered, grouped by binary version and wire-protocol version, and how many fall inside vs. outside the supported protocol window.
`Preflight`	The result of the most recent preflight run, if one has been recorded: the pass/fail status and per-check summary.

How to

Decide whether it is safe to apply an upgrade

Open Admin > Release.
Check each schema version: "behind" is expected before an upgrade - it means the new migrator will advance it.
Check the scanner fleet: any scanners outside the supported protocol window will stop receiving jobs after the upgrade until they are upgraded too.
Check the last backup timestamp - take a fresh backup if it is stale before migrating. Preflight reports backup age as an informational line only; a stale backup does NOT block the upgrade (it is a deployer judgment call), so decide here whether to back up first.
If a preflight result is shown, confirm it passed.

Investigate why a database will not let the app start

Open Admin > Release and find the database whose schema version is "behind".
Run the migrator (`docker compose --profile migrate run --rm migrator`) so the schema reaches the required version.
Reload this page - the status should change to "ok".

Gotchas

This page is read-only. It does not run migrations or preflight itself - those run in the migrator container, either automatically via the `mipo.sh deploy` tooling or by hand on the command line.
Image SHA shows "unknown" on a development stack. It is only populated on staging/production deploys made through the release tooling.
The `mipo.sh deploy` tooling runs the migrator preflight as a FAIL-CLOSED gate before migrating, and quiesces the app roles (manager, ingest, dispatcher, maintenance) first - so a stale/missing backup, low disk, schema drift, or an out-of-window scanner aborts the upgrade before the app roles are stopped or the proxy is recreated, so the previous version keeps serving and the database is untouched. A hand-run `docker compose --profile migrate run --rm migrator` does NOT gate - run `... migrator preflight` yourself first.
The backup gate applies only to an in-place upgrade (an install that already has a schema). A fresh/Day-0 install skips it (nothing to protect), and `reset`/`restore` do not run it. Operators can bypass the gate with `MIPO_DEPLOY_PREFLIGHT=0` (CI staging does; production leaves it enforcing). The authoritative runbook is `docs/operations/upgrade.md`.
The preflight section is empty until a preflight run has been recorded.
A schema version of "behind" immediately before an upgrade is normal - it is the migrator's job to advance it. "ahead" is the unusual one: the database is newer than the running image.
A schema version of "unknown" means the page could not read that database's migration ledger - that is a connectivity problem, not a pending migration.

API calls (1)

Method	Path	Description
GET	`/api/admin/release`	Returns the aggregated release posture rendered by this page.

Database Status — Database Status shows live DB health; Release shows schema versions and migration history.
Backups — Release shows the last backup timestamp; Backups is where you take and manage them.