Lösung

Hetzner Deployment automatisieren, statt jeden Server von Hand aufzusetzen

Ein Server ist in Minuten bestellt. Dann folgt Docker, Datenbank, Reverse-Proxy, SSL, Firewall und Backups einrichten. Das übernimmt die Plattform, sobald du per SSH anbindest.

Server per SSH anbinden, der Zugang bleibt vollständig bei dir
Docker, Datenbanken, Reverse-Proxy, SSL, Firewall und Backups werden eingerichtet
Direkte Anbindung an die GitLab-CI-Pipeline deines Projekts

Kostenlos registrieren Funktionen ansehen

Kostenlos starten. Keine Kreditkarte nötig.

Docker
Datenbanken
Reverse-Proxy
SSL
Backups
Firewall
Demnächst Kubernetes
Demnächst Monitoring

Ein angebundener Server wird automatisch für Deployments vorbereitet.

Kurz gesagt

Du behältst deinen Server und deinen Vertrag mit dem Anbieter. Die Einrichtung und die Verbindung zur Pipeline übernimmt die Plattform.

Anbindung per SSH: Du hinterlegst den Zugang, die Plattform übernimmt die Einrichtung.
Grundsetup automatisch: Docker, Datenbanken, Reverse-Proxy, SSL, Firewall und Backups entstehen.

Server selbst einrichten oder über die Plattform anbinden

Die Gegenüberstellung beschreibt die Aufgaben, die zwischen einem bestellten Server und einem funktionierenden Deployment liegen.

Aufgabe	Mit der Application Platform	Server selbst einrichten
Grundsetup des Servers	Vollständig abgedeckt: Docker, Datenbanken, Reverse-Proxy, SSL, Firewall und Backups werden eingerichtet	Nicht vorgesehen: Jeder Schritt einzeln, meist nach eigener Checkliste oder Notizen
Deployment anschließen	Vollständig abgedeckt: Der Server wird mit der GitLab-CI-Pipeline des Projekts verbunden	Teilweise abgedeckt: Eigenes Skript oder Deployment-Werkzeug einrichten und pflegen
Zertifikate und Erneuerung	Vollständig abgedeckt: SSL gehört zum Setup, Domains werden im Projekt verwaltet	Teilweise abgedeckt: Zertifikatsablauf fällt oft erst über eine Fehlermeldung auf
Backups	Vollständig abgedeckt: Werden beim Einrichten mit angelegt	Teilweise abgedeckt: Häufig nachgelagert und selten getestet
Zugangsdaten und Umgebungsvariablen	Vollständig abgedeckt: Zentral im Projekt verwaltet, mit Rechten pro Rolle	Nicht vorgesehen: Verteilt über Dateien auf dem Server und lokale Notizen
Nachvollziehbarkeit der Umgebung	Vollständig abgedeckt: Umgebungen und Deployments liegen als Konfiguration im Git-Verlauf	Nicht vorgesehen: Der Zustand steckt in der Maschine, nicht in einem Repository
Zweiten Server aufsetzen	Vollständig abgedeckt: Derselbe Ablauf, unabhängig von Anzahl und Anbieter	Nicht vorgesehen: Wiederholung der Handarbeit, mit kleinen Abweichungen
Mehrere Umgebungen trennen	Vollständig abgedeckt: Staging und Produktion als getrennte Umgebungen im Projekt	Teilweise abgedeckt: Oft ein Server für alles, weil ein zweiter Aufwand bedeutet
Zugriffsrechte im Team	Vollständig abgedeckt: Rollen und Projektzugehörigkeit steuern den Zugang zum Server	Nicht vorgesehen: SSH-Schlüssel werden verteilt und selten wieder entfernt
Volle Kontrolle über die Maschine	Vollständig abgedeckt: SSH-Zugang bleibt bei dir, du kannst jederzeit selbst eingreifen	Vollständig abgedeckt: Ebenfalls vollständig, ohne jede Vorgabe von außen

Grün bedeutet abgedeckt, gelb teilweise, grau nicht vorhanden. Die rechte Spalte beschreibt keinen Anbieter, sondern die übliche Handarbeit bei einem frisch bestellten Server.

Stand: 10. August 2026. Die Gegenüberstellung beschreibt typische Abläufe und kann je nach Projekt abweichen.

Was die Anbindung eines eigenen Servers bringt

Sechs Punkte, die den Unterschied zwischen einer leeren Maschine und einer Betriebsumgebung ausmachen.

Der Server bleibt deiner

Du behältst SSH-Zugang und den Vertrag mit deinem Anbieter. Die Plattform richtet ein, sie übernimmt nicht.

Grundsetup ohne Handarbeit

Docker, Datenbanken, Reverse-Proxy, SSL, Firewall und Backups entstehen automatisch statt nach Notizen aus dem letzten Projekt.

Deployments aus der Pipeline

Der Server hängt an der GitLab-CI-Pipeline. Test, Build, Publish und Release folgen demselben Weg.

Umgebungen im Git-Verlauf

Der gleiche Ablauf funktioniert mit anderen Hostern und mit Managed Servern der Plattform.

Server per SSH anbinden und pro Umgebung zuweisen.

So bindest du einen Hetzner-Server an

Vier Schritte von der bestellten Maschine zum ersten Deployment.

Server bereitstellen

Lege den Server bei deinem Anbieter an. Für die Anbindung brauchst du lediglich einen erreichbaren SSH-Zugang.
Zugang in der Plattform hinterlegen

Trage den Server im Bereich Server ein. Die Plattform prüft den Zugang und beginnt mit der Einrichtung.
Grundsetup abwarten

Docker, Datenbanken, Reverse-Proxy, SSL, Firewall und Backups werden aufgesetzt und für Deployments vorbereitet.
Projekt verbinden

Wähle den Server beim Anlegen oder Bearbeiten eines Projekts aus. Ab dann deployt die Pipeline dorthin.

Häufige Fragen

Gibt es eine Anleitung für die Anbindung?

Ja, die Dokumentation enthält ein Hetzner-Tutorial mit den einzelnen Schritten bis zum fertigen Server. Für andere Anbieter läuft es über SSH vergleichbar. Wer keinen eigenen Server verwalten will, findet dort auch Managed Server.

Besteht eine Partnerschaft mit Hetzner?

Nein. Hetzner ist ein unabhängiges Unternehmen ohne geschäftliche Verbindung zur Plattform. Die Anbindung läuft über einen normalen SSH-Zugang, genauso wie bei anderen Hostern. Vertrag und Abrechnung regelst du direkt mit deinem Anbieter.

Funktioniert das auch mit anderen Anbietern?

Technisch ja, aber mit Vorsicht. Die Plattform richtet eine definierte Grundlage ein, was zu Überschneidungen bei Ports oder Diensten führen kann. Eine frische Maschine ist der einfachere Start.

Binde deinen Server an

Registriere dich kostenlos, hinterlege einen Server per SSH und sieh dir an, wie weit die Einrichtung ohne dein Zutun kommt.

Kostenlos registrieren Mit uns sprechen