Coolify auf Hetzner installieren und sicher betreiben

Aktualisiert am 30. Juli 2026

Coolify ist eine gute Lösung, wenn Sie Anwendungen ähnlich bequem wie bei Heroku, Vercel oder Railway bereitstellen möchten, die Infrastruktur aber auf einem eigenen Server betreiben wollen. In Verbindung mit der Hetzner Cloud entsteht ein Setup, das für viele Webanwendungen, APIs und interne Systeme gut funktioniert: Git-Repository verbinden, Domain hinterlegen und neue Versionen automatisiert ausrollen.

Bei OnLouis setzen wir Coolify als Deployment-Ebene für containerisierte Anwendungen ein. Der größte Vorteil ist aus unserer Sicht nicht ein einzelnes Feature, sondern die zentrale Oberfläche für Builds, Umgebungsvariablen, Domains, Zertifikate, Logs und Datenbanken. Trotzdem bleibt es Self-Hosting. Betriebssystem, Backups, Monitoring und Anwendungssicherheit liegen weiterhin in Ihrer Verantwortung.

Diese Anleitung zeigt ein solides Grundsetup für kleine und mittlere Produktionsumgebungen. Sie konzentriert sich bewusst auf die Punkte, die nach der Installation tatsächlich wichtig werden.

Hinweis: Coolify wird aktiv weiterentwickelt. Bezeichnungen im Dashboard können sich ändern. Befehle, Voraussetzungen und Links in diesem Artikel wurden zuletzt am 30. Juli 2026 geprüft.

Was Coolify übernimmt – und was nicht

Coolify verwaltet Anwendungen und Dienste als Docker-Container. Je nach Projekt kann die Plattform den Quellcode aus einem Git-Repository abrufen, ein Container-Image bauen, Umgebungsvariablen setzen und die Anwendung über einen Reverse Proxy erreichbar machen.

Typische Aufgaben, die Coolify abnimmt:

Deployments aus GitHub, GitLab, Bitbucket, Gitea oder öffentlichen Repositories
Builds über Nixpacks, Dockerfile oder Docker Compose
Verwaltung von Domains, Routing und TLS-Zertifikaten
Bereitstellung von Datenbanken und weiteren Docker-basierten Diensten
Logs, Health Checks, Benachrichtigungen und Rollbacks auf lokal vorhandene Images
automatische Deployments nach einem Push oder Pull Request

Coolify ersetzt jedoch keinen vollständig gemanagten Hosting-Anbieter. Insbesondere diese Aufgaben bleiben beim Betreiber:

Absicherung und Aktualisierung des Servers
sinnvolle Rechte- und Zugriffskonzepte
externe und getestete Backups
Überwachung von außen
sichere Anwendungskonfiguration
Kapazitätsplanung und Reaktion auf Störungen

Das ist kein Nachteil, sondern der Preis für die zusätzliche Kontrolle. Wer keinerlei Verantwortung für Infrastruktur übernehmen möchte, ist mit einem vollständig gemanagten Angebot meist besser bedient.

Planung vor der Installation

Ein sauberer Start erspart später viel Fehlersuche. Coolify sollte nach Möglichkeit auf einem frischen Server installiert werden. Bereits vorhandene Docker-Container, Reverse Proxies oder manuell eingerichtete Webserver können Ports und Netzwerke belegen und dadurch schwer nachvollziehbare Konflikte verursachen.

Servergröße realistisch wählen

Die offizielle Installationsanleitung von Coolify nennt als Minimum:

2 CPU-Kerne
2 GB RAM
30 GB freien Speicher
ein 64-Bit-System mit AMD64- oder ARM64-Architektur

Diese Werte reichen für die Plattform und einfache Tests. Für einen produktiven Betrieb würden wir etwas mehr Reserve einplanen, weil Builds kurzfristig deutlich mehr Arbeitsspeicher und CPU benötigen können als die laufende Anwendung.

Als grobe Orientierung:

