Das Homelab in einem Bild

Ich sitze im Zug, und mir fällt der Brief ein, der gestern gekommen ist. Was stand da noch mal drin? Ich tippe paperless.home.example ins Handy, und eine Sekunde später ist er da, eingescannt und mit Absender und Datum versehen.

Das klingt nach etwas, das jede Cloud-App auch kann. Der Unterschied ist, wo der Brief liegt. Er liegt auf einem Rechner bei mir zu Hause. Und mein Router, das Kästchen, das mein Zuhause mit dem Internet verbindet, lässt von außen niemanden herein. Es gibt dort keine einzige offene Tür, im Fachjargon keinen offenen Port. Wie kommt die Anfrage aus dem Zug dann überhaupt an? Und was passiert, wenn der Rechner heute Nacht kaputtgeht?

Um diese Fragen geht es in dieser Serie. Dieser erste Teil ist der Einstieg, auch für dich, wenn du so etwas noch nie gebaut hast. Wir fangen deshalb ganz vorne an.

Was ist eigentlich ein Homelab?

Die meisten Programme, die wir täglich benutzen, laufen nicht auf unserem eigenen Gerät. Fotos landen bei Google oder Apple, Dateien bei Dropbox. Dort stehen Rechner, die rund um die Uhr laufen und auf Anfragen warten. So einen Rechner nennt man Server, und ein Programm, das darauf läuft und das man über Browser oder App benutzt, nennt man einen Dienst.

Ein Homelab ist dasselbe in klein, zu Hause: ein paar Rechner, auf denen die eigenen Dienste laufen, etwa ein eigenes Fotoalbum oder ein eigenes Archiv für Briefe. Man entscheidet dann selbst, wo die eigenen Daten liegen und wer sie sehen darf. Der Preis ist, dass man sich auch selbst kümmern muss, um Updates, um Sicherungen und darum, dass nachts nichts ausfällt. Genau dieses Kümmern ist der eigentliche Stoff dieser Serie.

Warum ich umgebaut habe

Bis September 2026 liefen meine Dienste als lose Sammlung auf meinem Arbeitsplatzrechner, also dem Rechner, an dem ich auch sonst sitze. Das geht erstaunlich lange gut. Bis man ihn neu startet und mit ihm die Namensauflösung fürs Heimnetz, das Dokumentenarchiv und die Dateiablage verschwinden.

Beim Umbau wollte ich es ordentlich machen, und was „ordentlich“ heißt, musste ich erst einmal aufschreiben. Herausgekommen sind vier Ziele, an denen sich seitdem jede Entscheidung messen lassen muss.

Vier Teile, ein Haus

Was aus diesen Zielen geworden ist, stelle ich mir als Haus vor. Ganz unten liegt das Fundament, die Hardware. Darauf wohnen die Dienste. Damit ich sie von unterwegs erreiche und sonst niemand, gibt es Netz & Zugriff, sozusagen Haustür, Klingelschild und Empfang. Und daneben steht der Betrieb, eine Art Hausmeister, der alles nach Bauplan errichtet, jede Nacht sichert und mich warnt, wenn etwas fehlt. Die Karte zeigt diese vier Teile. Sie taucht in jedem Teil der Serie wieder auf, damit du weißt, wo wir gerade sind.

Schauen wir uns zuerst die beiden unteren Teile an, weil alles andere darauf aufbaut.

Das Fundament: ein Rechner, viele VMs

Das ganze Haus steht auf einem einzigen Rechner, ich nenne ihn pve1. Die Hardware ist bescheidener, als man vielleicht erwartet: ein AMD Ryzen 9 4900H, also ein Notebook-Prozessor mit 16 Threads, und 62 GB Arbeitsspeicher.

Darauf läuft Proxmox VE, eine Software, die einen echten Rechner in viele kleine, voneinander abgeschottete Rechner aufteilt. Jeder dieser Rechner im Rechner heißt virtuelle Maschine, kurz VM. Man kann sich das wie ein Mehrfamilienhaus vorstellen. Jede VM ist eine eigene Wohnung mit eigener Tür und eigenem Betriebssystem, und wenn es in einer brennt, bleiben die anderen trocken.

