Alles selbst
- Du härtest die Box selbst und willst kein fremdes Setup darauf.
Hetzner-Server anbinden, Grundsetup nicht von Hand machen
Hetzner bleibt oft die richtige Hardware. Was fehlt, ist alles danach: Docker, Datenbank, Reverse-Proxy, Zertifikat, Firewall, Backup, dann CI. SSH reicht uns als Anschluss.
- Du behältst root. Wir richten ein, was Deployments brauchen.
- Produktion und Staging können auf getrennten Boxen liegen, dieselbe Pipeline
Nur die Console oder SSH plus Setup
Hetzner, angebunden
- Die Maschine ist bestellt. Das Grundsetup soll nicht noch einmal erfunden werden.
Docker
Datenbanken
Reverse-Proxy
SSL
Backups
Firewall
- Demnächst
Kubernetes
- Demnächst
Monitoring
Hetzner ist in Minuten da. Der Rest des Tages ist Docker, Zertifikate, Firewall, Backup – und beim zweiten Server dieselbe Liste. Automatisieren heißt hier nicht „Hetzner nachbauen“, sondern den Server so anschließen, dass die Pipeline ihn kennt.
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 angeboten: 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 angeboten: 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 angeboten: 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 angeboten: 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 angeboten: 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: 9. September 2026. Grundlage sind die öffentlich dokumentierten Funktionsumfänge der genannten Anbieter. Angaben können sich ändern; maßgeblich ist die jeweils aktuelle Darstellung des Anbieters. Logos sind Marken der jeweiligen Rechteinhaber und dienen nur der Zuordnung.
Was Hetzner allein schon liefert
- Preis und Standort Hetzner bleibt oft die richtige Hardware. Die Plattform ersetzt den Hoster nicht, sie hängt sich an den Server.
Kostenmodell
Den Server zahlst du bei Hetzner. Die Plattform ist ein eigener Posten.
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?
Ja. Entscheidend ist ein erreichbarer Server mit SSH-Zugang, nicht der Anbieter. Maschinen bei anderen Hostern oder im eigenen Rechenzentrum lassen sich genauso anbinden. Alternativ nutzt du einen Managed Server der Plattform.
Bleibt mein SSH-Zugang erhalten?
Er bleibt bestehen. Du kannst dich jederzeit selbst verbinden und nachsehen, was läuft. Die Plattform deployt dorthin, nimmt dir den Zugriff aber nicht ab. Rollen und Projektzugehörigkeit steuern, wer den Server sieht und deployen darf.
Kann ich einen bereits genutzten Server anbinden?
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.