Testsystem oder kleine statische Projekte: 2 GB RAM können ausreichen.
Kleine Webanwendung mit Datenbank: 4 GB RAM sind ein sinnvoller Einstieg.
Laravel- oder Node-Anwendung mit Datenbank, Queue und Builds auf demselben Server: 8 GB RAM bieten deutlich mehr Reserve.
Mehrere produktive Anwendungen: Ressourcen großzügiger planen oder Builds auf einen separaten Build-Server auslagern.

Swap kann kurze Lastspitzen abfangen, ersetzt aber keinen ausreichenden Arbeitsspeicher. Wenn der Server regelmäßig auslagert, sollte die Instanz vergrößert oder der Build-Prozess getrennt werden.

Betriebssystem und Serverstandort

Für ein unkompliziertes Setup bietet sich Ubuntu 24.04 LTS an. Das aktuelle Coolify-App-Image von Hetzner basiert ebenfalls darauf. Das automatische Installationsskript unterstützt die Ubuntu-LTS-Versionen 20.04, 22.04 und 24.04. Andere Linux-Distributionen sind möglich, benötigen je nach System aber zusätzliche Vorbereitung.

Wählen Sie den Serverstandort passend zu Ihren Nutzern und Datenschutzanforderungen. Ein deutscher Standort kann ein Datenschutzkonzept erleichtern, macht eine Anwendung jedoch nicht automatisch DSGVO-konform. Auftragsverarbeitung, Zugriffsrechte, Protokollierung, externe Dienste, Backups und tatsächliche Datenflüsse müssen weiterhin geprüft werden.

Domains vorab festlegen

Für das Coolify-Dashboard sollte eine eigene Subdomain vorgesehen werden, zum Beispiel:

coolify.example.de

Anwendungen erhalten anschließend eigene Domains wie:

app.example.de

api.example.de

Eine Wildcard-Domain ist praktisch, wenn viele temporäre oder automatisch erzeugte Umgebungen geplant sind. Für ein einzelnes Projekt ist sie nicht erforderlich.

Methode 1: Coolify als Hetzner Cloud App installieren

Der schnellste Weg ist das vorbereitete Coolify-Image in der Hetzner Cloud. Hetzner installiert Docker und Coolify vor, die Aktivierung wird beim ersten Serverzugriff abgeschlossen. Die Vorgehensweise ist in der Hetzner-Dokumentation zur Coolify-App beschrieben.

Schritt 1: Server erstellen

Erstellen Sie in der Hetzner Console einen neuen Cloud-Server und wählen Sie unter den Apps Coolify aus. Legen Sie anschließend fest:

gewünschten Standort
passende Servergröße
SSH-Key
Servername
Firewall

Verwenden Sie nach Möglichkeit von Anfang an einen SSH-Key. Ein Passwortzugang sollte nur als kurzfristige Übergangslösung dienen.

Schritt 2: Firewall für die Ersteinrichtung konfigurieren

Für die erste Einrichtung werden bei einer selbst gehosteten Coolify-Instanz mehrere Ports benötigt:

22/TCP: SSH oder ein eigener SSH-Port
80/TCP: HTTP und Zertifikatsvalidierung
443/TCP: HTTPS
8000/TCP: direkter Zugriff auf das Coolify-Dashboard
6001/TCP: Echtzeitkommunikation
6002/TCP: Terminalzugriff bei aktuellen Coolify-Versionen

Port 80 und 443 müssen für öffentliche Webanwendungen erreichbar sein. SSH sowie die Ports 8000, 6001 und 6002 sollten während der Einrichtung möglichst auf Ihre eigene IP-Adresse oder ein administratives Netzwerk beschränkt werden.

Schritt 3: Installation aktivieren

Melden Sie sich per SSH an:

ssh root@SERVER_IP

Beim vorbereiteten Hetzner-Image wird die Installation abgeschlossen und die Adresse des Coolify-Dashboards ausgegeben. Öffnen Sie die angezeigte URL, in der Regel zunächst nach diesem Muster:

