hosted-0.71.4 image omitted previously shipped database migrations #7422

Summary

A self-hosted linux/amd64 deployment entered a crash loop after a pod was
recreated with an image observed for
nangohq/nango-server:hosted-0.71.4. The image digest
sha256:d4bb9b8ce574bfc497e3c41da3d318edb3d97e5048ca334e402c7ea09d4008de
did not contain four PostgreSQL migration files that had already been applied
by a previously running image of the same version tag.

Knex correctly refused to start against the existing database:

The migration directory is corrupt, the following files are missing:
20260812150000_add_clock_offset_to_user_mfa_factors.cjs,
20260818173000_create_agent_sessions.cjs,
20260819090000_plans_add_audit_trail_capabilities.cjs,
20260819090100_plans_backfill_audit_trail_control_plane.cjs

The error originates from validateMigrationList in Knex and was repeated on
every restart until the deployment was restored to a known-good digest.

Image comparison

All three images identify as linux/amd64, use
packages/server/entrypoint.sh, and were pulled directly from Docker Hub.

As of 2026-09-06, Docker Hub resolves hosted-0.71.4 to 6354048.... We are
not claiming that this current digest is broken; it has not yet been
qualified against our disposable database copy. The report is about the
observed d4bb9b8... image and the fact that migration contents differed among
images associated with the same version tag.

Reproduction without database access

image='nangohq/nango-server@sha256:d4bb9b8ce574bfc497e3c41da3d318edb3d97e5048ca334e402c7ea09d4008de'

docker run --rm --entrypoint sh "$image" -c '
  base=/app/nango/packages/database/lib/migrations
  for file in \
    20260812150000_add_clock_offset_to_user_mfa_factors.cjs \
    20260818173000_create_agent_sessions.cjs \
    20260819090000_plans_add_audit_trail_capabilities.cjs \
    20260819090100_plans_backfill_audit_trail_control_plane.cjs
  do
    test -f "$base/$file" || echo "missing: $file"
  done
'

The command reports all four files as missing for d4bb9b8... and reports
none missing for 399dd5e... or 6354048....

Expected behavior

An image published for an existing version tag should not omit migrations that
were delivered by another image for that version, because a normal reschedule
can then make an existing self-hosted database impossible to start.

Questions

1. Was d4bb9b8... intentionally published or associated with
   hosted-0.71.4?
2. Are hosted-<version> tags expected to be mutable?
3. Which immutable version/commit reference is recommended for free
   self-hosting?
4. Can the image release pipeline enforce append-only database migration
   history for an already published application version?

We have mitigated the incident by pinning the known-good digest and requiring
a disposable-database upgrade test before accepting future image changes.