Mein Homelab: 25 Dienste, sechs Hosts und kein einziger Handgriff auf dem Server

Beruflich betreue ich rund 60 Linux-Server und zwei HA-Kubernetes-Cluster. Privat läuft bei mir zu Hause eine deutlich kleinere Infrastruktur, die sich für ein Homelab aber trotzdem sehen lassen kann. Ich habe 4 Server, etwa 25 Docker-Dienste, ein VPN und ein Ansible-Projekt, das alles zusammenhält.

Ich werde immer wieder gefragt, wozu man privat so etwas braucht. Die kurze Antwort: weil ich meine Daten selbst in der Hand haben will und weil ein Homelab der ehrlichste Übungsplatz ist, den man bekommen kann. Wenn etwas kaputtgeht, gibt es keinen Kollegen, der es repariert. Die lange Antwort ist dieser Artikel.

Die Topologie

Fangen wir mit dem an, was man anfassen kann. Wer bei „Homelab“ an ein Rack im Keller denkt, wird bei mir enttäuscht: Hier stehen drei kleine Rechner und ein NAS, zusammen kaum größer als ein Schuhkarton.

• Ein Geekom Mini Air12 als stärkste Maschine
• Zwei ZimaBoards (Gen 1 und Gen 2), beide komplett lüfterlos, wobei die zweite Generation der ersten leistungsmäßig deutlich davonzieht, ohne nennenswert mehr Strom zu brauchen
• Ein Ugreen DXP2800 als NAS

Das ist eine bewusste Entscheidung. Das Ganze läuft rund um die Uhr, niedriger Stromverbrauch war deshalb das wichtigste Auswahlkriterium, noch vor der Rechenleistung. Ausgemusterte Server-Hardware bekommt man günstig hinterhergeworfen, aber man bezahlt sie zwölf Monate im Jahr über die Stromrechnung nach. Der angenehme Nebeneffekt der kleinen, teils lüfterlosen Geräte: Man hört das Homelab nicht. Es steht nicht im Keller, sondern einfach da, wo Platz ist.

Auf zwei der drei Rechner, dem Geekom und dem neueren ZimaBoard, läuft Proxmox. Zu einem Cluster habe ich die beiden bewusst nicht zusammengeschaltet, sie arbeiten eigenständig. Zum einen sollten die Nodes in einem Cluster halbwegs gleich dimensioniert sein, und das sind die beiden Maschinen nicht. Zum anderen müsste ich auf beiden Kapazität freihalten, damit im Ernstfall die eine die Dienste der anderen übernehmen kann. Hochverfügbarkeit ist zu Hause aber keine Anforderung, und dafür Rechenleistung brachliegen zu lassen, sehe ich nicht ein. Fällt eine Maschine aus, fehlen mir die Dienste darauf, bis ich sie wieder hochbekomme. Damit kann ich leben. Das erste ZimaBoard braucht diese Ebene gar nicht, dort läuft Docker direkt auf dem Betriebssystem.

Auf den beiden Proxmox-Nodes laufen LXC-Container statt vollwertiger VMs, auf jedem Node einer. Für Dienste, die am Ende sowieso nur Docker starten, ist eine komplette VM Verschwendung, und gerade bei dieser Hardwareklasse zählt jedes eingesparte Gigabyte RAM. Docker in LXC ist nicht die Variante, die alle empfehlen, bei mir läuft es aber so, seit ich Proxmox einsetze. Angefangen habe ich mit Ubuntu in den Containern, inzwischen steckt in beiden NixOS, weil ich es lieber deklarativ mag.

Die sechs Hosts verteilen sich auf zwei Betriebssystem-Welten: vier Debian-Systeme und die beiden NixOS-Container. Interessant ist die Mischung: Die beiden NixOS-Container sind bei sich selbst schon vollständig deklarativ, Betriebssystem, Pakete und Firewall liegen in einem Git-Repo. Ansible kümmert sich dort nicht um das System, sondern nur um die Ebene darüber, also die Docker-Workloads. Bei den Debian-Hosts macht Ansible etwas mehr. NixOS macht das, was NixOS besser kann, Ansible den Rest.

Ein Detail, das mir wichtig ist: Die drei Hosts, auf denen Docker-Dienste laufen, bilden eine eigene Inventory-Gruppe, die die Betriebssystem-Gruppen absichtlich kreuzt. Dienste landen dort, wo Platz und Ressourcen sind, nicht dort, wo ein bestimmtes Betriebssystem läuft.