http://SERVER_IP:8000

Erstellen Sie unmittelbar das erste Administratorkonto. Solange die Registrierung offen ist, könnte sonst eine andere Person den ersten Zugang anlegen und vollständige Kontrolle über die Instanz erhalten.

Schritt 4: Eigene Dashboard-Domain setzen

Legen Sie beim DNS-Provider einen A-Record für Ihre Coolify-Subdomain an:

coolify.example.de → SERVER_IP

Tragen Sie die Domain anschließend in den Coolify-Einstellungen mit https:// ein. Sobald DNS korrekt aufgelöst wird und die Ports 80 sowie 443 erreichbar sind, richtet der integrierte Proxy das Zertifikat automatisch ein.

Nach erfolgreicher Umstellung auf die eigene Domain können die direkten Dashboard-Ports 8000, 6001 und 6002 laut offizieller Firewall-Dokumentation geschlossen werden. Prüfen Sie vorher, ob Dashboard, Echtzeitfunktionen und Terminal über die Domain funktionieren.

Methode 2: Manuelle Installation auf einem frischen Server

Die manuelle Installation ist sinnvoll, wenn Sie kein vorbereitetes App-Image verwenden oder den Ablauf nachvollziehen möchten. Für Ubuntu LTS empfiehlt Coolify das offizielle Installationsskript.

Melden Sie sich zunächst als root an und aktualisieren Sie das System:

apt update
apt upgrade -y
apt install -y curl

Die direkte Installation erfolgt mit:

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash

In kontrollierten Umgebungen kann das Skript vor der Ausführung heruntergeladen und geprüft werden:

curl -fsSL https://cdn.coollabs.io/coolify/install.sh -o /root/install-coolify.sh
less /root/install-coolify.sh
bash /root/install-coolify.sh

Das Installationsskript richtet die benötigten Werkzeuge, Docker Engine, Verzeichnisse und SSH-Schlüssel ein und startet Coolify. Node.js muss auf dem Host nicht separat installiert werden. Auch eine manuelle Docker-Installation ist bei einem frischen, unterstützten Ubuntu-System normalerweise nicht nötig.

Wichtig: Docker aus dem Snap-Paket wird von Coolify nicht unterstützt. Befindet sich bereits eine Snap-Installation oder ein komplexes Docker-Setup auf dem Server, ist ein frischer Server häufig schneller und sicherer als eine nachträgliche Bereinigung.

Nach der Installation zeigt das Skript die Dashboard-Adresse an. Rufen Sie diese auf und erstellen Sie sofort das Administratorkonto.

Firewall und SSH richtig absichern

Die Hetzner Cloud Firewall ist für dieses Setup meist die sauberste Lösung. Docker arbeitet mit eigenen NAT- und iptables-Regeln. Dadurch kann eine lokale UFW-Konfiguration veröffentlichte Container-Ports unter Umständen nicht so blockieren, wie man es erwartet. Coolify empfiehlt deshalb bei Cloud-Anbietern deren vorgeschaltete Firewall und warnt ausdrücklich davor, sich allein auf UFW zu verlassen.

Für einen einzelnen produktiven Server ist dieses Grundprinzip sinnvoll:

SSH nur von bekannten IP-Adressen oder über ein VPN erlauben
Ports 80 und 443 öffentlich freigeben
Datenbankports nicht öffentlich öffnen
direkte Coolify-Ports nach Einrichtung der Instanz-Domain schließen
neue Ports nur gezielt und dokumentiert freigeben

Für SSH sollte ausschließlich Schlüssel-Authentifizierung verwendet werden. Eine mögliche Basiskonfiguration in /etc/ssh/sshd_config ist:

PermitRootLogin prohibit-password
PasswordAuthentication no
PubkeyAuthentication yes

