Zwanzig Jahre Self-Hosting: Warum u/jc-21 ein kleines Homelab betreibt

Eva Wong

IceWhale author

Eva Wong ist die technische Redakteurin und begeisterte Tüftlerin bei ZimaSpace. Als lebenslanger Geek mit einer Leidenschaft für Homelabs und Open-Source-Softwarehat sie sich darauf spezialisiert, komplexe technische Konzepte in verständliche, praxisnahe Anleitungenzu übersetzen. Eva ist überzeugt, dass Self-Hosting Spaß machen sollte und nicht einschüchternd sein darf. Mit ihren Tutorials hilft sie der Community dabei, Hardware-Setups zu durchschauen, vom Bau des ersten NAS bis zum sicheren Umgang mit Docker-Containern.

Official Nginx Proxy Manager proxy-host list screenshot

Titelbild: Raspberry Pi – offizielles Produktfoto des Raspberry Pi 5.

Ein nützliches Home-Lab hat seinen eigenen Rhythmus. Die Dienste für den Haushalt funktionieren, der Besitzer weiß, wo die wichtigen Daten liegen, und ein Experiment kann warten, bis alle, die das Netzwerk nutzen, ihren Tag beendet haben. Genau von solchen Fortschritten wollten wir hören, als wir die Community eingeladen haben, ihre Geschichten zum Self-Hosting Day zu teilen.

In dem Beitrag von u/jc-21 führen rund zwanzig Jahre voller Experimente zurück zu einem bewusst kleinen, Linux-basierten Setup. Der Kommentator beschreibt einen FriendlyWrt-Router, einen Raspberry Pi 5 für tägliche Dienste wie AdGuard und Nginx Proxy Manager sowie ein NAS für rechenintensivere Workloads oder solche, die weniger gut mit ARM funktionieren, etwa Plex. Kleine Rechner und Netzwerkgeräte sind an eine USV angeschlossen. Der Autor gibt außerdem an, Nginx Proxy Manager entwickelt zu haben, und verbindet damit den persönlichen Wunsch nach einem einfacheren Zugriff mit einem Open-Source-Projekt.

„Mein Lab ist klein, praktisch und auf die beste Art langweilig“
u/jc-21

Das Architektur-Upgrade sorgt für eine klarere Aufteilung der Zuständigkeiten

Aus Sicht von ZimaSpace ist die übertragbare Idee die Trennung der Zuständigkeiten. Der Kern der täglichen Dienste benötigt eine andere Wartungsroutine als ein Rechner für Speicherexperimente oder anspruchsvolle Anwendungen. Sobald diese Rollen sichtbar sind, lassen sich Hardwareentscheidungen leichter erklären: Was muss verfügbar bleiben, was benötigt mehr Kapazität und was kann neu gestartet werden, ohne die Arbeit anderer zu unterbrechen?

Beginne mit den Abhängigkeiten statt mit der Liste der Container. Eine Anwendung kann korrekt laufen, während ihre Nutzer nicht darauf zugreifen können, weil ein Name nicht mehr aufgelöst wird oder der gewählte Zugriffsweg nicht verfügbar ist. Erstelle eine kurze Übersicht, die eine Nutzeraktion mit den dafür benötigten Diensten verknüpft. Das kann eine Seite mit Notizen sein. Sie ist wertvoll, wenn sie das System genau genug erklärt, damit Wartungsarbeiten nicht zum Ratespiel werden.

Ein praktischer Planungsleitfaden für ein kleines Home-Lab

Verantwortung	Planungsfrage	Eine nützliche Dokumentation
Tägliche Dienste	Was braucht der Haushalt im Alltag?	Eine Abhängigkeitsübersicht und eine Prüfung auf Client-Ebene.
Anwendungen	Welche Workloads benötigen eigene Ressourcen oder ein Wartungsfenster?	Version, Konfigurationsort und Neustartverfahren.
Gemeinsam genutzte Daten	Wo befinden sich die maßgeblichen Dateien und wer darf sie ändern?	Speicheraufbau und Zugriffsentscheidungen.
Wiederherstellung	Was bleibt bei einem Geräteausfall oder einer unterbrochenen Änderung erhalten?	Eine unabhängige Kopie und ein dokumentierter Wiederherstellungstest.

