Release
A read-only view of this deployment's release posture: app and image version, the schema version of each database 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 database (config, results, jobs): the version currently applied vs. the version this release requires. "behind" means the migrator must run; "ahead" means the database is newer than this image; "unknown" means that database could not be read. |
Migration history | The most recent migrations applied to each database, 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.
- 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 - those are run from the command line with the migrator container.
- Image SHA shows "unknown" on a development stack. It is only populated on staging/production deploys made through the release tooling.
- The preflight section is empty until a preflight run has been recorded; preflight is a separate, operator-run step.
- 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. |
Related
- 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.