APP_NAME, APP_TAGLINE und APP_URL sowie SESSION_TTL_DAYS und die drei
Schalter des SSRF-Schutzes werden an den App-Container durchgereicht.
Bei APP_URL steht ausdruecklich dabei, dass daraus die WebAuthn-rpID
abgeleitet wird, dass Passkeys einen sicheren Kontext brauchen und dass ein
spaeterer Hostnamenwechsel bestehende Passkeys ungueltig macht.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Dieselbe Codebasis laeuft nativ auf dem Rechner oder komplett im Container.
docker-compose.yml mit Profilen statt mehrerer Dateien:
- "db" laeuft immer -> docker compose up -d db, App dann lokal per npm
- --profile full -> zusaetzlich der App-Container
- --profile tools -> Adminer als Datenbankoberflaeche
Dockerfile als Multi-Stage-Build auf dem Next-Standalone-Output. In die
Laufzeitschicht wandern zusaetzlich Prisma-CLI, Engines und Schema, damit der
Entrypoint beim Start "migrate deploy" ausfuehren kann. Das Alpine-Image
bekommt openssl fuer die Prisma-Engines, der Client wird zusaetzlich fuer
linux-musl-openssl-3.0.x erzeugt. Der Container laeuft als unprivilegierter
Benutzer und meldet seinen Zustand ueber /api/health.
Der Entrypoint wartet in einer Schleife auf die Datenbank, ergaenzend zum
pg_isready-Healthcheck und der depends_on-Bedingung.
scripts/setup.mjs legt die .env aus der Vorlage an und erzeugt dabei ein
zufaelliges APP_SECRET, damit die Tokens nicht mit dem Standardschluessel
verschluesselt werden.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
florian.wildeandClaude Opus 5