Was da eigentlich läuft

Etwa 25 Dienste, alle als Docker-Compose-Stacks. Die interessantesten:

Infrastruktur und Zugriff

• Forgejo – meine eigene Git-Forge inklusive Container-Registry. Meine selbstgebauten Images liegen dort und werden direkt von da auf die Hosts gezogen. Kein Docker Hub, kein Rate-Limit, keine fremde Abhängigkeit.
• nginx-proxy-manager – terminiert TLS und legt jeden Dienst unter einem eigenen Hostnamen im internen Netz ab. Die Zertifikate kommen von Let’s Encrypt und werden automatisch erneuert. Weil von außen nichts erreichbar ist, kann die Validierung dabei nicht über einen HTTP-Request laufen. Stattdessen nutze ich die DNS-01-Challenge: Let’s Encrypt prüft einen Eintrag in meiner Zone, die bei Hetzner liegt, und weiß damit, dass die Domain wirklich mir gehört.
• Uptime Kuma und Beszel – Erreichbarkeits- und Host-Monitoring. Beszel läuft mit einem Agenten auf jedem Host.
• ntfy – Push-Benachrichtigungen aufs Handy. Backups, Monitoring und n8n-Workflows melden sich alle dort.

Meine Daten

• Seafile für Dateisynchronisation, Paperless-ngx für den kompletten Papierkram, Vaultwarden als Passwortmanager, Readeck als Read-it-later-Archiv, Vikunja für Aufgaben, dazu WebDAV und RustFS als S3-kompatibler Objektspeicher.

Automatisierung und KI

• n8n für Workflows, unter anderem läuft darüber ein selbstgebautes Code-Review für meine Merge-Requests.
• llama.cpp als CPU-only-Inferenzserver. Genutzt wird der vor allem von HowCanI, meiner eigenen Wissensdatenbank: Sie erzeugt darüber die Embeddings für ihre KI-gestützte Volltextsuche. Statt nur nach Wortübereinstimmungen zu suchen, findet die damit auch Einträge, die dasselbe meinen, aber ganz anders formuliert sind. Das Modell läuft komplett lokal, es verlässt also keine einzige Zeile das Haus.
• Hermes Agent bringt sein eigenes OpenAI-kompatibles Gateway mit und erledigt bei mir unbeaufsichtigt die Aufgaben, die sich schlecht als fester n8n-Workflow abbilden lassen. Ein Workflow ist gut, solange die Schritte von vornherein feststehen. Sobald die Aufgabe eher lautet „sieh dir das an und entscheide“, ist ein Agent das passendere Werkzeug.

Kleinkram, der überraschend oft nützlich ist

• it-tools, Stirling PDF, MicroBin, MeTube. Alles kleine, nette Helferlein, die ich lieber selbst hoste, damit meine Daten in meinem Netzwerk bleiben.

Und schließlich meine eigenen Projekte: das eben erwähnte HowCanI und ein Worktime-Logger, beide in Bun geschrieben, beide als Image in der eigenen Registry.

Ein WLAN für alles reicht nicht

Angefangen hat das mit dem Umzug in meine jetzige Wohnung. Seitdem ist die Zahl der IoT-Geräte im Netz Stück für Stück gewachsen, inzwischen sind es über zwanzig: Steckdosen, Sensoren, Lampen, Lautsprecher. Über die Sicherheit dieser Geräteklasse gibt es genug Berichte, und die fallen alle ähnlich aus: Die Firmware wird selten gepatcht, oft nie, und einsehen kann man sie ohnehin nicht. Solche Geräte im selben Netz zu haben wie meinen Arbeitsrechner und meinen Passwortmanager, wollte ich nicht.

Genau das ist übrigens der häufigste Fehler im Heimnetz, und er passiert nicht an der Firewall nach draußen, sondern innen: Alles hängt in einem einzigen flachen Netz. Die smarte Steckdose mit ihrer Firmware von 2019 steht dann im selben Segment wie der Rechner, auf dem man arbeitet.