Coolify arbeitet bei der Standardinstallation mit einem root-Zugang per SSH-Schlüssel. Ein vollständiges Deaktivieren des root-Logins kann daher die Serververwaltung durch Coolify unterbrechen. Nicht-root-Benutzer werden unterstützt, sind laut Dokumentation aber weiterhin weniger unkompliziert als das Standardszenario.

Ändern Sie SSH-Einstellungen nie, ohne eine bestehende Sitzung geöffnet zu lassen. Starten Sie nach der Änderung eine zweite Verbindung und prüfen Sie den Zugang, bevor Sie die erste Sitzung schließen.

Die erste Coolify-Konfiguration

Nach der Installation sollten nicht sofort alle Anwendungen migriert werden. Richten Sie zuerst die Plattform selbst sauber ein.

Instanz-Domain und Benachrichtigungen

Setzen Sie die eigene HTTPS-Domain für das Dashboard und prüfen Sie das Zertifikat. Konfigurieren Sie anschließend mindestens einen Benachrichtigungskanal für fehlgeschlagene Deployments, gestoppte Container und Backupfehler. Coolify unterstützt dafür unter anderem E-Mail, Slack, Discord, Telegram und Webhooks.

Projekte und Umgebungen trennen

Ein Projekt kann mehrere Umgebungen enthalten. Für produktive Anwendungen empfiehlt sich mindestens die Trennung in:

Production für die öffentlich genutzte Version
Staging für Tests vor dem Livegang

Diese Trennung verhindert, dass Testvariablen, Domains oder Datenbanken versehentlich in der Produktion verwendet werden.

Git-Anbieter verbinden

Für GitHub stehen mehrere Wege zur Verfügung:

öffentliches Repository direkt über die URL
private Repositories über eine GitHub App
private Repositories über einen Deploy Key
vorgebaute Images aus einer Container Registry

Die Coolify-Dokumentation zur GitHub-Integration beschreibt die Varianten im Detail. Gewähren Sie nur Zugriff auf die tatsächlich benötigten Repositories. Organisationsweite Berechtigungen sind für ein einzelnes Projekt in der Regel nicht erforderlich.

Secrets und produktive Zugangsdaten gehören in die Umgebungsvariablen von Coolify, nicht in das Repository. Das gilt auch dann, wenn das Repository privat ist.

Die erste Anwendung deployen

Coolify unterstützt unterschiedliche Build-Methoden. Welche sinnvoll ist, hängt vom Projekt ab.

Nixpacks eignet sich für einen schnellen Einstieg und erkennt viele Frameworks automatisch. Das reduziert Konfiguration, kann bei komplexeren Projekten aber weniger transparent sein.

Ein Dockerfile ist für produktive Anwendungen häufig die beste Wahl. PHP-Erweiterungen, Node-Version, Build-Schritte und Laufzeitumgebung sind damit reproduzierbar und versioniert.

Docker Compose ist praktisch, wenn mehrere eng gekoppelte Container gemeinsam beschrieben werden sollen. Persistente Daten, Netzwerke und Updates benötigen hier etwas mehr Aufmerksamkeit.

Port und Health Check

Die Anwendung muss innerhalb des Containers auf der erwarteten Adresse und dem erwarteten Port lauschen. Häufige Ursachen für einen 502- oder 503-Fehler sind:

die Anwendung bindet nur an 127.0.0.1 statt an 0.0.0.0
in Coolify ist der falsche interne Port eingetragen
der Container startet, wird aber unmittelbar wieder beendet
der konfigurierte Health Check liefert keinen erfolgreichen Statuscode

Ein einfacher Endpoint wie /health sollte ohne Login und ohne aufwendige externe Abhängigkeiten mit HTTP 200 antworten. Ein funktionierender Health Check ist außerdem Voraussetzung für zuverlässige Rolling Updates.

Persistente Daten

Container selbst sind austauschbar. Dateien, die einen neuen Build oder Containerwechsel überstehen müssen, gehören deshalb in ein persistentes Volume, einen Bind Mount oder einen externen Objektspeicher.

Typische Beispiele:

