- Dieser Artikel ist eine Checkliste, die den Ablauf des Self-Hostings auf einem VPS mit Hetzner und Coolify Schritt für Schritt ausführlich dokumentiert
- Hetzner wird wegen niedriger Latenz in Europa, hervorragendem Preis-Leistungs-Verhältnis und transparenten Tarifen empfohlen
- Enthalten sind praxisnahe Themen wie anfängliches Server-Setup, SSH-Sicherheit, Firewall und die Einrichtung automatischer Updates
- Außerdem wird detailliert erklärt, wie man eine Produktionsumgebung für Node.js-Apps, Monitoring, Backups und Troubleshooting sicher einrichtet
- Es ist ein praxisnaher Leitfaden, mit dem man beim Aufbau eines eigenen Servers DevOps-Kompetenzen und freie Verwaltungsmöglichkeiten entwickeln kann
Checkliste zur Vorbereitung des VPS-Setups
- Bei der Auswahl eines VPS-Anbieters wird Hetzner in Bezug auf Preis/Leistung als Empfehlung genannt
- Empfohlen wird eine Konfiguration mit mindestens 1 GB RAM und 20 GB Speicher; außerdem sollten die IP-Adresse des Servers und die Root-Kontodaten notiert werden
- Auf dem lokalen Rechner sollte ein SSH-Client bereitstehen; zudem sollte ein starker Passwortgenerator verwendet werden
Warum dieser VPS-Anbieter gewählt wird
- Hetzner Cloud ist in Europa günstig, schnell und zuverlässig
- Alternativen: DigitalOcean (gutes Onboarding und gute Dokumentation, aber teurer geworden), AWS Lightsail (an AWS gebunden, für Einsteiger schwieriger), Linode (stabil, aber weniger preislich konkurrenzfähig), Render/Fly.io (als PaaS bequem, aber mit höheren Kosten und mehr Einschränkungen)
- Hetzner ist bei gleicher Ausstattung 2- bis 3-mal günstiger, hat keine intransparenten Abrechnungen und punktet mit Rechenzentren in Europa
Checkliste für das anfängliche Server-Setup
Erste Anmeldung und System-Updates
- Paketlisten aktualisieren und das System upgraden
- Befehle zum Prüfen von Systeminformationen werden angegeben (z. B. uname -a, cat /etc/os-release)
Absicherung des Root-Kontos
- Es sollte ein komplexes Passwort gesetzt und sicher gespeichert werden
- Statt konventioneller Kontonamen wie 'admin' oder 'user' sollte ein eindeutiges Benutzerkonto angelegt werden
- Dem neuen Konto sollten sudo-Rechte gegeben und deren korrekte Anwendung geprüft werden
SSH-Schlüssel-Authentifizierung einrichten
- Auf dem lokalen Rechner ein Schlüsselpaar mit Ed25519 (empfohlen) oder RSA erzeugen
- Den öffentlichen Schlüssel in
.ssh/authorized_keys des Servers eintragen und die Berechtigungen setzen
- Prüfen, ob der SSH-Login korrekt funktioniert (also ohne Passworteingabe)
- Passwort-Authentifizierung deaktivieren und bei Bedarf auch separate cloud-init-Dateien prüfen
- Den SSH-Daemon neu starten und den ordnungsgemäßen Betrieb überprüfen
- Root-Login deaktivieren, um Remote-Anmeldungen als Root zu unterbinden
Checkliste zur Firewall-Konfiguration
UFW-Grundeinstellungen
- Alle eingehenden Verbindungen standardmäßig blockieren, ausgehende erlauben
- SSH sowie die Ports für HTTP (80) und HTTPS (443) freigeben und prüfen, ob UFW korrekt angewendet wird
- Optional: den SSH-Port auf bestimmte IPs beschränken oder die Portnummer ändern (zur Härtung), um eine zusätzliche Schutzschicht einzubauen
Checkliste zur Einrichtung automatischer Updates
Unattended Upgrades konfigurieren
- Die Pakete unattended-upgrades und apt-listchanges installieren und die Standardaktivierung bestätigen
- Sicherheitsupdates aktivieren, außerdem lassen sich E-Mail-Benachrichtigungen und automatischer Reboot konfigurieren
- Die automatische Update-Funktion testen und ihren Status prüfen
Checkliste für die Bereitstellung einer Produktionsanwendung
Node.js-Laufzeitumgebung einrichten
- Node.js LTS installieren und die Version prüfen
- Anwendungsdateien auf den Server hochladen und durch Installation der Abhängigkeiten für den Produktivbetrieb vorbereiten
Prozessmanager (PM2) verwenden
- Die App mit PM2 im Production-Modus starten, optional mit Clustering
- Autostart von PM2 beim Booten einrichten sowie Befehle für Neustart und Monitoring nutzen
Reverse Proxy (Nginx) einrichten
- Eine Nginx-Site-Konfigurationsdatei erstellen und
proxy_pass anwenden
- Die Site aktivieren und Nginx neu starten
Checkliste zur Einrichtung von SSL-Zertifikaten
Let's Encrypt und Certbot
- Nach Installation von certbot und python3-certbot-nginx domänenbasierte SSL-Zertifikate automatisch ausstellen
- Optionen für automatische Verlängerung und Tests zur Zertifikatsgültigkeit einrichten
Checkliste für Monitoring und Wartung
Grundlegende Monitoring-Methoden
- Tools zur Überwachung von Systemressourcen wie htop und iotop installieren
- syslog und auth.log in Echtzeit überwachen sowie eine Log-Rotation-Richtlinie (logrotate) einrichten
Backup-Strategie
- Mit tar ein Backup-Skript für Anwendung und Datenbank erstellen
- Regelmäßige Backups nach Zeitplan (crontab) ausführen
Checkliste zur Fehlerbehebung
Probleme beim SSH-Zugriff
- Firewall-Einstellungen, Status des SSH-Dienstes, Authentifizierungslogs und Netzwerk prüfen
Berechtigungsfehler
- Datei- und Ordnerrechte, Gruppen und sudo-Konfiguration überprüfen
Dienst startet nicht
- Mit systemctl und journalctl Status und Logs prüfen sowie die Syntax der Konfigurationsdateien kontrollieren
Übermäßige Ressourcennutzung
- Prozesse, Datenträger, Netzwerk und Anwendungslogs analysieren
Checkliste zur abschließenden Prüfung
Sicherheitsprüfung
- Kontrollieren, ob alle Punkte wie SSH-Schlüssel-Authentifizierung, Passwort-Login, Root-Login, Firewall, automatische Updates, Production-Modus, SSL und Backups korrekt funktionieren
Leistungstest
- Mit Apache Bench einen Lasttest durchführen, dabei Ressourcen überwachen und Fehler in den Logs prüfen
Liste nützlicher Schnellbefehle
Systeminformationen prüfen
- htop, df -h, free -h, uname -a
Prozessverwaltung
- pm2 status, pm2 restart all, pm2 logs, pm2 monit
Sicherheit
- sudo ufw status, sudo fail2ban-client status, sudo lynis audit system
Dienstverwaltung
- sudo systemctl status nginx, sudo systemctl restart nginx, sudo journalctl -u nginx
Fazit
- Diese Checkliste bietet ein vollständiges Verfahren für VPS-Setup und -Verwaltung
- Neben niedrigen Kosten gewinnt man auch direkte Kontrolle, Lernmöglichkeiten und DevOps-Autonomie
- Self-Hosting mit Hetzner und Coolify ermöglicht Vertrauen und Freiheit durch praktische Erfahrung
- Der Inhalt dient allen, die sich an VPS-Hosting wagen wollen, als konkreter Leitfaden
1 Kommentare
Hacker-News-Kommentar
Ich finde, das ist wirklich eine großartige Zusammenfassung für Anfänger, ich werde sie mir definitiv als Lesezeichen speichern.
Schade ist nur, dass Coolify im Titel erwähnt wird, im eigentlichen Text aber kaum vorkommt.
Ein weiterer nützlicher Artikel zu einem ähnlichen Thema ist
Setting up a Production-Ready VPS from Scratch, den ich mir unter folgendem Link gespeichert habe:https://dreamsofcode.io/blog/setting-up-a-production-ready-vps-from-scratch
Wenn ich solche Themen etwas tiefer verstehen möchte, gebe ich den Artikellink meist in ein LLM ein und verwende etwa folgenden Prompt:
"Dies ist ein Artikel über das 'Thema/den Titel': https://article.link. Erfasse und analysiere ihn gründlich, erweitere dann jeden Abschnitt mit deinem Wissen und füge auch zusätzliche relevante Abschnitte hinzu."
So lerne ich dabei.
https://www.youtube.com/watch?v=taJlPG82Ucw
Mit diesem Setup betreibe ich mein System nun seit etwa einem Jahr, und zum ersten Mal fühlte sich Self-Hosting für mich wirklich machbar an.
OVH ist genauso vertrauenswürdig wie Hetzner, hat aktuell aber deutlich günstigere Angebote.
https://us.ovhcloud.com/vps/configurator/?planCode=vps-2025-model3&brick=VPS%2BModel%2B3&pricing=upfront12&processor=%20&vcore=8__vCore&storage=200__SSD__NVMe
Wenn ich Coolify nutzen würde, wäre ich unschlüssig, welche Distribution ich wählen sollte.
Ich überlege zwischen Ubuntu 24.04 und Debian 13 und frage mich, was die bessere Wahl wäre.
OVH VPS kostet bei 24 vCPU (oder Threads) und 96 GB RAM 53,4 $ im Monat.
Ein Hetzner VPS (mit AMD-Option) hat 16 vCPU, 32 GB und kostet 54,9 $/Monat.
Ein DO Droplet kostet bei 16 vCPU und 64 GB RAM 504 $/Monat.
Linode und Upcloud liegen bei 24–20 vCPU und 96 GB RAM ebenfalls bei 576 $/Monat und sind damit im Vergleich zu OVH deutlich teurer.
Ich weiß nicht, welche CPU OVH verwendet, aber selbst wenn es angesichts des Preisunterschieds eine Intel-E-Core-CPU wäre, wäre das immer noch ein ziemlich gutes Angebot.
Zur Einordnung: Es gibt bei Hetzner auch günstigere Intel-vCPU-Optionen, aber das ist ältere Hardware und Plätze werden nur frei, wenn andere Kunden kündigen.
Deshalb habe ich nur die aktuelle AMD-Option zum Vergleich herangezogen.
Das einzige Problem bei OVH ist, dass ich zum Mieten eines VPS (um die 30 $ im Monat) zwingend eine Kopie meines Ausweises einsenden musste.
Ich wollte meine persönlichen Daten nicht auf diese Weise weitergeben und habe mich deshalb am Ende für einen teureren Anbieter entschieden.
Nach meiner Erfahrung (wenn auch nicht allzu umfangreich) waren Hetzner-Cloud-Server leistungstechnisch deutlich besser als OVH-VPS.
Ich bin aber mit beiden Anbietern zufrieden.
Ich frage mich, warum OVH und Hetzner im Vergleich zu anderen Anbietern so viel günstiger sind.
Bei VPS verstehe ich es teilweise, weil dort stärker geteilt wird als anderswo, aber diese beiden Anbieter haben auch dedizierte Server zu sehr niedrigen Preisen.
Da fragt man sich fast, ob das ein Lockangebot ist, und ich frage mich auch, ob sich die OVH-Preise kürzlich geändert haben.
Ich meine mich zu erinnern, dass OVH vor ein paar Jahren teurer war als Hetzner.
Alle hier genannten CPUs sind mit hoher Wahrscheinlichkeit in Wirklichkeit gemeinsam genutzte Ressourcen.
Und wie stark sie tatsächlich geteilt werden, wird nicht offengelegt.
Bei Hetzner gibt es Server mit derselben Kernanzahl zum halben Preis.
Oberflächlich ist das nicht sichtbar, aber wenn man die Leistung direkt testet, bringen die günstigeren Server tatsächlich nur etwa die halbe Performance.
Nachdem ich in den CSS-Einstellungen die folgenden beiden Dinge deaktiviert habe, wurden UI/UX des Blogs deutlich besser:
pre {
margin: 2rem 0 !important;
padding: 1rem !important;
}
Die Padding- und Margin-Werte der Code-Blöcke waren so groß, dass auf dem Bildschirm nur drei Zeilen sichtbar waren.
Und wenn man Webmin/Virtualmin installiert, werden Aufgaben wie das Hinzufügen neuer Subdomains oder Benutzer viel einfacher.
Ich habe wegen Coolify geklickt, aber tatsächlich wird es nur in den Tags, der Einleitung und dem Schluss erwähnt, nicht im eigentlichen Haupttext.
Ich finde schon die Erwähnung von Coolify unpassend.
Der Artikel handelt in Wirklichkeit davon, wie man einen VPS für ein Coolify-Deployment vorbereitet.
Die Installation von Coolify selbst wird nicht behandelt.
Bisher verwalte ich alle meine Services auf einer VM mit Docker Compose, und ich habe geklickt, weil ich wissen wollte, ob Coolify eine deutlich bessere Alternative dazu ist.
Aber es gab überhaupt keinen echten Inhalt zu Coolify, und die manuellen Schritte zur Vorbereitung für Coolify wirkten eher noch komplizierter.
Mein Ansatz, bei dem ich eine Docker-Compose-Basis verwende und nur ein paar Dinge anpasse, erscheint mir viel einfacher.
Dadurch habe ich eher das Gefühl, dass meine bisherige Methode weiterhin gut funktioniert.
Ein großer Vorteil ist, dass sich ein Umzug zwischen Hosts zu 99 % erledigt, indem man einfach nur die Docker-Compose-YAML-Datei kopiert.
Ich habe Coolify vor ein paar Monaten ausprobiert, und es gab alle möglichen Probleme, wenn mehrere Container über Compose miteinander verbunden waren.
Zum Beispiel habe ich manchmal vergessen, dass ein bestimmter Container schon lief, und ihn doppelt gestartet, oder beide liefen, aber Coolify erkannte nur einen davon.
Wenn man jeden Service einzeln in Coolify registriert, funktioniert es einigermaßen gut.
Letztlich bin ich auch wieder zu einem eigenständigen Setup auf Basis von Docker Compose zurückgekehrt, und das war im Betrieb deutlich einfacher.
Ich halte Versuche wie Coolify grundsätzlich für sehr wichtig, aber aktuell ist es meiner Meinung nach noch nicht ausgereift genug für den echten Produktiveinsatz.
Wenn Coolify oder ähnliche Projekte weder DB-Backups noch Streaming-Replikation unterstützen, bleiben sie letztlich im Hobbybereich.
Ich betreibe zwei VMs mit Docker Compose und bash-Skripten, und allein mit stündlichen Backups nach S3, WAL-Streaming sowie Streaming-Replikation für PG und Redis sind für mich die Mindestanforderungen für echten Produktivbetrieb schon erfüllt.
Es hängt wohl vom Einsatzzweck ab, aber ich habe sowohl Coolify als auch CapRover verwendet.
Am Ende habe ich mich für CapRover entschieden, weil ich dort per Git Hook bei jedem Commit automatisch bauen konnte und damit NodeJS-Apps schneller bereitstanden.
Beides wird zwar von beiden unterstützt, aber bei CapRover ist die Reibung geringer.
Coolify hat dafür mehr Funktionen.
Coolify läuft auf Traefik und Docker und ist im Grunde nur eine UI darüber.
Viele essenzielle Backup-Funktionen fehlen (auch wenn sich das mit etwas wie restic lösen lässt), und auch die UX ist nur so gerade brauchbar.
Coolify benötigt bei der Installation weiterhin Root-Rechte.
Ich habe gehört, dass an einem Branch gearbeitet wird, der eine Installation ohne Root ermöglichen soll.
Man kann sich per SSH auf dem Server anmelden, Coolify installieren und danach den Root-Login deaktivieren.
Wenn man bereit ist, den Server notfalls zu zerstören und alles von Grund auf neu aufzusetzen, ist das machbar.
Ich habe selbst erst vor Kurzem versucht, ein Coolify-Deployment komplett neu aufzusetzen, und hatte ständig Probleme mit den SSH-Schlüsseln.
Ich deploye zwar auf anderen Servern problemlos mehrere Projekte, aber der Ansatz „gib einfach die Docker-Compose-Datei an“ hat in der Praxis bei mir noch nie wirklich funktioniert.
Ich habe vor Kurzem einen FreeBSD-Server zu Hetzner migriert, und das war sehr einfach.
Die einzige Besonderheit war, dass Ports für Mailserver blockiert bleiben, bis der erste Abrechnungszeitraum vollständig abgeschlossen ist.
Ich verstehe diese Richtlinie, aber am Anfang wurde das nicht klar kommuniziert, was irritierend war.
Falls die Kreditkarte abläuft, sollte man wissen, dass Hetzner offenbar auch sofort die Netzwerkverbindung kappt.
Es gab keine Vorwarnung, und ich habe es erst mitbekommen, als sich ein echter Kunde oder ein Mitarbeiter bei mir meldete.
Mir ist das tatsächlich passiert.
Wenn man dem Hetzner-Team die Art des Traffics erklärt und nachfragt, öffnen sie die Ports manchmal auch vorab.
Ich habe als Nachweis das Projekt gezeigt, das ich migrieren wollte, und sie haben es sofort freigeschaltet.
Tools wie Coolify oder Dokploy sehen zwar gut aus, aber mich stört immer, dass der Serverzustand nicht als Code erhalten bleibt.
Deshalb bevorzuge ich NixOS oder Ansible, aber für echte Produktions-Setups ist dafür sehr viel Boilerplate und Customizing nötig.
Kennt jemand vielleicht ein Infrastructure-as-Code-Framework, das nicht Kubernetes ist, deklarativer arbeitet und die Verwaltung von Produktionsservern einfacher macht?
Von der Coolify-Konfiguration selbst gibt es fast nichts zu sichern, und die App-Einstellungen liegen alle unter /data/coolify.
Ich sichere das gesamte Volume mit kopia.
Das ist nicht besonders elegant gelöst, eher ein Workaround, aber für Disaster Recovery ist es durchaus brauchbar.
Guter Leitfaden.
Gerade bei Hetzner stimme ich der Firewall-Konfiguration aber nicht zu.
Wenn man nur eine einfache Konfiguration braucht, reicht die von Hetzner bereitgestellte Firewall völlig aus, und man hat zusätzlich einen gewissen „Outsourcing“-Effekt.
Wenn man es individueller möchte, lässt sich das auch per API konfigurieren.
https://docs.hetzner.cloud/reference/cloud#firewalls
Ich frage mich, ob es einen gravierenden Nachteil bei der Hetzner-Firewall gibt.
Den Rat „Erlaube SSH nur von meiner IP aus (optional, aber empfohlen)“ halte ich für riskant.
Wenn sich die IP ändert, kann man sich vollständig aussperren.
Über das Hetzner-Dashboard kann man das zwar zurücksetzen, aber statt es an eine sich ständig ändernde Heim-IP zu binden, ist es besser, etwas wie Tailscale zu verwenden
oder eine feste externe VPN-IP zu haben.
Schon allein die Nutzung von SSH-Schlüsseln verhindert fast alle typischen Sicherheitsprobleme.
Zusätzlich ist es sinnvoll, noch eine Schicht einzuziehen, die das Rauschen in den Logs reduziert, und Services, die außer SSH nicht von außen erreichbar sein müssen,
per VPN oder Ähnlichem abzuschotten.
Tatsächlich sind auf den meisten Servern andere Dienste verwundbarer als SSH.
Ja, das ist definitiv riskant.
Viele Leute zu Hause haben dynamische IPs.
Wenn man SSH-Schlüssel einrichtet und nur den Root-Login deaktiviert, ist das meiner Meinung nach sicher genug.
Ich denke, den Teil zum Setup von Produktions-Apps sollte man lieber durch Docker ersetzen.
Heutzutage ist Docker viel besser reproduzierbar und einfacher zu konfigurieren.