Die Fritzbox kann keine VLANs. Ich habe deshalb eine ganze Weile überlegt, welche Hardware das übernehmen soll, und bin bei einem UniFi-Router von Ubiquiti gelandet. Die Fritzbox ist seitdem nur noch das Modem am Kabelanschluss, die eigentliche Netzwerkarbeit macht der UniFi dahinter. Darauf laufen drei getrennte WLANs, jedes auf einem eigenen VLAN:

• Office: die Geräte, mit denen ich tatsächlich arbeite.
• IoT: Smart-Home-Geräte und Sensoren.
• Sonstige Geräte: alles, was ins Internet darf, aber im Arbeitsnetz nichts verloren hat.

Die Regel zwischen den Segmenten ist bewusst einfach gehalten: IoT darf ins Internet, aber nicht ins Office-Netz. Die Isolation gilt also nur in eine Richtung, und das reicht völlig. Entscheidend ist dabei weniger die Anzahl der Netze als die Annahme dahinter: Ich gehe davon aus, dass IoT-Geräte kompromittiert sind. Nicht, weil ich weiß, dass sie es sind, sondern weil ich es nicht ausschließen kann. Ein übernommenes Gerät soll dann keinen Weg zu den Diensten finden, in denen meine Dokumente und Passwörter liegen.

Interessant daran: VLANs hatte ich vorher noch nie eingerichtet. Beruflich brauchte ich das nie, gelernt habe ich es also nirgends. Ich habe es mir für das Homelab angeeignet und hier zum ersten Mal angewendet, und es hat auf Anhieb funktioniert. Genau dafür ist so ein Lab da: Dinge ausprobieren, die gerade nicht auf dem Schreibtisch liegen, aber trotzdem zum Handwerkszeug eines Administrators gehören. Gedauert hat vor allem die Entscheidung, welcher Router es werden soll. Die Einrichtung im Controller war dann an einem Abend erledigt und kostet mich seitdem nichts mehr.

Im Alltag merke ich von der Trennung fast nichts. Die Geräte sind bei Alexa und Google Home registriert, gesteuert wird also über deren Apps, und die brauchen keine direkte Verbindung ins IoT-Netz. Einzig zum Einrichten eines neuen Geräts muss ich mit Tablet oder Handy kurz ins IoT-WLAN wechseln.

Dass ausgerechnet die Smart-Home-Steuerung damit über zwei fremde Clouds läuft, während ich Dokumente und Passwörter selbst hoste, ist ein Widerspruch. Den gehe ich bewusst ein. Eine selbst gehostete Lösung würde die Sprachsteuerung kosten, und einfach „Alexa, mach das Licht aus“ sagen zu können, will hier niemand mehr missen, meine Frau am allerwenigsten.

Gemessen am Aufwand ist das die wirksamste Maßnahme in Bezug auf Sicherheit im ganzen Homelab.

Zugriff von außen: das VPN

Der wichtigste Punkt vorweg: Kein einziger Dienst meines Homelabs ist aus dem Internet erreichbar. Nach außen offen ist genau ein UDP-Port, der WireGuard-Endpunkt. Alles andere geht ausschließlich durch den Tunnel. Ein Dienst, der nicht öffentlich erreichbar ist, kann auch nicht von außen angegriffen werden, und Komfort kostet das praktisch keinen: Der Tunnel steht auf allen Geräten mit zwei Klicks.

Dafür braucht es erstaunlich wenig. Keinen Cloud-Reverse-Proxy, keinen VPS als Sprungbrett, keinen Tunnel-Dienst eines Drittanbieters, dem ich meinen Datenverkehr anvertrauen müsste. Drei Bausteine, von denen zwei sowieso schon im Haus stehen:

Der VPN-Server steckt im Router. Ich benutze einen Ubiquiti UniFi Express, und der bringt einen WireGuard-Server von Haus aus mit. Kein zusätzlicher Container, kein Dienst, den ich selbst patchen und überwachen muss. Für mich der eigentliche Vorteil: Der Fernzugriff hängt damit an keinem der Hosts, die ich per Ansible umbaue. Ich kann das komplette Homelab durchprovisionieren, ohne mir dabei den Weg nach draußen abzusägen.