hochgeladene Dateien
generierte Dokumente
Datenbankdateien
Suchindizes
lokale Anwendungsdaten

Quellcode, Abhängigkeiten und Build-Artefakte sollten dagegen aus dem Repository oder Image reproduzierbar sein.

Praxisbeispiel: Laravel

Für eine Laravel-Anwendung sollten mindestens diese Variablen bewusst gesetzt werden:

APP_ENV=production
APP_DEBUG=false
APP_URL=https://app.example.de

Der Datenbank-Host ist bei getrennten Containern normalerweise der interne Hostname der Datenbankressource und nicht localhost. Innerhalb des App-Containers bezeichnet localhost den App-Container selbst.

Queue Worker und Scheduler sollten als eigene, überwachte Prozesse laufen. Nutzeruploads im lokalen storage-Verzeichnis benötigen persistenten Speicher; alternativ können Dateien direkt in einen S3-kompatiblen Objektspeicher geschrieben werden.

Datenbankmigrationen gehören nicht in einen Image-Build. Sie sollten als kontrollierter Schritt im Deployment ausgeführt werden, idealerweise nach einem aktuellen Datenbankbackup. Bei nicht rückwärtskompatiblen Schemaänderungen muss zusätzlich bedacht werden, dass während eines Rolling Updates kurzzeitig alte und neue Container parallel laufen können.

Domains und automatische SSL-Zertifikate

Für eine Anwendung wird zunächst ein A-Record auf die öffentliche IPv4-Adresse des Servers gesetzt. Ein AAAA-Record sollte nur vorhanden sein, wenn IPv6 auf dem Server und in der Firewall tatsächlich korrekt funktioniert. Ein veralteter oder falscher AAAA-Record ist eine häufige Ursache für schwer nachvollziehbare Zertifikatsprobleme.

Tragen Sie die Domain in Coolify vollständig mit Protokoll ein:

https://app.example.de

Coolify konfiguriert den Reverse Proxy und fordert automatisch ein Let's-Encrypt-Zertifikat an. Ein zusätzlich installierter Certbot ist für normale Coolify-Domains nicht nötig und kann mit dem integrierten Proxy in Konflikt geraten.

Falls Cloudflare oder ein anderer Proxy vor dem Server eingesetzt wird, kann die Zertifikatsvalidierung gestört werden. Für die erste Einrichtung ist es oft am einfachsten, den DNS-Eintrag zunächst ohne Proxy zu betreiben. Alternativ kann eine DNS-Challenge eingerichtet werden.

Zur ersten Prüfung eignen sich diese Befehle:

dig +short A app.example.de
dig +short AAAA app.example.de
curl -I http://app.example.de
curl -I https://app.example.de

Wenn die Zertifikatsanforderung mehrfach fehlschlägt, sollten zuerst DNS, Ports und Proxy-Logs geprüft werden. Wiederholte Versuche ohne Ursachenbehebung können zu einer vorübergehenden Rate-Limitierung durch Let's Encrypt führen. Weitere Details stehen in der Coolify-Anleitung zu fehlgeschlagenen Zertifikaten.

Backups: vier Ebenen statt eines Snapshots

Ein Server-Snapshot ist hilfreich, aber kein vollständiges Backupkonzept. Für produktive Anwendungen sollten vier Ebenen betrachtet werden.

1. Datenbankbackups

Coolify kann geplante Dumps für unterstützte Datenbanken erstellen. Diese Backups sollten auf ein externes S3-kompatibles Ziel übertragen werden. Ein Backup, das ausschließlich auf demselben Server liegt, hilft bei einem vollständigen Serververlust nicht weiter.

Als Ziel eignet sich beispielsweise Hetzner Object Storage oder ein anderer S3-kompatibler Anbieter. Der Bucket muss bereits existieren, bevor Coolify die Verbindung prüfen kann. Zugangsschlüssel sollten nur die benötigten Rechte für den vorgesehenen Bucket erhalten.

2. Coolify-Instanz sichern