Legen Sie für die wichtigsten Alltagsdienste einen verlässlichen Wartungsplan fest

Eine kleine, ständig verfügbare Dienstebene ist dann nützlich, wenn sie sich berechenbar verhält. Bestimmen Sie für jeden unverzichtbaren Dienst eine verantwortliche Person, einen bekannten Speicherort für die Konfiguration und eine Möglichkeit zu prüfen, ob er tatsächlich funktioniert. Bei einem DNS-Dienst bedeutet das, von einem Client aus eine typische Namensauflösung zu testen. Bei einer Haushaltsanwendung heißt es, die Anwendung über den üblichen Zugriffsweg zu öffnen. Eine Anzeige für einen laufenden Prozess ist nur ein Teil dieser Prüfung.

Halten Sie Änderungen überschaubar genug, um sie rückgängig machen zu können. Notieren Sie die aktuelle Anwendungsversion und sichern Sie die Konfiguration vor einem Update. Legen Sie ein Wartungsfenster fest, das für die Systemnutzer passt, und prüfen Sie anschließend, ob die Nutzung für normale Clients weiterhin reibungslos funktioniert. Diese Betriebsroutinen eignen sich auch für kleine Installationen, ohne dass dafür eine aufwendige Verwaltungsplattform nötig ist. Entscheidend ist, wie sicher der Betreiber eine Änderung erklären und rückgängig machen kann.

Offizielle Proxy-Host-Liste von Nginx Proxy Manager — Die Liste der Proxy-Hosts im Projekt macht Ziele an einem Ort sichtbar; halten Sie auch den Kontext der zugehörigen Anwendung und des Zugriffs fest. Bild: Nginx-Proxy-Manager-Projekt.

Ein Reverse Proxy verdient einen eigenen Platz in der Dienstübersicht

Die offizielle Projektdokumentation von Nginx Proxy Manager beschreibt einen grafischen Ansatz für Proxy-Hosts und die Zertifikatsverwaltung. Damit eignet sich das Projekt gut als Beispiel für einen Dienst, dessen Konfiguration mehrere andere Anwendungen miteinander verbindet. Halten Sie fest, welcher Hostname zu welchem Ziel führt, wo die Anwendung selbst Daten speichert und welches Konto den Zugriff steuert.

Eine benutzerfreundliche Proxy-Oberfläche macht es nicht überflüssig, die dahinterliegende Anwendung zu verstehen. Prüfen Sie jeden Pfad als Ganzes: Client, Name, Proxy, Ziel und Anwendungskonto. Entscheiden Sie bewusst, welche Pfade ins lokale Netzwerk oder über einen privaten Fernzugriff erreichbar sein sollen. Wird eine Anwendung auf einen anderen Rechner verschoben, aktualisieren Sie diese Übersicht und testen Sie die gespeicherte Adresse von einem echten Client aus, bevor Sie die Migration für abgeschlossen erklären.

Offizielles Konfigurationsformular für Proxy-Hosts im Nginx Proxy Manager — Das offizielle Beispiel zur Konfiguration eines Proxy-Hosts im Nginx Proxy Manager zeigt die Zieleinstellungen, die in die Dienstübersicht gehören. Bild: Nginx-Proxy-Manager-Projekt.

Planen Sie Stromversorgung und Wiederherstellung anhand der Dienste, die den Menschen auffallen

Ein Ausfallplan sollte erklären, was noch funktioniert, wenn ein Teil des Systems ausfällt. Ermitteln Sie, welche Geräte für diesen Ablauf benötigt werden, einschließlich der relevanten Netzwerkgeräte, und berücksichtigen Sie nicht nur den Server. Wenn Sie eine USV verwenden, messen Sie die tatsächliche angeschlossene Last und testen Sie das vorgesehene Verhalten beim Herunterfahren. Die Laufzeit hängt von Akku, Last und Konfiguration ab. Sie sollte für die konkrete Installation ermittelt und nicht anhand der Größe eines Geräts angenommen werden.

