Caught on the first real deploy to optical-dev. Two separate bugs.
Dockerfile — runner stage was missing tsx + @prisma/adapter-pg + bcryptjs
The Next.js standalone bundle covers the app, but prisma/seed-dow.ts
is a separate .ts file executed via tsx (not bundled). Runner only
explicitly installed prisma + dotenv, so `npm run db:seed` failed with
"sh: tsx: not found" and deploys couldn't run the one-time seed.
→ Added tsx, @prisma/adapter-pg (seed uses PrismaPg directly), and
bcryptjs (seed hashes the admin's temp password) to the
`npm install --no-save` line in the runner stage. Adds ~15 MB to
the final image — worth it for a working seed path.
/api/health was 503 pre-seed, which made deploy.sh unwillingly block itself
The probe in deploy.sh uses `curl -sf` and treats any non-2xx as
"not ready". The health endpoint flipped the entire `healthy` flag to
false when `organizations` or `pipeline_templates` counted zero —
meaning a freshly-migrated-but-not-yet-seeded app was classified as
unhealthy, deploy.sh gave up at Step 6, and we never got to Step 7
(Apache config) or Step 8 (UFW). End result: the URL 404'd because
Apache wasn't proxying anything to the container.
→ Split liveness from readiness:
- GET /api/health (default) — DB reachable, pgvector installed,
AUTH_SECRET set, DEV_BYPASS off. Empty tables are reported as
"warn" but do NOT 503. This is what deploy.sh waits on.
- GET /api/health?strict=1 — same checks PLUS org + templates
present. Use post-seed to verify everything landed.
- Added a "mode" field ("liveness" | "strict") so which mode was
used is visible in the response.
- Pre-seed content-level checks now return status: "warn" with a
hint to run `npm run db:seed`, instead of hard-failing.
Net effect for a fresh deploy:
./deploy.sh → builds, runs migrations, reports healthy once DB +
env are good, configures Apache, DONE. Then you can
`docker compose -p dow-prod-tracker exec app npm run db:seed`
at your leisure.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2b18c99296