- Nach jahrelangen Versuchen mit verschiedenen Self-Hosting-Ansätzen teilt der Autor seine Erfahrung, erfolgreich eine maßgeschneiderte Umgebung aufgebaut zu haben
- Die wichtigsten Ziele waren Kontrolle über persönliche Daten und der Betrieb einer vertrauenswürdigen Infrastruktur; dafür wurden mehrere zentrale Technologien wie NixOS, ZFS, Tailscale und Authelia kombiniert
- Unter Berücksichtigung der Nutzbarkeit für Familie und Bekannte wurde auch die Zugänglichkeit verbessert, etwa durch SSO und eine separate Startseite
- Probleme aus dem realen Betrieb und konkrete Lösungswege (z. B. Reverse Proxy für private Dienste, gemischte VPN-Umgebungen, Authentifizierungs-Integration) werden ausführlich dokumentiert
- Für die Zukunft sind weitere Verbesserungen wie Backup-Infrastruktur und stärkere Sicherheit geplant; außerdem werden Know-how und Referenzmaterialien geteilt
Einführung und Motivation
- Nach mehreren Jahren mit verschiedenen Self-Hosting-Methoden wurde eine für den Autor passende, „gut genug“ funktionierende Umgebung aufgebaut
- Dabei wurden zahlreiche Open-Source-Ressourcen und Erfahrungen anderer genutzt; der Prozess wird geteilt, um auch anderen Entwicklern zu helfen
Ziele
- Durch direkte Kontrolle über persönliche Daten und die zugehörigen Dienste sollen Datenschutz gestärkt und Risiken durch Änderungen oder Einstellung externer Dienste minimiert werden
- Diese Kontrolle soll auch Familie und Bekannten zur Verfügung stehen, mit Fokus auf eine vertrauenswürdige Service-Umgebung
Anforderungen
-
Unverzichtbare Anforderungen
- Die Exponierung zum öffentlichen Internet der Dienste soll so weit wie möglich begrenzt werden, um das Risiko von Sicherheitsvorfällen zu senken
- Ausfallzeiten der Kerninfrastruktur durch Fehler sollen minimiert werden (Vermeidung zirkulärer Abhängigkeiten und einfache Konfigurations-Rollbacks)
- Direkter Besitz zentraler Komponenten wie Authentifizierung, Netzwerk und Domains sowie vorrangige Nutzung von Open Source
- Berücksichtigung der Nutzbarkeit aus Sicht von Familie und Bekannten (konsistentes SSO-Login, minimaler Wartungsaufwand)
- Konsequente Einführung einer deklarativen Konfiguration über Dateien (einfachere Versionsverwaltung, Backup und Wiederherstellung sowie bessere Wiederverwendbarkeit fremder Konfigurationen)
- Updates müssen einfach und sicher sein, damit regelmäßige Wartung möglich bleibt
-
Nicht priorisierte Anforderungen
- Extreme Modularität oder Perfektion in der Struktur sind nicht nötig (Pragmatismus vor Eleganz)
- Nicht alles muss Open Source sein, aber wenn möglich, wird es bevorzugt
- Hochverfügbarkeit (HA) wird nicht angestrebt; stattdessen wird eine einfache Struktur gewählt und Downtime akzeptiert
Technologieauswahl
-
NixOS
- Eine Linux-Distribution, die sämtliche OS-Konfigurationen deklarativ mit der Nix-Sprache und dem Paketmanager verwaltet
- Da die Konfiguration als Code vorliegt, sind Versionsverwaltung und systematische Rollbacks möglich
- Unterstützt viele Pakete sowie Integration mit Docker/PODMAN usw.
- Durch Einsicht in Nix-Konfigurationen anderer Entwickler wurde zusätzliches Know-how aufgebaut
-
ZFS
- Ein leistungsfähiges Dateisystem mit starken Datenschutz-/Datensicherungsfunktionen wie Snapshots und Rollbacks
- Vier 10-TB-HDDs wurden als RAIDZ2 konfiguriert (Ausfall von zwei Festplatten gleichzeitig möglich), mit 256GB SDD als Cache
- Trennung von Datei- und Medien-Datasets sowie Verwaltung über NFS-Mounts je nach Einsatzzweck
- Aufbau einer einfachen und zuverlässigen Hauptspeicher-Architektur
-
Tailscale & headscale
- Tailscale: ein gut zugängliches Mesh-VPN, das durch reine Client-Installation Zugriff auf das interne Netzwerk ohne Exponierung ins öffentliche Internet ermöglicht
- Headscale: ein selbst hostbares Open-Source-Backend für Tailscale, das das Risiko von Änderungen an Unternehmensrichtlinien eliminiert
- Verbessert die Netzwerksicherheit, erfordert aber die Installation eines Clients auf den Nutzergeräten
- Aus Sicht der Usability ist diese erforderliche Client-Installation auf jedem Gerät eine gewisse Einstiegshürde
-
Authelia & LLDAP
- Authelia: eine auf OpenID Connect basierende Lösung für SSO, Authentifizierung und Autorisierung, die mit einem nginx-Proxy integriert werden kann
- LLDAP: Lightweight LDAP, genutzt für Benutzer- und Gruppenverwaltung in Authelia sowie als Fallback-Authentifizierung für Backups
- Läuft mit minimalen Ressourcen gut, ist aber schwierig zu konfigurieren und bringt eine Lernkurve bei der Integration mit einzelnen Diensten mit sich
Strukturdesign
-
Architektur
- Jeder Server ist nach einem Star-Wars-Planeten benannt
- Der Einstiegspunkt (public server) ist „taris“ und stellt essenzielle Dienste wie Authelia, headscale und den Blog bereit
- headscale, Authelia und LLDAP müssen von außen erreichbar sein und werden daher in begrenztem Umfang öffentlich betrieben
- Private Dienste (Foundry VTT, Monitoring usw.) werden über NGINX geproxyt und selektiv veröffentlicht
-
Private Server
- Auf dem Hauptserver „kuat“ verwaltet TrueNAS einen NixOS-VM und den ZFS-Storage-Pool
- Der Snapshot-/Backup-Bereich wird in „files“ (nicht wiederherstellbare Daten) und „media“ (optional wiederherstellbare Daten) getrennt
- Zentrale Dienste laufen als NixOS auf der VM „bespin“, daneben gibt es eine separate Test-VM („alderaan“)
-
Weitere Dienste
- Mission-Critical-Geräte werden als Appliances mit nur einem Zweck betrieben (z. B. Smart Home separat mit Home Assistant OS)
- Für den Matrix-Server und den Element-Client wird das offizielle Ansible-Playbook genutzt
- E-Mail und Passwortverwaltung werden an externe Dienste wie ProtonMail und Bitwarden ausgelagert, um zirkuläre Abhängigkeiten zu vermeiden
Einzelne Probleme und Lösungen
-
Startseite für Dienste
- Ein schlichtes Dashboard auf Basis von Flame verbessert die Zugänglichkeit der Dienste für einzelne Nutzer
- Wegen geringer Nutzungskosten und hoher visueller Qualität wird es pragmatisch eingesetzt, bis eventuell ein Ersatzdienst eingeführt wird
-
Tailscale parallel zu anderen VPNs verwenden
- Einige Betriebssysteme (insbesondere Android und Windows) unterstützen nicht mehrere gleichzeitig aktive VPNs
- Durch die Kombination der Exit-Node-Funktion von Tailscale mit Gluetun (containerbasierter VPN-Client) wird Umgehung über externe VPNs wie ProtonVPN ermöglicht
- Es gibt allerdings Nebenwirkungen wie höheren Batterieverbrauch und gelegentliche Geschwindigkeitseinbußen
-
Hinweise zur Authentifizierung
- Wichtige Authentifizierungsprotokolle je nach Self-Hosting-Dienst: OIDC (bevorzugt), OAuth, LDAP
- Für jeden Dienst und für Authelia sind separate Konfigurationen erforderlich
- Admin-Konten sollten unbedingt getrennt von der Authelia-/LLDAP-Integration bestehen bleiben, damit bei Authentifizierungsproblemen ein Wiederherstellungsweg vorhanden ist
- Bei Diensten ohne OIDC-Unterstützung wird Zugriffskontrolle über die Proxy-Integration von NGINX und Authelia umgesetzt
- Authelias OIDC und die Zugriffskontrolle über NGINX Proxy müssen getrennt konfiguriert werden
-
DNS und SSL-Ausstellung
- Öffentliche Dienste werden auf übliche Weise betrieben (Domain → öffentliche IP)
- Interne Dienste verwenden die Subdomain „internal“ und Tailscale-IP, um externe Exponierung zu verhindern
- Für SSL-Zertifikate wird die integrierte Lets Encrypt-Unterstützung von NixOS genutzt (für öffentliche Dienste HTTP-01, für interne Dienste DNS-01)
-
Hinweise zur NixOS-Installation auf VPS
- Viele VPS bieten keine Installationsoption für NixOS an
- Falls eine Installation nötig ist, sollte über Community-Wikis oder Ähnliches geprüft werden, welche Installationspfade unterstützt werden
-
Mounten von TrueNAS-Datasets in VMs
- Die Standard-Firewall von TrueNAS blockiert den Host-Zugriff aus VMs
- Entsprechend der offiziellen Anleitung (Erstellung eines Bridge-Netzwerks) wurde das Mounten von NFS-Datasets umgesetzt
-
Öffentlicher Reverse Proxy für private Dienste
- Bei einer headscale-basierten Umgebung können private Dienste mit NGINX
proxyPass nach außen veröffentlicht werden
- Zusätzlich zu Tailscale Funnel werden Konfigurationsbeispiele und Referenzmaterial zur Einrichtung bereitgestellt
Nächste Schritte und Aufgaben
- Ein dedizierter Backup-Server und ein Verfahren zur Validierung der Wiederherstellung werden zusätzlich benötigt
- Die Zugriffskontrolle von Tailscale/headscale soll künftig aktiver genutzt werden
- Weitere Sicherheitsmaßnahmen wie abgesicherter SSH-Zugriff sind geplant
- Die Einführung lokaler DNS-Lösungen für Verschlüsselung und Caching wie Pi-hole oder AdGuard Home wird geprüft
- Eine Erweiterung um neue Dienste wie Forgejo, Manyfold und RomM wird erwogen
Referenzmaterialien
2 Kommentare
Sieht großartig aus!
Hacker-News-Kommentare
Das Ziel ist, dass Familie oder Freunde möglichst einfach alles nutzen können: pro Person ein Login-Konto, über das sie per SSO (Single Sign-On) auf mehrere Dienste zugreifen. Genau das ist der wirklich schwierige, aber zugleich auch coole Teil. Open Source und Linux sind in dieser Hinsicht ziemlich paradox: Sie werden wirklich überall eingesetzt und decken alle möglichen Protokolle ab, aber sobald es um die eigentliche Client-Umgebung geht – also darum, Menschen zusammenzubringen und groupwareartige Funktionen selbst aufzubauen – wird es eher noch komplizierter. Schon der Prozess, verschiedene Systeme organisch zu integrieren und sogar eine Verzeichnisinfrastruktur aufzubauen, ist bemerkenswert. Ich hätte nie gedacht, dass ich irgendwann einmal selbst FreeIPA oder einen Windows-kompatiblen Verzeichnisdienst betreiben würde, aber inzwischen fühlt es sich so an, als würde sich eine auf OpenID basierende Welt tatsächlich etablieren.
Danke für die Zustimmung. Einfaches Login und gute Zugänglichkeit waren in diesem Projekt die schwierigsten Anforderungen und aus meiner Sicht genau der Punkt, der darüber entscheidet, ob Menschen es tatsächlich nutzen oder nicht. Open Source ist wirklich überall, aber die Probleme beginnen in dem Moment, in dem normale Nutzer tatsächlich selbst etwas verwenden wollen. Dieses Paradox entsteht meiner Meinung nach dadurch, dass jedes Projekt für sich allein innovieren will. Dass es niemanden gibt, der alles in eine Richtung zieht, ist zugleich Vor- und Nachteil. Trotzdem habe ich den Eindruck, dass Self-Hosting allein in den letzten fünf Jahren bei Installation und Benutzung deutlich einfacher geworden ist.
Diesem Paradox stimme ich voll zu. Ich habe gestern auf meiner Validierungsplattform darüber gepostet, wie schwer FOSS für Nicht-Techniker zugänglich ist. Ich frage mich, ob eine Plattform nach Art eines Systemintegrators, die technische Nutzer mit nichttechnischen Einzelpersonen verbindet, eine Lösung sein könnte.
Eigentlich ist es gar nicht so schwer. Wenn man sich nicht an einen bestimmten Dienst klammert, sondern SSO-Unterstützung zum wichtigsten Auswahlkriterium macht, lässt sich das Setup überraschend leicht umsetzen. Ich selbst hatte anfangs fast keine Erfahrung, habe aber mit caddy und authentik schnell ein Self-Hosting-System aufgebaut. Als Alternative ist yunohost eine sehr einfache Distribution, die sogar SSO automatisch mitkonfiguriert.
Ich nutze mit authentik Google-, Discord- und GitHub-SSO-Authentifizierung. Das funktioniert für alle völlig ausreichend gut.
Mir ist klar, dass es Zeit kosten kann, für sich selbst das ganz persönliche „passende“ System zu finden. Ziele, Vorlieben und Umgebungen sind bei jedem anders, deshalb möchte ich meinen finalen Setup-Prozess in einem Blogpost zusammenfassen und teilen. Darin geht es um Ziele und Anforderungen, die verwendeten Technologien, das Design und den Weg zur Problemlösung. Meine Herangehensweise wird nicht für alle passen, aber vielleicht ist sie für andere trotzdem nützlich. Ich selbst bin auch dank vieler Inhalte und freier Software gewachsen und möchte deshalb weiterhin Hilfe weitergeben.
Mich würde interessieren, wie deine Erfahrungen mit Nix im Homelab sind. Ich betreibe seit über sieben Jahren ziemlich hardcore ein 25U-Rack mit kleinem Kubernetes, Ceph und Talos Linux, will aber immer stärker vereinfachen und lande beim Nachdenken seltsamerweise immer wieder bei Nix und ZFS. Die damit verbundenen Schwierigkeiten kommen mir sehr bekannt vor. Wenn du auch Fragen hast, frag gern.
Hast du schon einmal überlegt, coolify zu verwenden? Ich nutze coolify seit über einem Jahr und mag besonders, wie einfach Deployments direkt aus GitHub laufen, fast wie bei Heroku. https://coolify.io/
Mich würde interessieren, ob du auch die ZFS-Verschlüsselung nutzt. Ich habe früher FreeIPA und mehrere andere VMs auf Debian+ZFS betrieben, dann aber zur Vereinfachung auf eine Struktur umgestellt, bei der auf einem VPS nur die Verschlüsselungsbibliothek von Seafile läuft und per ZFS send/receive auf meinen Heimserver gesichert wird. Dieser Server geht nachts an, macht Updates und Synchronisation und geht dann wieder schlafen. Um es noch sicherer zu machen, überlege ich, auch ZFS auf meinem Linux-Desktop (Fedora) vollständig verschlüsselt zu betreiben. Da mein Haupt-Dataset bereits verschlüsselt ist, werden auch externe Laufwerke oder Cloud-Sync deutlich einfacher. Das komplette Fotoarchiv in Seafile auf dem VPS hochzuladen, wäre kostenseitig aber zu aufwendig, deshalb suche ich noch nach einer Lösung.
Dein Erfahrungsbericht zum Setup und die detaillierten Erklärungen waren hilfreich. Ich kann es nicht so schnell wie du direkt einführen, aber ich habe beschlossen, testweise flame als Dashboard für meine Familie zu installieren.
Freut mich, deine Arbeit ist wirklich interessant. Ich arbeite auch an einem ähnlichen Projekt auf Basis von NixOS. Mein Ziel ist eine kleine Box mit fast null Konfiguration und Apple-ähnlichem Gefühl, die man einfach an das Modem anschließt und dann nur noch einen Web-Installationsassistenten durchläuft. Es ist noch früh, aber bei mir zu Hause läuft es bereits. Das Gerät übernimmt gleichzeitig die Rolle eines Hybrid-Routers (OPNSense/PFSense) und eines App-Servers (Nextcloud, Synology, Yunohost usw.). Sämtliche Konfiguration wird auf einer einzigen Seite mit Nix-Modulen verwaltet. Dynamic DNS, Let's-Encrypt-Zertifikate, automatische Subdomain-Zuweisung pro App, Werbeblocker und headscale sind eingebaut. Ich arbeite gerade sogar an SSO und will mir aus deinem Beitrag ein paar Ideen holen. Mehr dazu unter https://homefree.host
Wenn ich manchmal mein Heimnetz anschaue, stelle ich mir vor, welchen Schaden ich meiner Familie zufügen würde, wenn ich sterbe, oder wie schwer es für Außenstehende wäre, mein Setup zu verstehen. „Homelab spielen“ erfüllt in Wahrheit etwas Ähnliches wie das Hobby älterer Generationen, Modelleisenbahnstrecken im Keller zu bauen. Das ist nicht abwertend gemeint, aber ich glaube, manche Menschen haben den Instinkt, eine kleine Miniaturwelt zu besitzen, die sie absolut kontrollieren können.
Ich hatte genau denselben Gedanken und habe deshalb Unterlagen für den Ernstfall geschrieben. Teil 1 beschreibt Geld und den Aufbewahrungsort wichtiger Dokumente, Teil 2 enthält Anweisungen dazu, wie man das Haus wieder „dümmer“ machen kann. Zum Beispiel: smarte Schalter entfernen und normale Schalter wiederherstellen, Schlüsseldienste wie Bitwarden in die Cloud verlagern, Kosten für Domain und Mail aufrechterhalten oder den Router wieder auf das Standardgerät des ISP zurücksetzen. Meine Frau war Smart Home gegenüber nicht besonders aufgeschlossen, aber es hat sie beruhigt, dass man alles jederzeit wieder in ein „dummes Haus“ zurückverwandeln kann. Ehrlich gesagt weiß ich nicht, wie unbequem es wäre, wenn das alles wegfiele, aber es tröstet mich auch ein wenig, dass es dann nicht mehr mein Problem wäre.
Ich speichere unsere Familienfotos auf einem home lab RAID1 und sichere sie jede Nacht per rsync auf eine externe Festplatte an dem Computer im Haus meiner Schwägerin. Das Backup dient gleichzeitig dazu, dass meine Familie im Notfall leicht darauf zugreifen kann. Meine Frau interessiert sich nicht für IT, also habe ich ihr einfach gesagt: „Wenn du den USB anschließt, ist alles da.“
Ich finde, man kann nutzlose Bedrohungsszenarien wie den Diebstahl physischer Datenträger ignorieren. Praktischer ist es, alle Fotos und wichtigen Dokumente unverschlüsselt zu speichern und zusätzlich leicht verständliche Erklärungen zu hinterlassen. Größere Sorgen macht mir eher der Bereich Heimautomatisierung.
Es ist praktisch wichtig, sich im Voraus Gedanken darüber zu machen, was passiert, wenn der Betreiber des Homelabs längere Zeit ausfällt oder stirbt. Ich habe zwar nicht bewusst darauf hingearbeitet, alles dafür einfach zu machen, aber ich denke, man sollte noch mehr darüber nachdenken. Entscheidend ist, wichtige Daten und die Zugangsdaten dazu zu hinterlassen. Dienste wie Nextcloud können helfen, damit Daten automatisch auf die Geräte der Familie synchronisiert werden, und es ist sinnvoll, Familie und Freunde die Nutzung selbst ausprobieren zu lassen. Auch bei uns versuche ich, Home Assistant so weit zu einem unverzichtbaren Haushaltsgerät zu machen, dass mein Partner bzw. meine Partnerin ihn mitbenutzt. Das ist leichter zu verwalten, wenn es als physisches Gerät existiert statt in einer separaten VM. Natürlich ist das alles von viel Hoffnung geprägt, deshalb ist es wichtig, zumindest mit nahen Familienmitgliedern gemeinsam einen konkreten Plan auszuarbeiten.
Ich habe darüber ebenfalls viel nachgedacht. Ich gehe davon aus, dass NAS und Docker-Dienste ohne mich nicht zuverlässig starten würden. Ein externes Passwort-Backup könnte ohne fachkundige Hilfe vermutlich ohnehin nicht wiederhergestellt werden. Deshalb speichere ich per Cron jeden Tag nur inkrementelle Snapshots in neue Ordner auf einer NTFS-USB-Festplatte. Das Volumen liegt unter 50 GB und lässt sich günstig redundant vorhalten. Im Ernstfall muss man nur die Festplatte anschließen und die Ordner kopieren. Außerdem habe ich auf einzelnen Laptops vollständige Kopien der gesamten Seafile-Bibliothek. Die Mail-Domain habe ich für zehn Jahre im Voraus bezahlt und hoste sie bei iCloud. Weil Mails mit Familienfotos als Anhang den Speicher füllen und dann zurückgewiesen werden, denke ich über migadu nach.
Ich interessiere mich ebenfalls sehr für dieses Thema. Ich möchte allerdings warnen: Wenn man selbstständig ist oder ein IT-Startup gründet, wird der Drang zum Homelab noch stärker. Irgendwann reicht es nicht mehr, nur einfache Container zu betreiben; man reicht Formulare ein, bekommt legal eine DBA und eine ASN, beschafft sich am Ende sogar eigene IP-Blöcke bzw. IPv6 und entwickelt sich zum eigenen ISP. Das ingress-Problem wird oft mit tailscale gelöst, aber das ist wirklich schwierig. Ich glaube, ein auf STUN/TURN basierendes Setup, das auf dem Server nur statische Dateien cached und dynamischen Zugriff über eine Login-Wall mit E-Mail-Magic-Link authentifiziert, wäre theoretisch weder besonders riskant noch teuer. Wenn man sich eine Remote-Entwicklungsumgebung aufbaut, hat man gleich noch einen Vorwand, sich auch darin zu vergraben. Zur Referenz: https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_NAT, https://en.wikipedia.org/wiki/STUN
Ich spiele in letzter Zeit mit Immich herum und überlege jedes Mal, ob ich es außerhalb des Hauses nur über tailscale nutze oder zusätzlich noch einen Reverse Proxy auf einem VPS betreibe. Was mich am meisten beschäftigt, ist die Suche nach einer benutzerfreundlichen Monitoring-/Security-Lösung, die erkennt, wenn auf dem VPS jemand Angriffsversuche unternimmt.
Mein Setup ist viel einfacher.
HTTP sendet Passwörter im Klartext, daher sollte man mindestens ein selbstsigniertes Zertifikat verwenden.
Auch die Infrastruktur oder Dienste selbst als Code zu bauen, ist einfach großartig zum Lernen. Cool ist auch, dass man die eigenen Anforderungen damit exakt treffen kann.
Ich würde so ein Homelab gern betreiben, habe aber keine Zeit. Am Wochenende könnte ich es installieren, aber für laufende Pflege und Updates fehlt mir dauerhaft der Spielraum. Deshalb überlasse ich es einfach einem Cloud-Anbieter und denke nicht weiter darüber nach. Mich würde interessieren, wie Leute wie ich, die nur Cloud nutzen, an so etwas herangehen.
Bei meinem früheren Setup war ich auch gestresst, weil die Wartung nicht gut lief. Deshalb habe ich NixOS und ZFS schätzen gelernt. Bei beiden ist Rollback wirklich einfach: Man aktualisiert, und wenn etwas schiefgeht, kehrt man sofort zur vorherigen Version zurück. Debugging macht man dann erst, wenn man Zeit dafür hat. Und wenn du mit einer Cloud-Option zufrieden bist, ist das natürlich auch okay. Ein eigenes Setup kostet definitiv Zeit, deshalb muss jeder für sich Kosten und Nutzen abwägen.
Ich betreibe etwa 12 self-hosted Dienste, und Upgrades dauern normalerweise nicht einmal eine Minute pro Monat. Für jeden Dienst gibt es einen Ordner mit einem docker-compose-Stack und dem Datenverzeichnis; aktualisiert wird mit
docker compose pullund danachup -d, und das war's. Sehr gelegentlich braucht ein Upgrade eine Konfigurationsänderung, aber meistens ist alles in wenigen Minuten erledigt. Ganz ohne VMs: Vollständig automatisiertes Self-Hosting nur mit Docker Compose ist aus meiner Sicht der einfachste Weg.Es bleibt nicht bei einem einzigen Wochenendprojekt. Bei mir fing es damit an, einmal Plex zu installieren, und ein Jahr später hatte ich ein komplexes Gebilde aus Proxmox und allerlei Heimautomatisierung. Halb Scherz, halb ernst: Wenn du minimal anfangen willst, dann mit
docker compose, denn das ist leicht zu verwalten und einfach zu aktualisieren.Ich frage mich, ob man überhaupt SSO braucht. Wenn Familie oder Freunde einen wireguard-Client nutzen – auch unter iOS sehr einfach –, können sie sich mit einem Schalter ins Heimnetz einklinken und dann alle internen Dienste ganz ohne separates SSO verwenden. Für ein kleines Heimnetz überwiegen die Vorteile die Nachteile deutlich.
Die Dienste, die wir verwenden, etwa Nextcloud oder Mealie, haben ohnehin standardmäßig Benutzerkonten pro Person. Dank SSO kann man mit demselben Konto auf alle Dienste zugreifen, und ich muss nicht einmal die Passwörter verwalten. Das Setup wird zwar etwas komplexer, im Betrieb ist es aber eher einfacher, und dadurch steigt die Wahrscheinlichkeit, dass die Familie es tatsächlich nutzt.
Ich self-hoste 20 Apps und habe es endgültig satt, Authentifizierung überall separat zu verwalten, deshalb führe ich gerade SSO ein. Wenn ich meiner Familie einige Apps zugänglich machen will, ist für mich am wichtigsten, das Auth-Thema zentral an einer Stelle zu lösen. Dem oben genannten Ansatz kann ich deshalb nicht zustimmen.
Ich frage mich, warum man überhaupt flame verwendet. Damit holt man sich Dutzende oder Hunderte Third-Party-Abhängigkeiten wie node, react, redux usw. in ein „Sicherheitskönigreich“, obwohl für eine Startseite im Grunde auch einfach eine einzelne HTML-Seite mit ein paar Links reichen würde.
Ich würde Self-Hosting mit NixOS gern ausprobieren, habe es aber noch nicht umgesetzt. Meine Umgebung verwalte ich mit ein paar VMs und je VM einer einzelnen docker-compose-Datei; per ansible-Playbook werden nur die Compose-Dateien kopiert, und Fedora Server halte ich jeweils eine Release-Version hinter der aktuellen und upgrade dann beim Support-Ende. Auf dem Mac nutze ich nix-darwin, daher verstehe ich die Vorteile von Nix-Konfigurationen, aber bislang spüre ich noch nicht genug Effizienzgewinn oder Zeitersparnis, um meine reale Umgebung nach Nix zu portieren. Vielleicht wäre es etwas anderes, wenn ein LLM mir die Konfigurationsdateien einfach diktieren würde, aber im Moment fehlt mir die Motivation dafür.
Ich habe NixOS auch ausprobiert und innerhalb einer Woche sogar mein Heimnetz und zwei produktive Server komplett migriert. Inzwischen sind 3–4 Monate vergangen, und ich bin zufriedener als erwartet. Die Servermigration war sogar leichter als ein Workstation-Umzug. Neulich habe ich auch noch ein Jetson Orin Nano als Spielzeug mit NixOS aufgesetzt und damit herumgespielt. Mit Gentoo hätte ich mir das früher nie zugetraut. Was mich an Gentoo am meisten genervt hat, waren die absurd langen Compile-Zeiten auf älteren Rechnern – zum Beispiel dauerte es auf einem XPS von 2019 etwa sechs Stunden, GHC zu bauen.
Für mich war bei NixOS der größte Unterschied, wie leicht Rollbacks sind, wenn etwas schiefläuft. Mit ansible- oder compose-basierten Setups kann man zwar auch Backups und Wiederherstellung bauen, aber dort muss man dieses System selbst erst entwerfen. Wenn du mit deinem aktuellen System zufrieden bist, ist das natürlich völlig in Ordnung.
Wenn man bereits in gewissem Maß IaC nutzt, fühlt sich der zusätzliche Effizienzgewinn durch NixOS gar nicht mehr so groß an.