Ein DynDNS-Name statt einer festen IP. Mein Vodafone-Anschluss hat eine echte, öffentliche IPv4-Adresse, aber keine statische. Damit die Clients trotzdem immer wissen, wohin sie sich verbinden sollen, läuft die Adresse bei ipv64.net auf einen festen Hostnamen. Ein deutscher DynDNS-Dienst, der genau das tut, was man an einem Privatanschluss braucht, inklusive automatischer Wildcard-Records und einer TTL, die kurz genug ist, dass ein Adresswechsel nicht wehtut.

Eine einzige Portfreigabe. Die Fritzbox reicht genau eine Freigabe weiter, den WireGuard-Port per UDP an den UniFi, der den Tunnel terminiert. Die Angriffsfläche ist damit ein einzelner UDP-Port, der auf ein falsches Paket nicht einmal antwortet. Das ist einer der Gründe, warum ich WireGuard einem offengelegten Reverse-Proxy vorziehe: Ein Port-Scan von außen sieht dort schlicht nichts.

Vom Notebook, Tablet und Handy komme ich damit an alles: Paperless, Seafile, Vaultwarden, Vikunja und eben auch an meine eigenen Anwendungen wie HowCanI, genau so, als wäre ich zu Hause im Netz. Der Datenverkehr läuft dabei über keinen fremden Server. Der einzige externe Dienst in der Kette ist der DynDNS-Anbieter, und der kennt nichts weiter als meine jeweils aktuelle IP-Adresse.

Eine Ausnahme gibt es: diese Homepage hier. Die soll ja jeder erreichen können, und sie läuft deshalb bewusst nicht im Homelab, sondern als statische Seite auf GitHub Pages. Öffentlich ist, was statisch und harmlos ist. Alles, wo Daten drinstecken, liegt zu Hause hinter dem Tunnel.

Alles ist Code: das Ansible-Projekt

Angefangen hat das nicht als Konzept, sondern aus Ärger. Solange nur ein Server mit ein paar Diensten lief, reichte eine Handvoll Compose-Dateien in einem Git-Repo völlig aus. Mit jedem weiteren Server kamen Kopien dazu, und irgendwann pflegte ich dieselbe Konfiguration an mehreren Stellen parallel und musste sie überall einzeln aktuell halten. Noch mehr gestört hat mich die Mischung: teils automatisiert deployt, teils zwischendurch von Hand auf dem Host geändert. Beruflich wäre mir das nicht durchgegangen, privat habe ich es mir eine Weile erlaubt.

Seitdem gilt bei mir eine Regel, an die ich mich ziemlich streng halte: Nichts wird auf dem Host manuell konfiguriert. Alles liegt in einem einzigen Ansible-Projekt, und der Alltag besteht aus genau einem Kommando:

./provision.sh                       # alles, auf allen Hosts
./provision.sh -t paperless-ngx      # nur diesen einen Dienst
./provision.sh -l nixos --check      # Dry-Run auf einer Gruppe

Wie das intern aufgebaut ist, füllt einen eigenen Artikel: eine generische Rolle für alle 25 Dienste statt 25 einzelner, verschlüsselte Secrets neben dem jeweiligen Dienst, und die Frage, wie ein einzelner Host eine Einstellung überschreibt, ohne dass die Konfiguration doppelt gepflegt wird. Den Deep Dive gibt es deshalb separat: 25 Docker-Dienste, eine Ansible-Rolle.

Backup: zwei Stufen, zwei Orte

Ein Homelab ist erst dann eines, wenn man es wiederherstellen kann. Alles bisher Beschriebene, die Provisionierung, die Netztrennung, der Tunnel, schützt gegen Ausfall und Angriff. Gegen die wahrscheinlichsten Katastrophen, nämlich eine sterbende Platte, ein versehentliches rm oder einen Verschlüsselungstrojaner, hilft nur eines. Deshalb ist Backup für mich der wichtigste Teil des ganzen Setups.

Mein Konzept hat zwei Stufen:

Stufe 1: alles auf das NAS. Jeder Server sichert seinen Stand einmal täglich auf das NAS, meine Arbeitsrechner tun das stündlich. Das läuft über rsync, angestoßen von systemd-Timern, und die kommen passend zum Rest dieses Artikels aus der cron_jobs-Rolle im Ansible-Repository. Damit ein Host seinen Backup-Timer bekommt, gebe ich ihm in seinen Host-Variablen ein paar Zeilen YAML. Von Hand eingerichtet wird da nichts.