Auch die Konfiguration der Coolify-Instanz muss gesichert werden. Dazu gehören je nach Setup die interne Datenbank, Schlüssel und relevante Konfigurationsdaten. Die Coolify-Dokumentation zu S3-Backups beschreibt die unterstützten Ziele.

3. Persistente Volumes sichern

Anwendungsdaten in Docker Volumes sind nicht automatisch durch einen Datenbankdump oder ein Git-Repository abgedeckt. Für jedes persistente Volume muss geklärt sein:

welche Daten darin liegen
wie sie konsistent gesichert werden
wie die Wiederherstellung funktioniert
wie lange Sicherungen aufbewahrt werden

4. Hetzner-Snapshots als zusätzliche Ebene

Snapshots eignen sich gut vor größeren Updates oder Umbauten und ermöglichen eine schnelle Wiederherstellung des gesamten Servers. Sie ersetzen jedoch keine externen, versionierten Datenbank- und Dateibackups.

Ein mögliches Aufbewahrungsschema ist:

tägliche Backups für 14 Tage
wöchentliche Backups für 8 Wochen
monatliche Backups für 12 Monate

Die passende Aufbewahrung hängt von Änderungsrate, Datenmenge und rechtlichen Anforderungen ab. Entscheidend ist ein regelmäßiger Restore-Test. Erst eine erfolgreich wiederhergestellte Sicherung ist ein belastbares Backup.

Monitoring und laufende Wartung

Coolify überwacht unter anderem Containerzustände, Speicherplatz und Backupstatus. Über Sentinel können je nach Ressourcentyp CPU- und RAM-Metriken angezeigt werden. Das ersetzt jedoch keine externe Verfügbarkeitsprüfung.

Ein gutes Basissetup umfasst:

externes Uptime-Monitoring für wichtige Domains und APIs
Benachrichtigung bei fehlgeschlagenen Deployments und Backups
Überwachung von CPU, RAM und Datenträger
Health Checks für Anwendungen
zentrale oder zumindest ausreichend lange Log-Aufbewahrung

Auf dem Server liefern diese Befehle einen schnellen Überblick:

free -h
df -h
docker system df
docker ps

Coolify verfügt über eine automatische Docker-Bereinigung. Diese sollte unter Server → Configuration → Advanced geprüft und passend konfiguriert werden. Alte Images, Build-Cache und Logs sind häufige Ursachen für vollen Speicher. Ein unüberlegtes docker system prune kann dagegen benötigte Daten entfernen und sollte nicht als Standardlösung verwendet werden.

Updates kontrolliert durchführen

Bei selbst gehosteten Instanzen ist die automatische Aktualisierung standardmäßig aktiviert. Die Coolify-Dokumentation zu Self-Updates empfiehlt für Produktionsinstanzen, automatische Updates zu deaktivieren und neue Versionen bewusst einzuspielen.

Ein sinnvoller Ablauf ist:

Release Notes und bekannte Probleme prüfen.
Aktuelle Datenbank- und Instanzbackups kontrollieren.
Update zunächst in einer weniger kritischen Umgebung testen.
Produktionsinstanz in einem geplanten Wartungsfenster aktualisieren.
Dashboard, Deployments, Proxy und Backups anschließend prüfen.

Auch das Betriebssystem benötigt regelmäßige Sicherheitsupdates. Coolify nimmt dem Betreiber diese Verantwortung nicht vollständig ab.

Performance und Skalierung

Viele Setups benötigen anfangs weder Cluster noch Load Balancer. Zunächst sollte geprüft werden, welcher Teil tatsächlich an seine Grenze kommt.

Vertikal skalieren

Mehr CPU, RAM oder Speicher auf einem bestehenden Server ist häufig der einfachste erste Schritt. Besonders bei kleinen Teams ist diese Lösung übersichtlicher als eine früh aufgebaute Mehrserver-Architektur.

Builds auslagern

