Vom Homelab in die Cloud: Der Umzugs-Ablaufplan

Warum überhaupt umziehen? #

Das Homelab läuft. Die Frage ist nur: Was passiert, wenn der DSL-Anschluss ausfällt, die Glasfaser-Baustelle vor der Haustür den Uplink lahmlegt, oder du ein halbes Jahr ins Ausland gehst? Ein Cloud-Server gibt dir symmetrische Anbindung mit hoher Bandbreite, USV-gepufferte Rechenzentren und eine öffentliche IPv4 – Verfügbarkeit und Standort-Unabhängigkeit, die ein Anschluss zu Hause schlicht nicht bieten kann. Das kostet mehr als der reine Stromverbrauch des Homelabs, aber dafür bekommst du eine Infrastruktur, die nicht von deiner Haustür-Internetleitung abhängt.

Die gute Nachricht: Weil die ganze Architektur von Anfang an hardware-agnostisch aufgebaut ist (Ansible + Flux CD als Single Source of Truth), ist der Umzug kein Neubau, sondern ein zweiter Lauf derselben Playbooks auf anderer Hardware. Dieser Post zeigt den kompletten Ablaufplan – mit Parallelbetrieb, damit du jederzeit zurück kannst, falls etwas schiefgeht.

Eine Sache vorweg: Ein paar Bausteine aus dem Homelab funktionieren in der Cloud nicht unverändert – allen voran die Art, wie LoadBalancer- und Control-Plane-IPs ins Netz announciert werden. Dazu kommt in Phase 3 ein eigener Abschnitt.

Zielarchitektur auf der Cloud-Seite #

Auf dem Cloud-Server läuft Proxmox – die gleiche Basis wie zuhause. Darauf:

• 1 WireGuard-VM (Debian, 1 vCPU, 1 GB RAM) – VPN-Gateway für alle internen Dienste
• 1 K8s-Control-Plane-VM
• 2–3 K8s-Worker-VMs (je nach Server-Ausstattung)
• 1 NFS-VM für RWX-Volumes (analog zum Homelab)

Eine Cloud-Firewall (bei den meisten Providern kostenfrei vorgelagert) lässt nur rein, was wirklich public sein muss: 80/tcp, 443/tcp für Nextcloud und Immich, 51820/udp für WireGuard. Alles andere bleibt dicht. Bietet der Provider keine vorgelagerte Firewall, übernimmt nftables auf dem Proxmox-Host dieselbe Aufgabe – die providerseitige Variante ist aber robuster, weil sie auch bei kompromittiertem Host noch greift.

Warum WireGuard in einer eigenen VM und nicht im Cluster? #

Weil du dann auch bei einem kaputten Cluster noch reinkommst. Läuft der VPN-Endpunkt als Pod und der Cluster klemmt, stehst du vor verschlossener Tür. Die eigene VM kostet 1 GB RAM und gibt dir im Worst Case Zugriff auf Proxmox und die NFS-VM, unabhängig vom Kubernetes-Zustand – dasselbe Prinzip wie “Backup zuerst”: Zugang und Wiederherstellung müssen unabhängig vom Hauptsystem funktionieren.

Tailscale oder Headscale wären komfortabler, bringen aber einen zusätzlichen Control-Plane-Layer mit. Für einen einzelnen Standort ist das Over-Engineering – WireGuard direkt reicht.

Der Ablaufplan in sieben Phasen #

Der Umzug läuft im Parallelbetrieb: Das Homelab bleibt online, bis die letzte DNS-Umstellung erfolgt ist. So kannst du jederzeit zurück, und es gibt keinen Zeitdruck an irgendeinem Wochenende.

Phase 1: Server-Vorbereitung #

1. Server bestellen – ausreichend RAM für alle VMs plus Reserve, zwei NVMe-SSDs für ZFS-Mirror. Faustregel: was im Homelab in Summe läuft, plus 30 % Puffer.