Stufe 2: das komplette NAS in die Cloud. Einmal täglich sichert sich das NAS als Ganzes mit BorgBackup in eine Storage Box bei Hetzner. Borg ist für diesen Zweck fast ideal: Es dedupliziert auf Blockebene, überträgt also nur das, was sich tatsächlich geändert hat, und es verschlüsselt clientseitig. Beim Hoster liegt damit ein Datenhaufen, mit dem niemand etwas anfangen kann, der Schlüssel verlässt mein Haus nie.

Damit liegen alle meine Daten immer an zwei voneinander unabhängigen Orten, und der zweite ist außer Haus. Ein Wasserschaden oder ein Einbruch nimmt mir zwar die Hardware, aber nicht die Daten.

Wichtig ist dabei die Aufbewahrung, denn ein Backup, das nur den letzten Stand kennt, repliziert einen Fehler bloß zuverlässig. Deshalb dünnt Borg die Archive gestaffelt aus:

• Jeden Tag ein Backup, sieben Tage lang
• Ein Backup pro Woche, vier Wochen lang
• Ein Backup pro Monat, drei Monate lang

Ein Datenverlust, den ich erst nach zwei Wochen bemerke, die gelöschte Datei oder das kaputt migrierte Postfach, ist damit immer noch reparabel. Zusätzlich prüft Borg regelmäßig auf Integrität: wöchentlich das Repository selbst, monatlich die Archive.

Zurückgeholt habe ich aus diesem Backup auch schon etwas. Einmal bewusst als Test, weil ich wissen wollte, ob ich an ein Archiv bei Hetzner im Ernstfall überhaupt wieder herankomme, und einmal, weil ich tatsächlich etwas daraus gebraucht habe. Beides hat funktioniert. Das ist mir wichtig, denn ein Backup, das man noch nie zurückgespielt hat, ist nur eine Vermutung.

Was ehrlich noch fehlt

Ich mag es nicht, wenn solche Artikel nur die Hochglanzversion zeigen, also hier die offenen Punkte:

• Der Host selbst wird noch nicht provisioniert. Ansible stellt die Dienste wieder her, das Betriebssystem darunter setze ich weiterhin von Hand auf. Bei den beiden NixOS-Containern ist das kein Thema, die beschreiben sich ohnehin selbst. Für die Debian-Hosts wäre es der logische nächste Schritt.
• Der Restore-Test läuft nicht automatisch. Beruflich habe ich das anders gelöst: Dort wird jede Nacht ein Backup eingelesen und der Restore einzelner Dateien automatisch verifiziert. Zu Hause teste ich von Hand. Das hat bisher jedes Mal funktioniert, mein Leidensdruck hält sich also in Grenzen. Trotzdem sollte auch privat mein Anspruch sein, das automatisch prüfen zu lassen und nicht darauf zu vertrauen, dass ich rechtzeitig daran denke.
• Einige Images laufen auf latest. Bei Paperless ist mir das gerade auf die Füße gefallen: Der Sprung auf Version 3 ließ sich nicht einfach so einspielen. Mit einem gepinnten Tag hätte ich selbst bestimmt, wann ich mich damit beschäftige, statt es vorgesetzt zu bekommen. Ich pinne inzwischen dort, wo es wehtun würde, aber noch nicht überall.

Fazit

Wenn mich jemand fragt, was an diesem Setup das Wertvollste ist, dann ist es weder die Anzahl der Dienste noch die Hardware. Es ist, dass ich die Dienste eines Hosts auf einer anderen Maschine mit einem Kommando wieder genauso hinbekomme, wie sie vorher konfiguriert waren, ohne mich erinnern zu müssen, wie ich das damals eingerichtet habe. Die Daten kommen separat aus dem Backup dazu. Das macht den Unterschied zwischen einem Homelab, das man pflegt, und einem, vor dem man Angst hat.

Der Nebeneffekt ist nicht zu unterschätzen: Fast alles, was ich hier privat ausprobiere, Ansible-Patterns, deklarative Konfiguration, ein selbst gehosteter Registry-Workflow, wandert früher oder später in abgewandelter Form in meine Arbeit. Und was ich beruflich bisher nicht brauchte, wie die VLAN-Trennung oben, lerne ich hier trotzdem, weil es zum Handwerkszeug gehört. Ein Homelab ist die günstigste Weiterbildung, die man bekommen kann.