Builds können den Arbeitsspeicher und die CPU einer laufenden Anwendung stark belasten. Coolify unterstützt separate Build-Server. Diese bauen Images und übertragen sie über eine Container Registry auf die Zielserver. Das trennt kurzfristige Build-Last vom produktiven Betrieb.

Datenbank trennen

Eine eigene Datenbankinstanz kann sinnvoll sein, wenn Datenbanklast, Backupfenster oder Verfügbarkeitsanforderungen steigen. Die Kommunikation sollte möglichst über ein privates Hetzner-Netzwerk erfolgen. Datenbankports gehören nicht ungeschützt ins öffentliche Internet.

Mehrere App-Server und Load Balancer

Für horizontale Skalierung können mehrere Server mit einem Hetzner Load Balancer kombiniert werden. Dafür werden unter anderem ein privates Netzwerk, kompatible Serverarchitekturen und eine Container Registry benötigt. Die offizielle Coolify-Anleitung zum Hetzner Load Balancing beschreibt ein mögliches Setup.

Zero-Downtime ist dabei kein Automatismus. Eine Anwendung benötigt funktionierende Health Checks, Rolling Updates und eine Architektur, die parallele Instanzen verträgt. Lokale Sessions, nicht geteilte Uploads oder dateibasierte Zustände können horizontale Skalierung verhindern.

Sicherheitscheck vor dem Livegang

Vor der Veröffentlichung sollten mindestens diese Punkte erfüllt sein:

SSH-Zugang nur per Schlüssel
Hetzner Firewall aktiv und restriktiv konfiguriert
Coolify-Dashboard nur über HTTPS erreichbar
direkte Managementports nach der Einrichtung geschlossen
Datenbanken nicht öffentlich freigegeben
APP_DEBUG und vergleichbare Debug-Modi deaktiviert
Secrets ausschließlich in der dafür vorgesehenen Konfiguration gespeichert
externe Backups eingerichtet und testweise wiederhergestellt
Health Checks und externes Monitoring aktiv
Benachrichtigungen für Deployment- und Backupfehler eingerichtet
Update- und Wiederherstellungsprozess dokumentiert

Häufige Probleme und ihre Ursachen

Das Coolify-Dashboard ist nicht erreichbar

Prüfen Sie zunächst, ob der Server läuft und die Firewall Port 8000 während der Ersteinrichtung zulässt. Anschließend kontrollieren Sie die Container:

docker ps

Ist Coolify bereits über eine eigene Domain konfiguriert, müssen DNS sowie die Ports 80 und 443 geprüft werden. Ein nicht erreichbarer direkter Port 8000 ist nach vollständiger Domain-Einrichtung dagegen gewollt, wenn er in der Firewall geschlossen wurde.

Das SSL-Zertifikat wird nicht erstellt

Die häufigsten Ursachen sind:

A-Record zeigt auf die falsche IPv4-Adresse
ein vorhandener AAAA-Record zeigt auf eine nicht funktionierende IPv6-Adresse
Port 80 oder 443 ist blockiert
Cloudflare oder eine andere Proxy-Schicht stört die Challenge
der Reverse Proxy läuft nicht korrekt
Let's Encrypt hat nach vielen Fehlversuchen vorübergehend limitiert

Ändern Sie nicht mehrere Dinge gleichzeitig. Prüfen Sie DNS, Firewall und Proxy-Logs nacheinander und starten Sie erst danach einen neuen Versuch.

Der Build schlägt fehl

Lesen Sie im Build-Log von oben nach unten bis zur ersten relevanten Fehlermeldung. Spätere Meldungen sind häufig nur Folgefehler. Typische Ursachen sind:

fehlende oder falsche Umgebungsvariablen
nicht verfügbare Systempakete oder PHP-Erweiterungen
eine falsche Node-, PHP- oder Paketmanager-Version
fehlende Berechtigungen für ein privates Repository
zu wenig RAM oder Speicherplatz
ein Dockerfile, das lokale Dateien voraussetzt, die nicht im Repository liegen