2. Proxmox installieren – über den vom Provider angebotenen Weg (Rescue-System, Image-Installer oder manuell von Debian aus). ZFS-Mirror über beide NVMes, verschlüsselt.

3. System härten – Pflicht, bevor irgendetwas ans Netz geht. Die Basics: SSH auf Key-only umstellen (PasswordAuthentication no), root-Login deaktivieren, einen nicht-Standard-Port wählen (kein echter Sicherheitsgewinn, aber spürbar weniger Log-Rauschen durch Massen-Scans) und den Zugang per AllowUsers-Allowlist begrenzen. Dazu Fail2ban fürs sshd-Jail und unattended-upgrades für den Security-Channel – auf einem exponierten Host ist ungepatcht das größere Risiko als ein gelegentlicher Update-Reboot. Sinnvoll ist außerdem Kernel- und Netzwerk-Hardening via sysctl.

   Eine vollständige, systematische Härtung ist ein eigenes Thema – darauf gehe ich in einem der nächsten Posts genauer ein, inklusive der etablierten Referenzrahmen (CIS Benchmarks) und Werkzeuge zur automatisierten, reproduzierbaren Umsetzung. Dann auch mit konkreten Links zum Einarbeiten.

4. Cloud-Firewall konfigurieren – beim Provider: 22/tcp (bzw. dein SSH-Port) nur von deiner Home-IP, 51820/udp von überall, 80/443 von überall, Rest DROP. Diese Firewall sitzt im Provider-Netz vor dem Server, unabhängig vom OS.

5. Zeit-Sync und Monitoring-Basis – chrony und Prometheus-Node-Exporter, damit der Host im Monitoring ist, bevor VMs laufen.

Phase 2: Netzwerk und VMs #

1. Proxmox-Netzwerk anlegen – vmbr0 auf der öffentlichen IP, vmbr1 als internes Bridge-Netz (z. B. 10.10.0.0/24).
2. WireGuard-VM erstellen – kleine Debian-VM mit zwei Interfaces: NIC auf vmbr0 für eingehende WireGuard-Verbindungen, NIC auf vmbr1 fürs Routing ins interne Netz.
3. WireGuard-Server konfigurieren – Keys generieren, Client-Configs vorbereiten. AllowedIPs clientseitig: nur das interne 10.10.0.0/24, kein Full-Tunnel. Der WG-Server übernimmt Routing und NAT ins VM-Netz.
4. VPN-Test vor allem anderen – bevor ein Kubernetes-Knoten entsteht, muss WireGuard stehen: von unterwegs einwählen, den Proxmox-Host über seine interne IP erreichen. Erst dann geht es weiter.
5. K8s-VMs anlegen – Control Plane, Worker, NFS-VM. Identische Dimensionierung wie im Homelab, damit die Ansible-Rollen ohne Änderung laufen.

Phase 3: Kubernetes und GitOps #

Hier zahlt sich die hardware-agnostische Architektur aus: derselbe Ansible-Lauf wie zuhause, nur gegen ein anderes Inventory.

1. Ansible-Inventory erweitern – neue Gruppe cloud mit den IPs der neuen VMs. Die Rollen bleiben weitgehend identisch.
2. K8s-Cluster ausrollen – ansible-playbook site.yml -i inventories/cloud. Kubeadm, Calico (eBPF), kube-vip, NFS-Subdir-Provisioner – alles wie gehabt.
3. Flux CD bootstrappen – auf einen neuen Branch oder ein neues Cluster-Verzeichnis zeigen. Cluster-spezifische Werte (LoadBalancer-Range, Storage-Klassen, Domain) kommen aus Overlays; die App-Definitionen sind dieselben.
4. Infrastruktur-Layer prüfen – Traefik, cert-manager, Reflector, SOPS, Monitoring (Prometheus, Grafana, Loki, Alloy) müssen stehen, bevor die Anwendungen kommen.

Der Stolperstein: kube-vip und ARP funktionieren in der Cloud nicht #