Bewahren Sie Wiederherstellungsanweisungen an einem anderen Ort auf als dem Dienst, den sie beschreiben. Ein Netzwerkdiagramm, das nur hinter einem ausgefallenen Anmeldedienst liegt, ist genau im falschen Moment schwer zu erreichen. Halten Sie eine zugängliche Kopie wichtiger Notizen, einen dokumentierten Weg zum Backup und ein Verfahren bereit, um das System in sinnvoller Reihenfolge wieder in Betrieb zu nehmen. So lässt sich eine gewöhnliche Unterbrechung im Haushalt leichter bewältigen, ohne jeden Ausfall zu einem Abend des erneuten Zusammensuchens zu machen.

Welche Rolle der ZimaCube 2 spielt, wenn die Datenschicht wächst

Wer eine ähnliche Aufgabenteilung umsetzen möchte, kann ein persönliches Cloud-NAS ZimaCube 2 als gemeinsame Datenschicht neben einem vorhandenen Rechner für den täglichen Betrieb einsetzen. Dies ist unser Vorschlag zur Hardwareplanung: Der Community-Beitrag beschreibt eine andere Installation. Speichern Sie archivierte Medien, Projektdateien und Anwendungsdaten an klar definierten und verwalteten Orten und entscheiden Sie, welche Clients und Dienste auf die jeweiligen Bereiche zugreifen müssen.

Die Laufwerksschächte und Erweiterungsmöglichkeiten für M.2 des ZimaCube 2 bieten einer wachsenden Sammlung Platz und lassen sich auf unterschiedliche Speicheraufgaben abstimmen. Dimensionieren Sie die Konfiguration nach den gespeicherten Daten, den tatsächlich laufenden Diensten und den unabhängigen Backups, die Sie vorhalten möchten. Für den Umzug der Daten in ein größeres Gehäuse müssen nicht alle Dienste im Haushalt gleichzeitig umziehen. Eine schrittweise Übergabe hält das aktuelle System übersichtlich, während die Speicherrolle erweitert wird.

Offizielle Frontalansicht des silbernen persönlichen Cloud-NAS ZimaCube 2 — Offizielles Produktfoto des ZimaCube 2, das die in den Planungshinweisen von ZimaSpace besprochene Option für gemeinsam genutzten Speicher veranschaulicht. Bild: ZimaSpace.

Gestalte das nächste Upgrade so, dass du es verständlich übergeben kannst

Wähle für eine Testmigration eine Sammlung oder einen Anwendungsdatensatz aus. Bewahre den aktuellen Speicherort, kopiere ihn an den vorgesehenen Zielort und prüfe den Zugriff über den dafür vorgesehenen Client. Dokumentiere alle Änderungen an Pfaden oder Konten und stelle anschließend ein Beispiel aus der Sicherungskopie an einem separaten Speicherort wieder her. Eine abgeschlossene Übertragung ist überzeugender, wenn eine andere Person dieselben Informationen finden und erkennen kann, welche Kopie maßgeblich ist.

Halte in einer kurzen Übergabenotiz fest, welche Dienste täglich genutzt werden, welcher Speicher gemeinsam genutzt wird, wo sich die Wiederherstellungskopie befindet und welche Änderungen noch getestet werden. Ein ausführlicheres Beispiel zur Virtualisierung findest du in unserem Community-Aufbau mit Proxmox auf dem ZimaBoard 2. Ziel ist dieselbe Klarheit: ein System, das nützlich bleibt, während sein Besitzer weiter dazulernt.

Die Erkenntnis zum Self-Hosting Day

Für den Self-Hosting Day lautet die nützliche Erkenntnis: Mache das Alltagssystem so verständlich, dass du ihm vertrauen kannst, und schaffe dir einen separaten Ort zum Experimentieren. Ein kompakter Dienstekern und eine gut verwaltete Datenebene können sich unterschiedlich schnell weiterentwickeln.

Weiter erkunden

Originalbeitrag und Projektverweise

Basierend auf dem oben verlinkten Beitrag zum Self-Hosting Day. Die Architekturinterpretation und die Hinweise zur Hardwareplanung stammen von ZimaSpace. Screenshots und Produktillustrationen sind den jeweiligen Originalprojekten oder Herstellern zugeordnet.