Das ist das zweite Ziel von oben. Jeder Dienst bekommt seine eigene VM mit Debian 13, einem freien Linux-Betriebssystem. Insgesamt laufen auf pve1 17 VMs. Die meisten sind Dienst-VMs aus demselben Bauplan, dazu kommen ältere Maschinen, etwa eine Dateiablage mit TrueNAS und die Haussteuerung Home Assistant. Ganz umsonst ist die Trennung nicht, denn jede VM braucht ihren eigenen Arbeitsspeicher. Bei 1 bis 8 GB pro VM nehme ich das gern in Kauf.

Die VMs benenne ich nach ihrem Dienst und hänge eine Nummer an. Die VM für Paperless heißt also paperless-01.

Die Dienste

In den Wohnungen leben die Programme, die ich tatsächlich benutze. Paperless-ngx ist mein Archiv für eingescannte Briefe, also der Dienst aus dem Zug. Nextcloud ist meine eigene Dateiablage, ähnlich wie Dropbox, und Immich mein eigenes Fotoalbum, ähnlich wie Google Fotos. Mit n8n baue ich Automatisierungen nach dem Muster „wenn das passiert, tu jenes“. Und Open WebUI ist ein Chatfenster für ein Sprachmodell, das bei mir zu Hause läuft.

So weit das Haus. Der Kern der Geschichte vom Anfang ist aber, wie mein Handy im Zug die Dienste überhaupt findet. Dafür gehen wir jetzt zweimal hindurch, einmal mit der Anfrage aus dem Zug und einmal mit einer Änderung vom Schreibtisch.

Ein privater Tunnel nach Hause

Mein Handy hängt im Mobilfunk, pve1 steht hinter dem Router, und dazwischen liegt das Internet. Weil der Router keine Tür öffnet, braucht es einen anderen Weg hinein.

Dieser Weg heißt NetBird. NetBird legt ein privates Netz über das Internet, ein sogenanntes Overlay-Netz. Man kann es sich wie ein Netz privater Tunnel vorstellen, durch die nur meine eigenen Geräte fahren dürfen. Die Tunnel baut eine Technik namens WireGuard, und sie sind verschlüsselt. Wer unterwegs mitschaut, sieht nur Zeichensalat. Jedes Gerät in diesem Netz heißt Peer, mein Handy genauso wie jede Dienst-VM.

Damit sich die Peers finden, gibt es einen Vermittler, den NetBird-Server. Er steht auf einem kleinen gemieteten Server beim Hosting-Anbieter Hetzner. Er sagt jedem Peer, wen er erreichen darf, aber die Daten selbst fließen nie über ihn. Die Tunnel bauen beide Seiten von innen nach außen auf, und deshalb muss der Router zu Hause keine Tür öffnen.

Vom Namen zur Seite

Das Handy ist jetzt im privaten Netz. Mit paperless.home.example kann es aber noch nichts anfangen, denn im Netz finden sich Rechner über Nummern, nicht über Namen. Das Bild zeigt den ganzen Weg vom Namen bis zur fertigen Seite. Oben stehen die Beteiligten, und die Pfeile folgen der Zeit von oben nach unten.

Der erste Pfeil kommt vom NetBird-Server. Er sagt dem Handy auch, wen es nach Namen fragen soll. Das übernimmt ein DNS-Server, das Telefonbuch des Netzes, das zu jedem Namen die passende Nummer kennt. Bei mir ist das AdGuard Home in einer eigenen VM namens dns-01, mit einer Kopie auf einem Raspberry Pi als Reserve.