Das ist der Punkt, an dem ein 1:1-Umzug scheitert, wenn man ihn nicht kennt. Im Homelab macht kube-vip Layer-2-ARP: Ein Knoten beansprucht per Gratuitous ARP eine virtuelle IP (Control-Plane-VIP auf 6443, Service-IP für Traefik) und announciert sie ins flache LAN. Im Cloud-Netz funktioniert das nicht:

• Kein flaches L2-Segment nach außen – das Provider-Netz ist gerouted, kein Broadcast-Segment, das man per ARP beschwatzen kann.
• Anti-Spoofing – der virtuelle Switch leitet Pakete nur an die fest zugewiesene IP/MAC einer VM. Eine VM, die per Gratuitous ARP eine fremde IP übernehmen will, wird ignoriert. Genau davon lebt aber vip_arp: "true".
• Kein BGP zur Hand – die saubere Alternative wäre kube-vip im BGP-Mode gegen einen Router, der die VIP-Route lernt. Eine BGP-Session zum Provider-Router bekommst du bei einem typischen Cloud-Server aber nicht.

Sowohl Control-Plane-VIP als auch Traefik-Service-IP, die im Homelab beide an vip_arp: "true" hängen, brauchen also einen anderen Mechanismus:

• Öffentliche Dienste: Eingehender Traffic kommt über die fest zugewiesene öffentliche VM-IP. Lass Traefik per hostNetwork oder festem NodePort auf dem Worker laufen, der diese IP hält – kein VIP nötig, die öffentliche IP ist der Endpunkt. Single Point of Failure auf Node-Ebene, aber bei einem Single-Host-Server ist der Host ohnehin der limitierende Faktor.
• Provider-Floating-IP: Viele Provider bieten eine per API umhängbare IP. Das ersetzt das ARP-Failover: Statt dass ein Knoten die IP per ARP an sich reißt, hängt ein kleiner Controller sie per API um. Robuster als es klingt, aber providerspezifisch.
• Control-Plane-Endpoint: Bei einer Single-Control-Plane brauchst du gar keine VIP – der controlPlaneEndpoint zeigt auf die feste interne IP. Erst bei HA mit mehreren Control-Plane-Knoten führt der Weg wieder über Floating-IP oder einen vorgelagerten Provider-LB.
• Interne Service-IPs (hinter WireGuard): Hängen alle VMs auf einem Proxmox-Host an derselben internen Bridge (vmbr1), ist das ein echtes L2-Segment – dort darf kube-vip weiter ARP machen. Die interne Traefik-IP wird also im VM-Netz per ARP announciert und über WireGuard erreicht. Sobald die VMs über mehrere Hosts verteilt sind, fällt auch das weg.

Pragmatisch für den Single-Host-Server: öffentliche Dienste über die feste VM-IP via hostNetwork/NodePort, interne über kube-vip-ARP auf der internen Bridge. Minimaler Eingriff ins bestehende Setup. Die Calico-eBPF-Config (bpfExternalServiceMode: "Tunnel", kubeProxyReplacement: "Strict") läuft dabei unverändert weiter – das eBPF-Forwarding ist nicht das Problem, nur die IP-Beschaffung davor.

Noch ein Hinweis: cert-manager bekommt seinen ACME-Account erstmal im Staging-Modus, damit du beim Testen nicht gegen Let’s-Encrypt-Rate-Limits läufst.

Phase 4: Backup zuerst – Velero und Object Storage #

Diese Phase überspringt man nicht. Bevor Produktionsdaten auf den neuen Cluster wandern, muss ein funktionierender Restore-Test laufen – sonst migrierst du womöglich in eine kaputte Backup-Kette und merkst es zu spät.

