Container-Host auf Hetzner

01 Voraussetzung: Server-Basis

Konto, API-Token, hcloud CLI, SSH-Key, Firewall-Prinzip und die Skripte – der einmalige Teil steht in einer eigenen Anleitung, damit er nicht in jedem Guide steht.

Ab hier nur noch der Container-Teil: cloud-init-Zeile, Erstellen, die Podman-Docker-Verbindung und der Betrieb.

02 cloud-init-Datei schreiben

cloud-init ist ein Standardmechanismus, der beim allerersten Boot einer VM (virtuelle Maschine) einmalig ein kleines Setup-Skript ausführt. Wir lassen den Server damit Podman installieren und den podman.socket aktivierenDocker installieren und starten – ganz ohne manuelle Handgriffe. Die Datei muss mit der Zeile #cloud-config beginnen, und die Einrueckung (2 Leerzeichen) ist Pflicht.

#cloud-config
package_update: true
packages:
  - podman
runcmd:
  - systemctl enable --now podman.socket

#cloud-config
package_update: true
packages:
  - docker.io
  - docker-compose-v2
# Docker startet nach der Installation von selbst und kommt bei jedem Boot wieder.

Die Datei im aktuellen Verzeichnis speichern – dort, wo du gleich hcloud server create aufrufst.

03 Server erstellen

Ein Befehl erzeugt die VM. Sie bootet in Sekunden, danach läuft cloud-init aus Schritt 5 noch etwa 30–90 Sekunden im Hintergrund (Paketinstallation).

hcloud server create `
  --name podman-host `
  --type cpx22 `
  --image ubuntu-24.04 `
  --ssh-key laptop `
  --firewall podman-fw `
  --user-data-from-file cloud-init.yaml

hcloud server ip podman-host        # IP anzeigen -> oben ins Feld "Server-IP" eintragen

• --name podman-host ist nur ein Label (auch bei Docker ok). Es taucht in allen weiteren Befehlen wieder auf.
• --type: CPX22 = 2 vCPU / 4 GB (Gigabyte). Für mehrere Container eher CPX32 (4 / 8) oder CAX21 (ARM, gleiche Ausstattung, günstiger). Später ändern: hcloud server change-type podman-host cpx32.
• --location (optional): nbg1/fsn1 (Deutschland), hel1 (Finnland), ash/hil (USA). Ohne Angabe wählt Hetzner.
• Eine öffentliche IPv4 ist dabei (~0,50 €/Monat). Ohne: --without-ipv4 anhängen.

04 Server prüfen & Host-Key bestätigen

Der erste ssh-Kontakt fragt „The authenticity of host … can't be established. Continue?“ – das ist normal (dein Rechner kennt den neuen Server noch nicht). Mit yes bestätigen. Die Antwort wird gespeichert. Überspringst du das, scheitert die Verbindung in Schritt 8 stumm.

ssh root@<IP> "systemctl is-active podman.socket"

ssh root@<IP> "systemctl is-active docker"

05 Podman-Verbindung anlegenDocker-Context anlegen

Jetzt sagst du dem podmandocker-Befehl auf dem Laptop einmalig, dass er über SSH auf dem Server arbeiten soll. Ab dann geht jeder Befehl automatisch dorthin – kein Umweg nötig.

podman system connection add hetzner `
  --identity $env:USERPROFILE\.ssh\id_ed25519 `
  ssh://root@<IP>/run/podman/podman.sock

podman system connection default hetzner        # als Standard setzen
podman info --format "{{.Host.Hostname}}"        # muss den Server zeigen

Zwischen lokal und Cloud wechseln:

podman system connection default podman-machine-default   # zurueck zu lokal
podman --connection hetzner ps                            # nur ein Befehl remote
podman system connection list                             # alle Verbindungen

docker context create hetzner --docker "host=ssh://root@<IP>"

docker context use hetzner                    # als Standard setzen
docker info --format "{{.Name}}"              # muss "hetzner" zeigen

Zwischen lokal und Cloud wechseln:

docker context use default        # zurueck zu lokal
docker --context hetzner ps       # nur ein Befehl remote
docker context ls                 # alle Contexts

Verbindet docker context nicht, fehlt meist der Schlüssel im SSH-Agent. Einmalig:

Get-Service ssh-agent | Set-Service -StartupType Automatic
Start-Service ssh-agent
ssh-add $env:USERPROFILE\.ssh\id_ed25519

06 Container starten & Ports

Ganz normale Befehle – sie laufen dank Schritt 8 auf dem Server. podman composedocker compose funktioniert genauso. -p 8080:80 heißt: Port 80 im Container ist als Port 8080 auf dem Server erreichbar.

podman run -d --name web -p 8080:80 docker.io/library/nginx
podman ps
podman logs web

docker run -d --name web -p 8080:80 nginx
docker ps
docker logs web

Der Port ist von außen aber erst erreichbar, wenn die Firewall ihn durchlaesst. Zwei Wege:

a) Nur privat testen – nichts öffnen, per SSH tunneln:

ssh -L 8080:localhost:8080 root@<IP>
# Fenster offen lassen, dann im Browser:  http://localhost:8080

