SQL and Seed into App

Dockerfile

@@ -27,18 +27,13 @@ ENV DATABASE_URL="postgresql://placeholder:placeholder@localhost:5432/placeholde
 # Datenbanken wechseln kann, siehe lib/prisma.ts.
 RUN pnpm build
 
-# --- Migrator ---------------------------------------------------------------
-# Eigenstaendige, schlanke Stage nur fuer den Kubernetes-Migrations-Job
-# (k8s/04-migrate-job.yaml): "prisma migrate deploy" + "prisma db seed"
-# brauchen nur die Prisma-CLI, tsx und die paar Laufzeit-Pakete, die
-# prisma/seed.ts importiert — NICHT next/react/sharp/stripe/alle
-# devDependencies, die im vollen builder-Stage (oben) noch mit drin sind.
-# Frueher wurde builder direkt als Migrations-Image gebaut; dessen
-# node_modules-Layer wurde beim Push an die (hinter Cloudflare liegende,
-# ~100 MB Limit pro Layer) Gitea-Registry mit "413 Payload Too Large"
-# abgewiesen. Eigene, minimale Paketliste statt "pnpm install" gegen das
-# volle package.json, damit next/react/sharp erst gar nicht installiert
-# werden.
+# --- Migrator-Tools -----------------------------------------------------
+# Eigenstaendiger, schlanker node_modules-Baum nur mit Prisma-CLI, tsx und
+# den paar Laufzeit-Paketen, die prisma/seed.ts importiert — NICHT
+# next/react/sharp/stripe/alle devDependencies, die der volle builder-Stage
+# oben mitbringt. Wird unten in die runner-Stage kopiert, damit die App sich
+# beim Start selbst migrieren/seeden kann (kein separates Migrations-Image/
+# kein Kubernetes-Job mehr noetig).
 FROM base AS migrator
 # pnpm-workspace.yaml zuerst kopieren: pnpm v11 blockt Postinstall-Skripte
 # (u.a. @prisma/engines, laedt die Schema-Engine-Binary fuer "migrate
@@ -52,19 +47,6 @@ RUN pnpm add --save-prod \
   prisma@^7.9.1 tsx@^4 bcryptjs@^3.0.3 \
   @prisma/client@^7.9.1 @prisma/adapter-pg@^7.9.1 \
   @prisma/adapter-mariadb@^7.9.1 mariadb@^3.5.3
-COPY prisma.config.ts ./
-COPY prisma ./prisma
-COPY scripts ./scripts
-COPY src/lib/db-adapter.ts ./src/lib/db-adapter.ts
-COPY src/lib/password-breach-check.ts ./src/lib/password-breach-check.ts
-COPY --from=builder /app/src/generated ./src/generated
-# Nur fuer scripts/prisma-provider.mjs (schreibt die provider-Zeile passend
-# zu DATABASE_PROVIDER) und damit prisma.config.ts nicht wegen einer
-# fehlenden URL abbricht, wenn versehentlich ohne echtes DATABASE_URL
-# aufgerufen — die K8s-Job-Umgebung (04-migrate-job.yaml) setzt die echte
-# DATABASE_URL zur Laufzeit ueber das Secret.
-ENV DATABASE_URL="postgresql://placeholder:placeholder@localhost:5432/placeholder"
-CMD ["sh", "-c", "node scripts/prisma-provider.mjs && npx prisma migrate deploy && npx prisma db seed"]
 
 # --- Runtime --------------------------------------------------------------
 FROM base AS runner
@@ -76,10 +58,32 @@ COPY --from=builder /app/public ./public
 COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
 COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static
 COPY --from=builder /app/prisma ./prisma
+COPY prisma.config.ts ./
+COPY scripts ./scripts
+COPY src/lib/db-adapter.ts ./src/lib/db-adapter.ts
+COPY src/lib/password-breach-check.ts ./src/lib/password-breach-check.ts
+COPY --from=builder /app/src/generated ./src/generated
+# Eigener node_modules-Baum nur fuer Migrationen/Seed (prisma-CLI/tsx),
+# getrennt vom node_modules des Next.js-Standalone-Outputs oben (das ist
+# eine von Next.js kopierte, nicht pnpm-verwaltete Teilmenge — "pnpm add"
+# wuerde dort kollidieren). PATH macht "prisma"/"tsx" ausfuehrbar,
+# NODE_PATH ist ein Fallback fuer Node-Modulaufloesung, falls tsx beim
+# Ausfuehren von prisma/seed.ts ein Paket braucht, das der Next.js-Tracer
+# nicht schon ins Standalone-node_modules uebernommen hat.
+COPY --chown=nextjs:nodejs --from=migrator /app/node_modules ./migrate-tools/node_modules
+ENV PATH="/app/migrate-tools/node_modules/.bin:${PATH}"
+ENV NODE_PATH="/app/migrate-tools/node_modules"
 
 USER nextjs
 EXPOSE 3000
 ENV PORT=3000
 ENV HOSTNAME="0.0.0.0"
 
-CMD ["node", "server.js"]
+# Migrationen + Seed laufen VOR dem Serverstart, damit Readiness-/Liveness-
+# Probes nie gegen eine ungemigrateet Datenbank treffen — dafuer kein
+# separater Kubernetes-Job mehr noetig. Beide Schritte sind idempotent
+# ("migrate deploy" wendet nur neue Migrationen an, prisma/seed.ts
+# legt/erneuert nur das Admin-Konto) und damit bei jedem Neustart
+# gefahrlos. KEINE Beispieldaten im Image/Auto-Seed — dafuer separat
+# "pnpm db:seed:demo" (prisma/seed-demo.ts), nie automatisch ausgefuehrt.
+CMD ["sh", "-c", "node scripts/prisma-provider.mjs && prisma migrate deploy && prisma db seed && exec node server.js"]