1. Object Storage anlegen – einen S3-kompatiblen Bucket beim Provider, Größe nach Datenvolumen plus Retention.
2. Velero installieren – mit dem AWS-Plugin gegen den S3-Endpoint. Credentials via SOPS verschlüsselt im Git-Repo.
3. Testdaten sichern – kleine Test-App mit PVC deployen, velero backup create, prüfen, dass die Daten im Bucket landen.
4. Restore-Test auf demselben Cluster – Namespace löschen, velero restore create --from-backup ..., inklusive PVC-Inhalt verifizieren.
5. Cross-Cluster-Restore-Test – der eigentliche Punkt: ein aktuelles Homelab-Backup gegen den Cloud-Cluster einspielen. Erst wenn das klappt, weißt du, dass du im Ernstfall umziehen kannst. Guter Testkandidat: Paperless-ngx mit ein paar Test-Dokumenten.

Klappt der Cross-Cluster-Restore nicht, liegt es meist an nicht übereinstimmenden StorageClass-Namen oder an Reflector-Secrets, die auf bestimmte Namespaces gepinnt sind. In Ruhe debuggen – bevor es produktiv wird.

Phase 5: Dienste-Migration im Parallelbetrieb #

Die Anwendungen wandern einzeln, nach Kritikalität – erst die unwichtigen, dann die zentralen:

1. Paperless-ngx – kleiner Datenbestand, unkritisch. Perfekter erster Migrationskandidat.
2. Vaultwarden – heikel, aber überschaubar. Bleibt bewusst ohne SSO-Anbindung, weil der Passwort-Manager nicht vom Identity-Provider abhängen darf – beim Umzug braucht Vaultwarden also nur sich selbst, keine Kanidm-Abhängigkeit.
3. Kanidm – der Identity-Provider. Läuft er auf der Cloud-Seite, können SSO-abhängige Dienste nachziehen.
4. Immich – großes Datenvolumen, aber abgegrenzt. Hier lohnt ein Vorab-Sync der Foto-Bibliothek via rsync über WireGuard, damit das Velero-Restore nicht TB-weise durch den Tunnel schiebt.
5. Nextcloud – zuletzt, weil zentral. DB per Velero, Dateien liegen ohnehin im S3-kompatiblen Object Storage – die Migration betrifft also vor allem DB und Konfiguration.

Pro Dienst derselbe Ablauf: Homelab-Backup (velero backup create) → in die Cloud-Location verfügbar machen → Restore (velero restore create) → Funktionstest über WireGuard → kurze Read-only-Phase, finaler Delta-Sync, DNS-Umstellung.

Die DNS-Umstellung ist der Cutover-Moment. Vorher TTL der Einträge auf z. B. 300 Sekunden senken, damit der Schwenk schnell greift.

Phase 6: Public Exposure – Nextcloud und Immich auf 443 #

Vorab die Grundsatzfrage: Muss überhaupt etwas öffentlich sein? Die sicherste Variante ist, alles hinter WireGuard zu lassen – auch Nextcloud und Immich. Dann gibt es keine öffentliche Angriffsfläche, kein WAF-Thema, kein Brute-Force-Risiko, und diese Phase entfällt fast komplett. Der Preis: Jedes syncende Gerät braucht einen aktiven WireGuard-Tunnel – für eigene Geräte unkritisch, aber sobald Familienmitglieder oder geteilte Links ins Spiel kommen (Foto-Freigaben, Nextcloud-Shares an Externe), wird es unpraktikabel. Wer damit leben kann, fährt mit dem reinen VPN-Ansatz entspannter. Der Rest dieser Phase beschreibt den Fall, dass Nextcloud und Immich öffentlich erreichbar sein sollen.