Bei wiederkehrenden Problemen ist ein explizites Dockerfile meist leichter zu warten als ein zunehmend komplex konfigurierter automatischer Build.

Die Anwendung liefert 502 oder 503

Prüfen Sie zuerst, ob der Container läuft und gesund ist. Danach kontrollieren Sie:

interner Anwendungsport
Bind-Adresse 0.0.0.0
Port-Expose-Einstellung in Coolify
Health-Check-Pfad
Startbefehl und Anwendungslogs
Verbindung zur Datenbank

Ein Container kann technisch laufen, obwohl die Anwendung im Container nicht auf Anfragen reagiert.

Der Server hat keinen Speicherplatz mehr

Ermitteln Sie zunächst, wo der Speicher belegt wird:

df -h
docker system df

Häufig wachsen alte Images, Build-Caches, Containerlogs oder lokal gespeicherte Backups. Konfigurieren Sie die automatische Bereinigung und eine passende Aufbewahrung. Löschen Sie Docker Volumes nie pauschal; sie können produktive Daten enthalten.

Ein Git-Push löst kein Deployment aus

Prüfen Sie:

ob der richtige Branch konfiguriert ist
ob die GitHub App Zugriff auf das Repository besitzt
ob der Webhook vorhanden und erreichbar ist
ob Webhook-Secret und URL übereinstimmen
ob GitHub im Bereich der Webhook-Auslieferungen einen Fehler anzeigt

Für Webhooks müssen die öffentliche Coolify-Domain und Port 443 erreichbar sein.

Die Anwendung erreicht die Datenbank nicht

Innerhalb eines Containers ist localhost fast nie der richtige Host für eine getrennte Datenbank. Verwenden Sie den internen Hostnamen der Coolify-Ressource und prüfen Sie Benutzername, Passwort, Port und Datenbankname. Bei einem externen Datenbankserver müssen zusätzlich privates Netzwerk und Firewallregeln stimmen.

Welcher Support ist zuständig?

Bei Problemen hilft eine klare Trennung der Ebenen.

Hetzner ist der richtige Ansprechpartner für Cloud-Server, Netzwerk, Storage, Abrechnung und Störungen der zugrunde liegenden Infrastruktur.

Coolify-Dokumentation und Community helfen bei Installation, Proxy, Deployments, Integrationen und bekannten Fehlern der Plattform. Reproduzierbare Softwarefehler können im offiziellen Coolify-Repository auf GitHub gemeldet werden. Dabei sollten Coolify-Version, Betriebssystem, genaue Schritte und bereinigte Logs angegeben werden. Zugangsdaten und Secrets gehören nie in ein öffentliches Issue.

Der Betreiber oder Entwicklungspartner ist für Anwendungscode, Konfiguration, Datenbankmodell, Backupstrategie und die konkrete Sicherheitsarchitektur verantwortlich.

OnLouis unterstützt bei der Einrichtung und Absicherung von Coolify auf Hetzner, bei Laravel- und React-Deployments, bei Migrationen sowie beim Aufbau von Backup-, Monitoring- und Updateprozessen.

Fazit

Coolify auf Hetzner ist eine überzeugende Kombination für Unternehmen und Entwickler, die komfortable Deployments möchten, ihre Infrastruktur aber selbst kontrollieren wollen. Die Installation ist schnell erledigt. Die Qualität des Setups entscheidet sich jedoch erst bei Firewall, Backups, Health Checks, Monitoring und einem kontrollierten Updateprozess.

Für den Einstieg reicht meist ein einzelner, ausreichend dimensionierter Server. Load Balancer, mehrere Nodes und getrennte Build-Server sollten erst hinzukommen, wenn Last oder Verfügbarkeitsanforderungen sie tatsächlich rechtfertigen. Ein einfaches Setup, das dokumentiert, überwacht und wiederherstellbar ist, ist wertvoller als eine komplexe Architektur ohne getesteten Notfallplan.