Der Stack bleibt bewusst erhalten: Er richtet sich an Betreiber OHNE eigenen Reverse-Proxy, weil Caddy das Zertifikat selbst holt und erneuert. Er war allerdings seit Februar stehengeblieben und reichte zehn Variablen nicht an den Container durch - teils sicherheitsrelevant. Behoben: - HTTPS_ENABLED ergaenzt (Default true, Caddy terminiert TLS). Fehlte bisher komplett, dadurch waere der Refresh-Cookie OHNE Secure-Attribut gesetzt worden und trust proxy falsch gewesen. - JWT_EXPIRES_IN Default von 7d auf 15m korrigiert - der Wert galt dem ACCESS-Token und stammte aus der Zeit vor dem Access-/Refresh-Pattern. Ein Access-Token mit einer Woche Lebensdauer im Browser-Speicher macht das XSS-Fenster unnoetig gross. - JWT_REFRESH_EXPIRES_IN, CORS_ORIGINS, LISTEN_ADDR, SSRF_BLOCK_PRIVATE_IPS ergaenzt. JWT_REFRESH_EXPIRES_IN stand bereits in docker/.env.example, wurde aber nie durchgereicht - dieselbe Fehlerklasse wie beim Audit-Siegel. - Caddyfile: gzip fuer /api/* deaktiviert (BREACH, CVE-2013-3587). Die Konfiguration komprimierte bisher alles, obwohl die README das fuer die API ausdruecklich ausschliesst. Statische Assets bleiben komprimiert. Mit `caddy validate` geprueft. - docker/.env.example um die neuen Variablen erweitert, dazu ein Hinweis auf Sonderzeichen im DB-Passwort (dieser Stack setzt die DATABASE_URL direkt zusammen, anders als der Entrypoint im Projektstamm). - README benennt jetzt, wann welcher Stack der richtige ist. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
OpenCRM Docker Deployment
Schnellstart
-
Umgebungsvariablen konfigurieren:
cd docker cp .env.example .env nano .env # Sichere Werte setzen -
Container starten (erster Start mit RUN_SEED=true):
docker compose up -dBeim ersten Start wird automatisch:
- Auf die Datenbank gewartet
- Migrationen ausgeführt
- Seed-Daten geladen (wenn
RUN_SEED=true)
-
Nach erfolgreicher Installation:
# RUN_SEED in .env auf false setzen sed -i 's/RUN_SEED=true/RUN_SEED=false/' .env -
Anwendung aufrufen:
- Mit Domain:
https://your-domain.com - Lokal:
http://localhost
- Mit Domain:
-
Login:
- E-Mail:
admin@admin.com - Passwort:
admin
- E-Mail:
Architektur
┌─────────────┐
│ Caddy │
│ (SSL/TLS) │
│ :80/:443 │
└──────┬──────┘
│
┌──────▼──────┐
│ OpenCRM │
│ (Node.js) │
│ :3001 │
└──────┬──────┘
│
┌──────▼──────┐
│ MariaDB │
│ :3306 │
└─────────────┘
Befehle
Container verwalten
# Starten
docker compose up -d
# Stoppen
docker compose down
# Logs anzeigen
docker compose logs -f app
# Neustart
docker compose restart app
Datenbank
# Migration ausführen
docker compose exec app npx prisma migrate deploy
# Seed-Daten laden
docker compose exec app npx tsx prisma/seed.ts
# Prisma Studio (Datenbank-UI)
docker compose exec app npx prisma studio
Backup & Restore
# Backup-Verzeichnis ist unter /app/backups gemountet
# Backups werden über die Anwendung erstellt/wiederhergestellt
Update
# Image neu bauen und Container aktualisieren
docker compose build --no-cache
docker compose up -d
# Migrationen werden automatisch beim Start ausgeführt
Volumes
| Volume | Beschreibung |
|---|---|
mariadb_data |
Datenbank-Dateien |
uploads_data |
Hochgeladene Dokumente |
backups_data |
Backup-Dateien |
caddy_data |
SSL-Zertifikate |
caddy_config |
Caddy-Konfiguration |
SSL-Zertifikat
Caddy holt automatisch ein Let's Encrypt Zertifikat wenn:
- Die Domain in
.envkorrekt gesetzt ist - Port 80 und 443 von außen erreichbar sind
- DNS auf den Server zeigt
Für lokale Entwicklung mit DOMAIN=localhost wird ein selbstsigniertes Zertifikat verwendet.
Troubleshooting
Container startet nicht
docker compose logs app
Datenbank-Verbindung fehlgeschlagen
# Warten bis MariaDB bereit ist
docker compose logs db
SSL-Zertifikat Probleme
docker compose logs caddy
# Caddy-Daten zurücksetzen
docker compose down
docker volume rm opencrm_caddy_data opencrm_caddy_config
docker compose up -d