Sicherer Betrieb und Rollout

Die Anwendung startet ohne Schemaänderungen und ohne Demo-Seeding. Datenbankmigrationen laufen separat mit einer administrativen Rolle. Der App-Container verwendet ausschließlich kita_runtime, läuft als UID/GID 1001 und hat ein schreibgeschütztes Dateisystem mit persistenten Upload- und Cache-Volumes.

Konfiguration

Werte aus production.env.example als Hosting-Secrets hinterlegen. APP_DATABASE_URL enthält die eingeschränkte Rolle; MIGRATION_DATABASE_URL den Datenbankeigentümer. Für lokale CLI-Befehle heißt die jeweils benötigte URL DATABASE_URL. APP_DATABASE_PASSWORD ist das separate Runtime-Passwort (24–256 Zeichen); in URLs muss es URL-kodiert werden. Keine echten Secrets im Repository speichern.

AUTH_URL, NEXTAUTH_URL und NEXT_PUBLIC_SITE_URL müssen dieselbe kanonische HTTPS-Origin verwenden. Der Reverse Proxy terminiert TLS, routet intern auf App-Port 3000 und überschreibt weitergeleitete Host-/IP-Header. TRUSTED_CLIENT_IP_HEADER nur setzen, wenn der Proxy den gewählten Header (x-real-ip oder cf-connecting-ip) zuverlässig überschreibt. Ohne diese Einstellung gelten weiterhin gemeinsame globale und identitätsbezogene Datenbanklimits. Proxyseitig Body-Limit von höchstens 26 MiB, Timeouts und zusätzliche Request-Limits setzen.

Compose startet PostgreSQL standardmäßig intern. Bei einer bereits extern verwalteten Coolify-Datenbank den Stack entsprechend anpassen und deren interne URL verwenden; niemals versehentlich einen neuen leeren Datenbankdienst als Ersatz anschließen. pgAdmin ist nur im Profil maintenance und nur auf Loopback verfügbar; Zugriff über SSH-Tunnel.

Bestehende Installation aktualisieren

Datenbank und Upload-Volume sichern und Wiederherstellung überprüfen. Wartungsfenster ankündigen und alte App stoppen: das neue Schema und der neue Code gehören zusammen.
Den Zustand der bestehenden Datenbank mit prisma/migrations/20261009000000_baseline/migration.sql vergleichen. Die Baseline bildet das bisherige Schema ab. Bei Abweichungen zuerst die Unterschiede gezielt klären; eine Baseline-Markierung prüft das Schema nicht automatisch.
scripts/check-tenant-integrity.sql mit psql "$MIGRATION_DATABASE_URL" -v ON_ERROR_STOP=1 -f scripts/check-tenant-integrity.sql ausführen. Keine Ergebniszeilen bedeutet, dass keine der geprüften widersprüchlichen Tenant-Verknüpfungen vorliegt. Ergebnisse vor der Migration fachlich korrigieren; keine Daten automatisch einem anderen Mandanten zuweisen.
Nur für eine bestehende, zur Baseline passende Datenbank einmal die Baseline als bereits angewendet markieren. Bei einer leeren neuen Datenbank diesen Schritt auslassen.
Alle weiteren Migrationen anwenden, Runtime-Rolle bereitstellen und Größenmetadaten vorhandener Anhänge nachtragen.
Eigentümer bestehender Upload-/Cache-Volumes auf UID/GID 1001 vorbereiten, dann die neue App starten. Stichproben mit zwei verschiedenen Kitas und den echten E-Mail-Flows prüfen.

Compose-Beispiele (Environment-Secrets vorher bereitstellen):

docker compose -f docker-compose.coolify.yml build app migrate
# NUR bei bestehender, zuvor geprüfter Baseline-Datenbank:
docker compose -f docker-compose.coolify.yml --profile maintenance run --rm migrate npx prisma migrate resolve --applied 20261009000000_baseline
# Bei neuen und bestehenden Datenbanken:
docker compose -f docker-compose.coolify.yml --profile maintenance run --rm migrate npm run db:migrate:deploy
docker compose -f docker-compose.coolify.yml --profile maintenance run --rm migrate npm run db:provision-runtime
docker compose -f docker-compose.coolify.yml --profile maintenance run --rm migrate npm run uploads:backfill
# Nur auf dem vorgesehenen App-Upload-Volume:
docker compose -f docker-compose.coolify.yml --profile maintenance run --rm migrate chown -R 1001:1001 /app/uploads
# Falls ein bereits vorhandenes Cache-Volume root gehört: dessen Eigentümer separat korrigieren.
docker compose -f docker-compose.coolify.yml up -d app

