Files
certvia/docs/DEPLOY-PROD-CONTABO.md
T
msolarczekandClaude Opus 4.8 cc8d48698f Feat: Prod-Bootstrap (Erst-Superadmin) + Contabo-Runbook
- scripts/bootstrap-admin.ts: legt ersten Plattform-Admin + Mandant via
  provisionTenant(isPlatformAdmin) an; idempotent, per Env gesteuert. Ersetzt in
  Prod den Demo-Seed. tsx-@/-Auflösung lokal verifiziert.
- docker-compose.coolify.yml: migrate-Job führt bei BOOTSTRAP_ADMIN=true das Skript
  nach der Migration aus; BOOTSTRAP_*-Vars durchgereicht.
- .env.prod.example: Prod-Env-Referenz (HTTPS, kein Demo-Seed, Bootstrap-Vars).
- docs/DEPLOY-PROD-CONTABO.md: Runbook (VPS-Härtung/Swap, Coolify+Gitea, DNS/TLS
  app.certvia.de, Deploy, Bootstrap, Backups, Go-Live-Checkliste).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 13:44:34 +02:00

5.0 KiB
Raw Blame History

Deployment: Produktivserver (Contabo-VPS via Coolify)

Zielumgebung: öffentlicher Contabo-VPS, eigene Coolify-Instanz, Git (Gitea) auf demselben VPS, Domain app.certvia.de mit echtem Let's-Encrypt-TLS. Ergänzt docs/DEPLOY-COOLIFY.md (Testserver). Deploy-Datei: docker-compose.coolify.yml.

Unterschiede zum Testserver

Aspekt Test (intern) Produktiv (Contabo)
Erreichbarkeit intern, HTTP, sslip.io öffentlich, HTTPS, app.certvia.de
Git-Quelle internes Gitea Gitea auf dem VPS (Release-Push)
Erst-Admin Demo-Seed (RUN_DEMO_SEED=true) Bootstrap-Admin (BOOTSTRAP_ADMIN=true), kein Demo-Seed
Secrets Testwerte frische, starke Secrets
Backups optional Pflicht (pg_dump + Restore-Test)
Branch dev main

Phase 1 — VPS-Grundlage

  1. Contabo-VPS bereitstellen — ≥ 8 GB RAM empfohlen (Next-Build ~1 GB + Stack). Bei weniger RAM zwingend Swap:
    fallocate -l 4G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile
    echo '/swapfile none swap sw 0 0' >> /etc/fstab
    free -h
    
  2. Grundhärtung: System aktualisieren, SSH-Key-Login (Passwort-Login aus), unattended-upgrades.
  3. Firewall (ufw): nur benötigte Ports offen — 80, 443, SSH, sowie der Gitea-SSH-Port (s. Phase 2).
  4. Coolify installieren (offizielles Installskript) — eigene, unabhängige Instanz.

Phase 2 — Gitea auf dem VPS

  1. Gitea als Coolify-Ressource (One-Click/Compose) aufsetzen, eigene Subdomain (z. B. git.certvia.de), TLS via Coolify.
  2. Repo ISMS-Tool in diesem Gitea anlegen.
  3. Lokal ein zweites Remote hinzufügen und beim Release main dorthin pushen:
    git remote add prod https://git.certvia.de/<org>/ISMS-Tool.git
    git push prod main
    
    (Das ist der bewusste „Release-Push" — Prod deployt nur, was hier landet.)

Phase 3 — DNS & Domain

  1. Bei eurem DNS für certvia.de einen A-Record app.certvia.de → Contabo-IP anlegen (ebenso git.certvia.de).
  2. Coolify vergibt/prüft danach automatisch das Let's-Encrypt-Zertifikat (VPS ist öffentlich erreichbar).

Phase 4 — App-Ressource (Prod) in Coolify

  1. New Resource → Git-Quelle = das VPS-Gitea (Deploy-Key), Repo ISMS-Tool, Branch main.
  2. Build Pack: Docker Compose, Compose Location: docker-compose.coolify.yml.
  3. Domain beim Service app = https://app.certvia.de:3000 (Port 3000), Schema https.
  4. Environment-Variablen aus .env.prod.example setzen (Runtime-Variablen). Kritisch:
    • Alle Secrets frisch (AUTH_SECRET neu: openssl rand -base64 32; neue DB-/MinIO-Passwörter).
    • AUTH_URL=https://app.certvia.de (exakt die App-Domain).
    • RUN_DEMO_SEED=false (bzw. weglassen).
    • Bootstrap (erster Deploy): BOOTSTRAP_ADMIN=true + BOOTSTRAP_ADMIN_EMAIL/PASSWORD/NAME + BOOTSTRAP_TENANT_NAME/SLUG.
  5. Persistent Storage prüfen — v. a. pgdata (sonst Datenverlust bei Redeploy).

Phase 5 — Erster Deploy & Bootstrap

  1. Deploy. Ablauf: postgres (healthy) → migrate (migriert und legt via BOOTSTRAP_ADMIN=true den Erst-Admin an) → app.
  2. In den migrate-Logs prüfen: >> Bootstrap-Admin läuft…✔ Bootstrap fertig: Mandant … + Plattform-Admin … angelegt.
  3. Login unter https://app.certvia.de mit den BOOTSTRAP_ADMIN_*-Zugangsdaten → Passwort sofort ändern.
  4. Optional danach BOOTSTRAP_ADMIN auf false (das Skript ist idempotent, es schadet aber nicht, es an zu lassen).

Phase 6 — Backups & Betrieb (vor „echtem" Go-Live)

  1. Postgres-Backups: regelmäßiger pg_dump (oder Coolify-DB-Backup nach S3) + Restore-Test dokumentieren. pgdata ist das kritische Volume.
  2. MinIO-Backup, sobald Datei-/Logo-Upload aktiv ist.
  3. Monitoring/Alerting: App-Healthcheck ist im Compose vorhanden; zusätzlich Uptime-Check auf https://app.certvia.de und Log-Aggregation einrichten.
  4. Updates: Betriebssystem/Coolify/Images regelmäßig aktualisieren.

Phase 7 — Auto-Deploy (optional)

  1. Gitea-Webhook (VPS-Gitea → Coolify) mit Branch-Filter main. Da Gitea und Coolify auf demselben Host sind, ggf. GITEA__webhook__ALLOWED_HOST_LIST weit genug setzen (vgl. Testserver-Erfahrung).

Release-Fluss (Zusammenfassung)

Feature-Branch → dev            # Entwicklung, Auto-Deploy Testserver
dev → main                      # Release-Merge (nach Test-Freigabe)
git push prod main              # Release-Push ins VPS-Gitea → Prod-Deploy

Sicherheits-Checkliste Go-Live

  • Frische, starke Secrets (nicht aus Test übernommen)
  • RUN_DEMO_SEED aus, keine Demo-Daten in Prod
  • Bootstrap-Admin-Passwort nach erstem Login geändert
  • HTTPS erzwungen, gültiges Zertifikat
  • pgdata persistent + Backup + Restore-Test
  • Firewall aktiv, SSH gehärtet
  • Gitea-Repo privat, Zugriff nur für das Team