gateway image cannot migrate its own database — drizzle-kit stripped by --prod deploy, no migrate step anywhere in the boot path #1137

Open
opened 2026-08-09 20:19:02 +00:00 by Ghost · 0 comments

Found by shaggy while preparing the mosaic.woltje.com stack refresh (2026-08-09); independently verified by fred against origin/next.

Defect

The published gateway image has no way to apply schema migrations:

  • docker/gateway.Dockerfile runner stage copies only /deploy/node_modules, package.json, and dist, then CMD ["node", "dist/main.js"] — no migrate step, no entrypoint script.
  • drizzle-kit is a devDependency of packages/db, and the image is built with pnpm --filter @mosaicstack/gateway --prod deploy --legacy, which strips dev dependencies.
  • apps/gateway/src/main.ts runs detectAndAssertTier() as pre-flight and then boots Nest. It never applies migrations.

packages/db/drizzle/ currently holds 17 migrations (0000_loud_ezekiel_stane.sql0016_salty_morlocks.sql), all of which must be applied out of band, by a human with a checkout, before a new gateway version boots against an older database.

Why it matters

Every production/staging deploy of the gateway forever requires a manual pnpm db:migrate from a workstation with network reach to the database. That is survivable for a single-operator homelab cutover (and is the plan for the first mosaic.woltje.com deploy) but it is a standing operational trap: forget the manual step and the gateway boots against a stale schema.

Suggested fix

Publish a one-shot migration-runner image (pattern already exists in-repo: mosaic-db-init / synapse-db-init) that contains drizzle-kit + packages/db/drizzle/, suitable for a db-migrate service in Swarm stacks / an initContainer in k8s. Alternatively bundle a production-safe migrate entrypoint into the gateway image behind an explicit flag.

Refs: docs/scratchpads/mosaic-woltje-stack-proposal.md §7 in jarvis-brain (shaggy, gated by fred).

Found by shaggy while preparing the mosaic.woltje.com stack refresh (2026-08-09); independently verified by fred against `origin/next`. ## Defect The published gateway image has no way to apply schema migrations: - `docker/gateway.Dockerfile` runner stage copies only `/deploy/node_modules`, `package.json`, and `dist`, then `CMD ["node", "dist/main.js"]` — no migrate step, no entrypoint script. - `drizzle-kit` is a **devDependency** of `packages/db`, and the image is built with `pnpm --filter @mosaicstack/gateway --prod deploy --legacy`, which strips dev dependencies. - `apps/gateway/src/main.ts` runs `detectAndAssertTier()` as pre-flight and then boots Nest. It never applies migrations. `packages/db/drizzle/` currently holds 17 migrations (`0000_loud_ezekiel_stane.sql` → `0016_salty_morlocks.sql`), all of which must be applied out of band, by a human with a checkout, before a new gateway version boots against an older database. ## Why it matters Every production/staging deploy of the gateway forever requires a manual `pnpm db:migrate` from a workstation with network reach to the database. That is survivable for a single-operator homelab cutover (and is the plan for the first mosaic.woltje.com deploy) but it is a standing operational trap: forget the manual step and the gateway boots against a stale schema. ## Suggested fix Publish a one-shot migration-runner image (pattern already exists in-repo: `mosaic-db-init` / `synapse-db-init`) that contains drizzle-kit + `packages/db/drizzle/`, suitable for a `db-migrate` service in Swarm stacks / an initContainer in k8s. Alternatively bundle a production-safe migrate entrypoint into the gateway image behind an explicit flag. Refs: `docs/scratchpads/mosaic-woltje-stack-proposal.md` §7 in jarvis-brain (shaggy, gated by fred).
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#1137