Einen eigenen Eintrag für Paperless hat AdGuard gar nicht. Es kennt nur eine Platzhalter-Regel, eine sogenannte Wildcard, nach der jeder Name, der auf .home.example endet, zur selben Adresse führt. Dort steht der Reverse Proxy, kurz Proxy. Er arbeitet wie der Empfang in einem Bürohaus, nimmt jede Anfrage entgegen, liest am Namen ab, zu welchem Dienst sie will, und bringt sie dorthin. Er wohnt in der VM proxy-01. Weil alle Namen zum Proxy führen, braucht ein neuer Dienst keinen neuen Eintrag im Telefonbuch.

Jetzt baut das Handy durch den WireGuard-Tunnel eine Verbindung zum Proxy auf, per HTTPS, der verschlüsselten Sprache von Webseiten, die man am Schloss im Browser erkennt. Der Proxy zeigt dabei ein Zertifikat vor, eine Art Ausweis, der dem Browser beweist, dass er mit dem richtigen Server spricht. Wie man so einen Ausweis bekommt, obwohl niemand von außen an die Tür klopfen kann, erzähle ich in Teil 2.

Zum Schluss reicht der Proxy die Anfrage an paperless-01 weiter, ebenfalls durch einen WireGuard-Tunnel, obwohl beide VMs auf demselben Rechner stehen. Meine Frage aus dem Zug berührt also genau drei VMs, und keine davon hat eine offene Tür ins Internet.

Vom Schreibtisch zur laufenden VM

Der zweite Weg beginnt am Schreibtisch. Angenommen, ich will einen neuen Dienst ausprobieren. Statt eine VM von Hand zusammenzuklicken, schreibe ich eine kurze Textdatei, eine Art Bauplan, mit Name, Prozessorkernen, Arbeitsspeicher und Plattengröße der VM.

Die Datei landet in einem Repository, kurz Repo, einem Ordner, der sich jede Änderung merkt. Bei mir liegt er bei GitLab. Sobald ich eine Änderung hochlade, im Jargon ein git push, startet eine Pipeline. Das ist ein Fließband aus festen Arbeitsschritten, das bei jeder Änderung von selbst losläuft. Das Bild zeigt dieses Fließband von oben nach unten, bis in die erste Nacht.

Das Fließband läuft auf einem Runner, der Maschine, die die Arbeitsschritte ausführt. Mein Runner ist selbst eine VM auf pve1 und fragt GitLab von sich aus nach Arbeit, also muss auch dafür keine Tür offen sein. Zuerst prüft er die Dateien, und das Prüfprogramm gitleaks sucht nach Passwörtern, die versehentlich hineingeraten sind.

Danach vergleicht OpenTofu, ein Werkzeug für genau solche Baupläne, die Datei mit dem, was auf pve1 tatsächlich läuft, und schreibt einen Plan, was neu entsteht, was sich ändert und was verschwindet. Hier bleibe ich mit Absicht hängen und lese. Steht bei einer bestehenden VM „must be replaced“, soll sie also ersetzt werden, ist etwas faul, und ich drücke den Knopf nicht.

Drücke ich ihn, setzt OpenTofu genau den gelesenen Plan um, und Proxmox legt aus einem fertigen Debian-Abbild eine neue VM an. Beim ersten Start bekommt sie über das Startprogramm cloud-init nur das Nötigste, einen Namen, einen Benutzer und einen Schlüssel für SSH, den verschlüsselten Fernzugang. Nach etwa 30 Sekunden ist sie erreichbar.

Eine leere VM ist wie eine frisch gestrichene Wohnung ohne Möbel. Das Einrichten übernimmt Ansible, ein Werkzeug, das sich per SSH anmeldet und eine Checkliste abarbeitet. Es spielt Updates ein, lässt die VM NetBird beitreten, richtet die Zeitpläne für Sicherung und Update ein und installiert Docker. Docker packt ein Programm samt allem, was es braucht, in eine abgeschlossene Kiste, einen Container, und darin läuft am Ende der Dienst. Seine Passwörter kommen per SSH in eine .env-Datei auf der VM, ins Repo gelangen sie nie.

Zum Schluss bekommt der Dienst einen Eintrag im Proxy, und Uptime Kuma, mein Wächter, der regelmäßig nachsieht, ob alle Dienste antworten, bekommt einen neuen Posten. Ab da ist der Dienst unter seinem Namen erreichbar, auch aus dem Zug.

