70 lines
3.2 KiB
Markdown
70 lines
3.2 KiB
Markdown
# Production Checklist
|
||
|
||
## 1. Domain & Basis-URLs
|
||
|
||
- [ ] Produktionsdomain festlegen: `https://[deine-domain.de]`
|
||
- [ ] `NEXT_PUBLIC_SITE_URL` auf die Produktionsdomain setzen
|
||
- [ ] `AUTH_URL` und `NEXTAUTH_URL` auf die Produktionsdomain setzen
|
||
- [ ] Nach Deployment die WhatsApp-/LinkedIn-Vorschau mit der finalen URL testen
|
||
|
||
## 2. Datenbank
|
||
|
||
- [ ] Datenbankvariante wählen: mitgelieferter Compose-Dienst oder vorhandene Datenbank
|
||
- [ ] Bei vorhandener Datenbank Compose-Konfiguration und Netzwerkverbindung auf deren interne `DATABASE_URL` anpassen; die unveränderte Vorlage verwendet den eigenen `postgres`-Dienst
|
||
- [ ] Beim ersten App-Start wird das Schema automatisch mit `npx prisma db push --skip-generate` angewendet
|
||
- [ ] Fuer spaetere Releases idealerweise Prisma-Migrationen einfuehren
|
||
|
||
## 3. Auth & Sicherheit
|
||
|
||
- [ ] `AUTH_SECRET` neu generieren: `openssl rand -base64 32`
|
||
- [ ] Keine `.env`-Dateien mit echten Secrets committen
|
||
- [ ] Dashboard ist per Metadata auf `noindex,nofollow` gesetzt
|
||
- [ ] Produktionsdomain auf HTTPS betreiben
|
||
|
||
## 4. Mail
|
||
|
||
- [ ] Eigene Versanddomain bei Resend verifizieren
|
||
- [ ] `RESEND_API_KEY` fuer Produktion setzen
|
||
- [ ] `EMAIL_FROM` auf eine verifizierte Absenderadresse setzen
|
||
- [ ] `ADMIN_EMAIL` fuer Kontaktformular setzen
|
||
- [ ] Kontaktformular und Einladung/E-Mail-Flows einmal in Produktion testen
|
||
|
||
## 5. Uploads
|
||
|
||
- [ ] Coolify-Volume `kita_planer_uploads` fuer `/app/uploads` verwenden
|
||
- [ ] Sicherstellen, dass Uploads nicht aus Versehen oeffentlich ausgeliefert werden
|
||
- [ ] Backup-Strategie fuer Uploads klaeren
|
||
|
||
## 6. Rechtliches
|
||
|
||
- [ ] Platzhalter im Impressum ersetzen
|
||
- [ ] Platzhalter in der Datenschutzerklaerung ersetzen
|
||
- [ ] Hosting-Anbieter und Mail-Anbieter in Datenschutztext eintragen
|
||
- [ ] Rechtliche Texte vor Livegang pruefen lassen
|
||
|
||
## 7. Build & Smoke Test
|
||
|
||
- [ ] Dependencies installieren: `npm ci`
|
||
- [ ] Production Build erstellen: `npm run build:prod`
|
||
- [ ] Produktionsstart mit Schemaabgleich und Notdienst-Worker verwenden: `scripts/start-production.sh`; bei anderem Hosting diese Schritte separat sicherstellen
|
||
- [ ] Startseite, Login, Dashboard und Kontaktformular testen
|
||
|
||
## 8. Coolify
|
||
|
||
- [ ] Code nach Gitea pushen
|
||
- [ ] In Coolify eine Application aus dem Gitea-Repository anlegen
|
||
- [ ] Build Pack `Docker Compose` waehlen
|
||
- [ ] Compose-Datei `docker-compose.coolify.yml` verwenden
|
||
- [ ] Environment Variables in Coolify eintragen, nicht ins Repo committen
|
||
- [ ] Domain auf den `app`-Service und Container-Port `3000` routen
|
||
- [ ] Upload-Volume `kita_planer_uploads` bleibt zwischen Deployments erhalten
|
||
|
||
## Notdienstalarm – ergänzende Betriebsprüfung
|
||
|
||
- [ ] `NOTDIENST_JOB_SECRET` zufällig erzeugt, mindestens 32 Zeichen, nur als Runtime-Secret gespeichert.
|
||
- [ ] Schema-Upgrade gesichert und angewandt; `db push` oder einmaliges SQL-Upgrade, nicht beides hintereinander.
|
||
- [ ] Worker bzw. Scheduler startet nach Neustart automatisch und ruft die geschützte Jobroute jede Minute auf.
|
||
- [ ] Fristablauf mit geschlossenem Browser geprüft: einmaliger Hinweis an Admins und Koordination.
|
||
- [ ] Versanddienst und öffentliche App-Adresse geprüft; Rückmeldelinks erreichen die tatsächliche Domain.
|
||
- [ ] Versandübersicht auf Fehler geprüft; Annahme durch den Maildienst und Postfachzustellung getrennt geprüft.
|