express-prisma-coolify-image

The image carries compiled code, production dependencies and the migrations, applies pending migrations before it listens, and reports ready only when it can reach its database. Because a rolling update runs the new container beside the old one, every migration must be compatible with the previous release: expand, migrate, contract.

Hard rules: never break these

• Build natively on the runner, copy artifacts into the image. No pnpm install inside Docker, no build on the server.
• Migrations run in the entrypoint, with prisma migrate deploy, never migrate dev, db push or migrate reset. The entrypoint applies them and then execs the server, so a failed migration stops the container before it takes traffic.
• Applied migrations are immutable. CI rejects any edit, rename or deletion under prisma/migrations; a mistake gets a new migration.
• Every release starts from a restore-verified backup. The deploy job takes one before touching the tag (the vps-ops-toolkit skill provides it).
• Readiness means the database answers. The probe calls the readiness route that runs a trivial query, so a container that cannot reach Postgres never takes traffic.
• Non-root user, no host ports, a stop that finishes within 10 s.

Step 1: Audit the API

cat package.json | jq '{scripts, engines, packageManager}'
ls prisma prisma/migrations | head; cat prisma.config.ts 2>/dev/null
grep -rn "process.env" src/config | head -40
grep -rn "health" src/routes src/modules 2>/dev/null | head

List the runtime variables the app validates at boot (database URL, secrets, allowed origins, feature switches) and which have safe values for a smoke test. Note native or downloaded dependencies (a headless browser, image libraries): they must be fetched on the runner and copied in, with their shared libraries installed in the image.

Step 2: Add the runtime files