Aus der Praxis: Dass der Runner selbst auf einer der VMs läuft, die er verwaltet, hat sich schon am Umzugstag bemerkbar gemacht. Ein Durchlauf, der nur eine harmlose Einstellung ändern sollte, startete mehrere VMs neu, darunter den Runner, auf dem er gerade lief. Was danach passierte und welche Zeile seitdem in jedem Bauplan steht, erzähle ich in Teil 5.

Die erste Nacht

Bleibt die zweite Frage vom Anfang, was passiert, wenn pve1 heute Nacht kaputtgeht. Dann helfen nur Sicherungen, die außer Haus liegen. Dafür miete ich bei Hetzner zweierlei. Auf einem zweiten kleinen Server läuft der Proxmox Backup Server, ein Programm, das ganze VMs sichert. Dazu kommt Object Storage, ein Online-Speicher wie eine Lagerhalle mit Schließfächern, die man Buckets nennt. Nach der Sprache, mit der man ihn anspricht, heißt so ein Speicher meist einfach S3.

Drei Sicherungen laufen dann von selbst:

Die Buckets behalten außerdem alte Versionen, sodass sich auch ein versehentlich gelöschter Stand noch eine Weile zurückholen lässt.

Damit ich merke, wenn etwas schiefgeht, gibt es ntfy, einen Dienst für Push-Nachrichten aufs Handy. Das Update am Sonntag meldet sein Ergebnis dorthin, und Uptime Kuma meldet sich auf demselben Weg, wenn ein Dienst nicht antwortet. ntfy läuft auf dem Backup-Server bei Hetzner, nicht auf pve1, aus einem schlichten Grund. Wenn pve1 ausfällt, soll mir noch jemand davon erzählen können.

Alles in einem Bild

Jetzt hat jedes Teil einen Namen, und das ganze System passt in ein Bild. Oben stehen der NetBird-Server und das Handy, in der Mitte pve1 mit seinen VMs, unten der Backup-Server und der Speicher bei Hetzner. Ein paar Namen darin, etwa Authentik und InfluxDB, lernst du erst in späteren Teilen kennen.

Beide Wege von heute stecken darin. Die Anfrage aus dem Zug läuft vom Handy über dns-01 und proxy-01 zu paperless-01, die Änderung vom Schreibtisch über den Runner zu einer neuen VM und nachts weiter zu Hetzner.

Zurück im Zug

Wenn ich das nächste Mal im Zug einen Brief aufrufe, laufen im Hintergrund also zwei Geschichten zusammen. Die eine ist der Weg meiner Anfrage durch drei VMs, ohne dass irgendwo eine Tür offen steht. Die andere ist alles, was vorher passiert sein muss, damit es diese VMs überhaupt gibt und sie morgen noch da sind.

Rückblickend haben die vier Ziele fast jede spätere Entscheidung vorweggenommen. Und zwei Gewohnheiten möchte ich nicht mehr missen. Vor dem gefährlichsten Schritt steht ein Mensch, der den Plan gelesen hat, und Sicherung und Meldeweg stehen auf anderer Hardware als das, was sie schützen.

Die übrigen fünf Teile folgen der Karte. Teil 2 bleibt beim Handy und prüft mit einem Mitschnitt, ob „alles verschlüsselt“ auch im eigenen Heimnetz stimmt. Teil 3 geht dem Brief hinterher, vom Knopf am Scanner bis zum durchsuchbaren Dokument, das ein Sprachmodell zu Hause einsortiert hat. Danach wechseln wir an den Schreibtisch: Teil 4 zeigt, wie aus dem Bauplan ein laufender Dienst wird, und Teil 5 erzählt von den eigenen Runnern und einer nächtlichen Testreihe, die plötzlich zu langsam war, obwohl am Code nichts falsch war. Teil 6 kehrt schließlich zu der Nacht zurück, in der der Rechner ausfällt.