b) Öffentlich erreichbar – Port gezielt in der Firewall freigeben (dann http://<IP>:8080):

hcloud firewall add-rule podman-fw --direction in `
  --protocol tcp --port 8080 --source-ips 0.0.0.0/0,::/0

07 Container neustart-fest machen

Ein einfach gestarteter Container ist nach einem Server-Neustart weg. Damit dauerhaft laufende Dienste automatisch wiederkommen – beim Booten und nach Abstuerzen:

docker run -d --name web --restart=always -p 8080:80 nginx

docker update --restart=always web

ssh root@<IP>
# der Prompt wird jetzt zu  root@podman-host:~#  -> du bist auf dem Server

cat > /etc/containers/systemd/web.container <<'EOF'
[Container]
Image=docker.io/library/nginx
PublishPort=8080:80

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload      # neue Datei einlesen
systemctl start web          # Container starten

systemctl status web         # laeuft er?
journalctl -u web            # Logs ansehen
exit                         # zurueck zum Laptop

+ Kosten steuern

Hetzner rechnet stundenweise ab, solange der Server existiert – herunterfahren spart nichts. Der Snapshot-Zyklus (sichern → löschen → neu, Snapshot ~0,0143 €/GB/Monat) steht in Server-Snapshot & Restore. cloud.ps1 macht ihn per up/down.

Rechnungsposten pro Tag (Beispiel CPX32, 24 h Dauerbetrieb)

.\scripts\cloud.ps1 down stoppt Server und IPv4-Uhr sofort – nur der Snapshot läuft weiter (~0,06 €/Monat). Eine typische 3-h-Session ist ~4 Cent, ein vergessener Tag ~33 Cent. Bei einem Mehr-Node-Cluster alles × Anzahl Nodes (Load Balancer extra, siehe Microservices-Guide).

Richtwerte Region Deutschland, 2026, ohne IPv4-Aufschlag (~0,50 €/Monat). Die Intel-cx-Linie ist bei Hetzner oft ausverkauft – cpx (AMD, x86, gleiche Nutzung) ist der Ausweg. ARM (Advanced RISC Machines) cax nur mit ARM-Snapshot. Stundenpreis wird bis zum Monatspreis gedeckelt. Aktuell: hcloud server-type describe <typ>.

+ Absicherung

Sobald der Aufbau steht – in Ruhe nachziehen.

• Rootless statt root: einen normalen Linux-User anlegen, loginctl enable-linger <user> setzen (damit der User-Dienst ohne Login läuft), dann die Verbindung auf ssh://<user>@<IP>/run/user/<uid>/podman/podman.sock umstellen. Container laufen dann komplett ohne root – ein echter Podman-Vorteil.
• Zum root-Daemon: Der Docker-Daemon läuft als root, und wer den Docker-Socket erreicht, ist praktisch root auf dem Server. Deshalb: Socket nie per TCP (Transmission Control Protocol) ins Netz öffnen (dieser Guide nutzt nur SSH – passt). Wer es rootless will, richtet Rootless Docker (dockerd-rootless-setuptool.sh install als non-root User) ein – oder nimmt gleich Podman.
• Automatische Updates: apt install unattended-upgrades auf dem Server, dann laufen Sicherheitsupdates von selbst.
• SSH: Passwort-Login ist bei Hetzner-Images ohnehin aus. PermitRootLogin prohibit-password (nur Key) so belassen.
• Firewall-Default: alles Eingehende außer den bewusst geöffneten Ports bleibt zu – hier nichts weiter zu tun.

+ Kill-Switch: Vergessen darf nichts kosten

Die vier Schutz-Ebenen (Skript, Desktop-Verknüpfung, nächtliche Aufgabenplanung, serverseitige Selbstzerstörung) stehen komplett in Server-Snapshot & Restore. Hier nur:

.\scripts\cloud.ps1 up       # aus letztem Snapshot, podmandocker-Verbindung gesetzt
.\scripts\cloud.ps1 down     # Snapshot + loeschen -> Kosten sofort gestoppt
.\scripts\cloud.ps1 status

• cloud.ps1 liegt im Repo – Konfiguration oben: $Server='podman-host', $Firewall='podman-fw', $Connection='hetzner'.
• Serverseitiger Self-Destruct (cloud-init.selfdestruct.yaml): nur in einem separaten Hetzner-Projekt – Details in Server-Snapshot & Restore.

+ Andere Anbieter

Der Remote-Ablauf aus dieser Anleitung (Podman oder Docker) funktioniert auf jeder Linux-VM – nur IP, Image-Name und die Firewall-/Security-Group-Syntax ändern sich. Es gibt zwei Familien:

• VM mieten – du bekommst Root per SSH, richtest die Engine ein (Schritt 5), verbindest wie oben. Du pflegst das System (Updates, Backup). Tabelle A.
• Serverless-Container – kein Server, kein SSH. Du baust ein Image, schiebst es in eine Registry und definierst einen Dienst. Skaliert bei Nichtnutzung auf null. Anderer Workflow, siehe unten.

Tabelle A VM-Anbieter – passen zu dieser Anleitung

Alle Beträge grobe Richtwerte, August 2026. ARM-Anbieter (Oracle, AWS t4g, Azure Dpls, teils Scaleway/Hetzner cax) brauchen arm64-Images – bei offiziellen Images fast immer vorhanden.

Tabelle B Serverless – kein run auf einem Server, Image in Registry

Ablauf hier: build → push in eine Container-Registry → Dienst anlegen (mit podman oder docker). Kein SSH, kein Server. Vorteil: läuft nichts, zahlst (fast) nichts. Nachteil: Kaltstart 0,2–3 s und neuer Workflow.