Bei einem Rollback nach Migration zuerst Kompatibilität prüfen; das alte Image allein zurückzusetzen reicht wegen neuer Pflichtfelder nicht aus. Im Zweifel das geprüfte Backup von Datenbank und Dateien gemeinsam wiederherstellen.

Auswirkungen auf bestehende Konten

Alle JWT-Sitzungen vor diesem Release werden ungültig; erneute Anmeldung ist erforderlich. Administrative Sperren entwerten auch bei späterer Entsperrung dauerhaft die alten Sitzungen. Gründerkonten ohne Kita und ohne echte E-Mail-Prüfung registrieren sich mit derselben Adresse erneut und bestätigen den Link. Bereits bestehende Kita-Gründer behalten ihre bisherige Verifizierung; deren historische Adressen werden dadurch nicht nachträglich als echte Mailbox-Bestätigung nachgewiesen.

Neue Registrierungen bestätigen zuerst die E-Mail-Adresse, wählen anschließend ihr Passwort und erstellen erst danach eine Kita. Beim Ändern einer Elternadresse werden Passwort und bisherige Sitzungen entwertet; die neue Adresse erhält eine Einladung zum Festlegen eines neuen Passworts. Kita-Admins können die Einladung erneut senden. Neue Registrierungslinks gelten 30 Minuten, Einladungen sieben Tage und Notdienst-Bestätigungslinks höchstens 24 Stunden sowie nur für offene, noch relevante Einsätze. Bestehende UUID-Links bleiben innerhalb ihrer Laufzeit kompatibel. Zwei-Faktor-Anmeldung ist auf ausdrücklichen Wunsch vorerst nicht eingeführt.

Dateien und Wartung

UPLOAD_DIR bezeichnet die bisherige Basis; die Anwendung ergänzt announcements. Compose verwendet unverändert /app/uploads/announcements/announcements. Backfill muss genau dieselben Dateien sehen. Fehlende Dateien werden mit Größe 0 erfasst und als Anzahl gemeldet: Ursache und Datenverlust prüfen. Solange Größenwerte NULL sind, blockiert die Anwendung neue Anhänge, damit das Gesamtlimit nicht umgangen werden kann.

Grenzen: 10 MiB pro Datei, fünf Dateien und 25 MiB pro Nachricht; standardmäßig 256 MiB pro Kita und 10 GiB insgesamt, konfigurierbar über die beiden Quota-Variablen. Erlaubt sind PDF, PNG und JPEG mit passenden Dateisignaturen und Endungen. Das ist keine Virenprüfung oder vollständige PDF-Bereinigung. Downloads erfordern Sitzung, Consent und die passende Kita; sie werden als Anhang ausgeliefert.

npm run uploads:cleanup zeigt zunächst nur verwaiste Dateien mit mindestens 24 Stunden Alter. Nach Prüfung entfernt npm run uploads:cleanup -- --delete diese Dateien. Backups, Speicherüberwachung und eine Aufbewahrungs-/Löschstrategie für Backups separat einrichten. Dateien gelöschter Datensätze werden auch unmittelbar bestmöglich entfernt.

Die SQL-Migrationen ergänzen 31 zusammengesetzte Tenant-Fremdschlüssel, die Prisma wegen der vorhandenen optionalen Cascade-/SetNull-Beziehungen nicht vollständig abbildet. Zukünftige generierte Migrationen auf unbeabsichtigtes Entfernen dieser Constraints prüfen. Kein prisma db push auf verwalteten Datenbanken einsetzen. Runtime-Grants nach zukünftigen Migrationen erneut bereitstellen.

Verifikation und Updates

npm ci
npm run build:prod
npx tsc --noEmit
npm run lint -- --quiet
npm audit --omit=dev

Die Integrationstests setzen eine ausdrücklich isolierte lokale PostgreSQL-Datenbank namens kita_security_test voraus; SECURITY_TEST_DATABASE_URL darf keine Anwendungsdaten enthalten. npm run test:security prüft Aktionen und echte DB-Transaktionen. npm run test:security:http benötigt den Production-Server auf localhost:3057 mit derselben Testdatenbank, UPLOAD_DIR und dem im Test dokumentierten Test-Secret. Niemals dieses Test-Secret in Produktion verwenden.

Docker-Images sind auf Digests fixiert. Neue Sicherheitsreleases regelmäßig prüfen und die Digests bewusst aktualisieren. Zum Prüfzeitpunkt verbleibt eine ungepatchte braces-Schwachstelle in der Entwicklungs-Lint-Kette; npm audit --force löst sie nicht sinnvoll. Der Runtime-Audit ist ohne bekannte Findings. NextAuth bleibt eine Beta-Abhängigkeit und benötigt weiterhin Update-Beobachtung.