Coolify im Produktivbetrieb: Was die Dokumentation nicht erklärt

Wer eine Self-Hosting-Plattform sucht, sollte Coolify ernsthaft in Betracht ziehen. Das Tool bietet eine saubere Oberfläche für Docker-Compose-Deployments, automatisches SSL-Management via Traefik, Umgebungsvariablen, Logs und Service-Monitoring – ohne Kubernetes-Konfiguration oder selbst gewartete Deployment-Skripte. Für Einzelentwickler und kleine Teams, die Open-Source-Tools auf einem Hetzner- oder DigitalOcean-VPS betreiben, ist Coolify einer der besten Ansätze.

Wir betreiben es über mehrere Setups hinweg: Listmonk, Twenty CRM, Plausible, n8n, Vaultwarden, NocoDB. Der komplette Self-Hosted-Stack. Coolify managt das alles zuverlässig.

Trotzdem hat der Produktivbetrieb eine Lernkurve. Nicht weil Coolify schlecht designt wäre, sondern weil einige Verhaltensweisen nicht intuitiv sind und in der Dokumentation kaum auftauchen. Hier sind die Punkte, die im Produktivbetrieb am meisten Zeit kosten, wenn man sie nicht kennt.

1. Manuelle docker-compose.yml-Änderungen werden beim Redeploy überschrieben

Das ist der wichtigste Punkt. Wenn Coolify einen Service deployed, generiert es eine docker-compose.yml aus einem internen Template. Wer sich per SSH einloggt und diese Datei manuell anpasst – z.B. um ein Traefik-Label hinzuzufügen, ein Volume einzuhängen oder einen Command-Parameter zu setzen – sollte danach keinen Redeploy über die Coolify-UI auslösen.

Ein Redeploy generiert die Compose-Datei neu, und alle manuellen Änderungen werden kommentarlos überschrieben.

Die Lösung: Nach manuellen Änderungen direkt per SSH anwenden:

cd /data/coolify/services/<SERVICE_UUID>/
docker compose up -d <container_name>

Coolify zeigt danach den Banner „Die neueste Konfiguration wurde nicht angewendet.” Das ist rein kosmetisch – ignorieren. Die Änderungen sind aktiv.

Das betrifft alle Services, die ein Setup benötigen, das Coolify’s UI nicht abdeckt – etwa ein --static-dir-Argument bei Listmonk oder benutzerdefinierte Traefik-Routing-Regeln für Multi-Container-Apps.

2. API-Restart generiert .env neu

Coolify hat eine API, und Restarts darüber zu triggern ist praktisch. Der Haken: GET /api/v1/services/{uuid}/restart startet die Container nicht einfach neu – es generiert die .env-Datei zuerst neu, aus Coolifys internem Template. Manuelle Änderungen in .env werden dabei überschrieben.

Das passiert klassischerweise so: Man behebt eine Umgebungsvariable per SSH, triggert danach einen Restart über die API oder per Automation – und die Änderung ist weg.

Das richtige Muster für jeden .env-Fix: SSH rein, Datei bearbeiten, dann den Container manuell neu starten:

cd /data/coolify/services/<SERVICE_UUID>/
docker compose restart <container_name>

Wer möchte, dass eine Änderung auch Coolify-Redeployments überlebt, setzt den Wert besser in Coolifys Umgebungsvariablen-UI – nicht direkt in .env.

3. SERVICE_URL_*-Variablen zeigen auf HTTP

Beim Deployment eines neuen Services generiert Coolify automatisch SERVICE_URL_*-Variablen, die auf http://<uuid>.<VPS-IP>.sslip.io zeigen. Wichtig: HTTP, nicht HTTPS.

Für interne Container-Kommunikation ist das kein Problem. Viele Apps verwenden diese URLs aber als ihre eigene öffentliche Basis-URL – Twenty CRM nutzt sie als SERVER_URL, Rybbit für API-Aufrufe aus dem Browser. Wenn der Service über HTTPS ausgeliefert wird, aber intern HTTP-URLs verwendet, blockiert der Browser das als Mixed Content. Das Ergebnis ist oft eine kryptische „Unable to Reach Back-end”-Fehlermeldung oder eine komplett leere Seite.

Der Fix:

sed -i 's|SERVICE_URL_APPNAME=http://.*|SERVICE_URL_APPNAME=https://yourdomain.com|' /data/coolify/services/<UUID>/.env
docker compose up -d <container_name>

Das Unangenehme daran: Nach jedem Redeploy dieses Services muss der Fix neu eingespielt werden, da .env jedes Mal neu generiert wird.

4. Coolify-Backups für Compose-Stack-Datenbanken schlagen still fehl

Coolify hat eine eingebaute Backup-Funktion für Datenbanken. Sie funktioniert zuverlässig für Datenbanken, die als eigenständige Ressourcen im Databases-Bereich deployed werden. Für Datenbanken innerhalb von Docker-Compose-Stacks – also alle One-Click-Services wie Listmonk, Twenty, Plausible, n8n – fehlt der Backup-Tab oft komplett, oder er meldet „Success”, während der S3-Upload still fehlschlägt.

Wir haben das konkret gegen einen Cloudflare-R2-Bucket verifiziert: Coolify meldete auf jedem Run einen erfolgreichen Backup. Der Bucket blieb leer.

Für Compose-Stack-Datenbanken empfehlen wir PGBackWeb. Es ist als Coolify-One-Click-Service verfügbar, verbindet sich direkt mit Postgres-Containern auf dem VPS über Docker-Netzwerke, und liefert die Dateien tatsächlich zu S3. Die Einrichtung dauert etwa 20 Minuten, die Web-Oberfläche ist übersichtlich.

Für Services mit Datei- oder SQLite-Speicher (Vaultwarden, Uptime Kuma) empfiehlt sich der offen/docker-volume-backup-Sidecar, der per SSH in das jeweilige Compose-Stack eingehängt wird.

5. Backup-Zeitpläne nach Coolify-Updates prüfen

Ein kleinerer Punkt: Nach einem Coolify-Update sollte man prüfen, ob die geplanten Backup-Jobs noch aktiv sind. Es gibt bekannte Fälle, in denen Zeitpläne nach Updates still auf „deaktiviert” zurückgesetzt wurden. Leicht zu übersehen – bis die Backups eine mehrwöchige Lücke haben.

Eine kurze monatliche Prüfung der aktiven Schedules empfiehlt sich.

Der Gesamteindruck

Nichts davon ist ein K.O.-Kriterium. Wer die Muster kennt, arbeitet schnell damit. Coolifys eigentlicher Mehrwert – One-Click-Deploys, automatisches SSL, eine saubere Service-Übersicht, lesbare Logs, Umgebungsvariablen-Management – ist real und erheblich. Für einen Hetzner-VPS mit 8–12 Self-Hosted-Services ist das deutlich besser als reines Docker-Compose-Management per Hand.

Die oben genannten Punkte sind Eigenheiten, die im Produktivbetrieb auftauchen, selten aber beim ersten Testen. Genau das macht sie teuer in Zeit: Man stolpert erst dann drüber, wenn man mitten in einem live laufenden Setup steckt.

Wer diese Patterns kennt, spart sich viele Debug-Stunden. Wer sie gar nicht erst selbst durcharbeiten möchte, ist bei uns richtig.