1. DNS-Einträge – nextcloud.deine-domain.de und immich.deine-domain.de auf die öffentliche Server-IP. Der Rest (grafana.*, paperless.*, vaultwarden.*, proxmox.*) zeigt auf interne IPs, nur über WireGuard erreichbar. Das reduziert die Angriffsfläche drastisch – von außen sieht ein Angreifer nicht mal, dass diese Dienste existieren.
2. Traefik-IngressRoutes – die beiden öffentlichen Dienste laufen über den öffentlichen Pfad (feste VM-IP via hostNetwork/NodePort, siehe Phase 3), alle anderen über den internen Pfad, erreichbar nur aus dem VM-Netz und damit per WireGuard.
3. cert-manager auf Produktion umstellen – ACME-Account von Staging auf Production, Zertifikate werden ausgestellt.
4. Security-Hardening für die öffentlichen Routen:
   • Rate-Limiting (Traefik-Middleware)
   • Fail2ban auf den App-Logs (Nextcloud hat brauchbare Brute-Force-Erkennung eingebaut)
   • HSTS und sichere Security-Header (Traefik-Middleware)
   • CrowdSec oder modsecurity als WAF-Layer (optional, aber bei öffentlichem Nextcloud sinnvoll)
   • 2FA verpflichtend für alle Nextcloud-Nutzer
   • Regelmäßige Updates – Nextcloud ist ein populäres Ziel; zeitnahes Patchen ist Pflicht.

Phase 7: Cutover und Rollback #

Der eigentliche Umzug ist am Ende nur noch DNS – aber ein paar Dinge müssen sitzen.

Cutover-Checkliste:

• Alle Dienste in der Cloud laufen und sind per WireGuard erreichbar
• Nextcloud und Immich über Test-Subdomains (nc-new.*, immich-new.*) erreichbar und funktional
• Velero-Backup-Jobs laufen in der Cloud, Restore-Test war erfolgreich
• Monitoring zeigt beide Cluster parallel
• DNS-TTL auf Minuten-Werte reduziert
• Nutzer sind vorgewarnt (Wartungsfenster)

Cutover-Ablauf: betroffene Dienste im Homelab in Read-only/Wartung → finaler Delta-Sync (DBs, Object Storage) → DNS auf die Cloud umschalten → Funktionstests (Login, Datei-Upload, Sync-Clients) → Homelab-Dienste nicht sofort löschen.

Rollback: Geht etwas Grundlegendes schief, DNS zurück aufs Homelab – dort läuft alles noch. Genau dafür ist der Parallelbetrieb da. Erst nach einer Karenzzeit (7–14 Tage ohne Probleme) werden die Homelab-Dienste abgeschaltet.

Was nach dem Umzug bleibt #

Das Homelab muss nicht weg – es eignet sich als Offsite-Backup-Ziel für den Cloud-Stack: Velero sichert aufs Object Storage, ein zweiter Job zusätzlich Richtung Homelab. Das ist echtes 3-2-1 (drei Kopien, zwei Medien, eine offsite), für den überschaubaren Preis eines weiterlaufenden Homelab-NAS. Umgekehrt dient der Cloud-Stack als DR-Site für künftige Homelab-Installationen – GitOps macht daraus einen Inventory-Wechsel, keinen Neubau.

Fazit #

Der Umzug ist kein Hexenwerk, wenn die Architektur hardware-agnostisch gedacht ist. Vier Dinge zählen wirklich:

1. WireGuard zuerst – Zugang muss unabhängig vom Cluster funktionieren.
2. VIP-Strategie anpassen – kube-vip-ARP läuft in der Cloud nicht; öffentliche Dienste an die feste VM-IP, interne ggf. weiter per ARP auf der internen Bridge.
3. Backup vor Migration – Cross-Cluster-Restore testen, bevor Produktionsdaten wandern.
4. Parallelbetrieb statt Big Bang – kein Zeitdruck, jederzeit Rollback möglich.

Und die Grundsatzentscheidung am Anfang: Wer keine öffentlichen Shares braucht, lässt einfach alles hinter WireGuard und spart sich Phase 6 fast komplett. Alles andere ist Routine – Ansible gegen neues Inventory, Flux CD pflanzt den gewohnten Stack, Velero kümmert sich um den Datentransport. Die Dienste merken vom Umzug nichts – und die Nutzer idealerweise auch nicht.

Im nächsten Post: wie sich Cloud-Stack und Homelab gegenseitig absichern – als beidseitiges Offsite-Backup mit automatischem Failover.

Dieser Artikel erschien zuerst auf LinkedIn. Gedanken dazu, Fragen oder eigene Erfahrungen mit digitaler Souveränität — ich freue mich auf die Diskussion: