mipo
Menu
ProductFeaturesArchitectureSecurityComplianceDocsGitHub
Guide

Operations: Upgrade

An evaluator-facing overview of the in-place upgrade flow and its safety model. This is not the operational procedure.

Operators: use the runbook in your release bundle

The step-by-step upgrade procedure ships with every mipo release at docs/operations/upgrade.md. That file is the authoritative reference. Follow it instead of this page.

The upgrade flow

  1. Pull the new images (does not touch running containers).
  2. Preflight gate: mipo.sh deploy runs the migrator preflight FAIL-CLOSED before any schema-writing app role is stopped and before any migration runs — DB connectivity, schema drift, disk free, scanner protocol compatibility, app-version downgrade. Backup recency is reported as an informational line only and never blocks the deploy (owner decision 2026-07-08). (Images are pulled and the proxy is recreated first; a preflight failure leaves the app serving and the database untouched.)
  3. Quiesce: the schema-writing app roles (manager, ingest, dispatcher, maintenance) are stopped so no old writer races the migration. The proxy and database stay up.
  4. Migrate: forward-only schema migrations run with the app quiesced.
  5. Roll out: the new images start and the app comes back up.

When is a backup required?

A deploy never wipes data by itself — it applies forward-only (additive) migrations. The backup gate guards only the one risky case: mutating the schema of an install that already holds data.

  • In-place upgrade (new version over an existing install): Required — a fail-closed gate blocks the upgrade without a recent backup
  • Fresh / Day-0 install (empty cluster): Not required — the gate auto-skips (nothing to protect)
  • Wipe and reinstall (reset --all): Not required — you are deliberately destroying data
  • Restore from a bundle: You already hold the backup
  • Force an upgrade through anyway: MIPO_DEPLOY_PREFLIGHT=0 (break-glass; logged loudly)