Vor etwa einem Monat habe ich mein Homelab aufgebaut.
Eigentlich war das Ganze nie als großes Infrastrukturprojekt geplant. Der Auslöser war sogar erstaunlich unspektakulär. Nach den Änderungen bei Synology wollte ich Home Assistant wieder zuverlässig betreiben, ohne auf inoffizielle Workarounds oder dauerhaft gepflegte Hacks angewiesen zu sein. Also habe ich einen alten Gaming-PC aus der Ecke geholt, Proxmox installiert und angefangen, die ersten Dienste umzuziehen.
Rückblickend war Home Assistant allerdings nur der Einstiegspunkt.
Die eigentliche Veränderung fand an einer ganz anderen Stelle statt.
Die größte Überraschung war nicht Home Assistant
Wenn man sich heute mit Homelabs beschäftigt, landet man sehr schnell bei Themen wie Smart Home, KI, Automatisierung oder Selbsthosting.
Auch ich habe mit diesen Dingen experimentiert. OpenClaw läuft. Paperless läuft. Home Assistant läuft. Diverse andere Dienste ebenfalls.
Trotzdem war keines dieser Systeme die größte Überraschung.
Die größte Überraschung war, dass sich meine tägliche Arbeit als Entwickler verändert hat.
Nicht durch neue Software.
Nicht durch KI.
Sondern durch Infrastruktur.
Das klingt zunächst deutlich weniger spektakulär als die neuesten KI-Agenten oder autonome Assistenten. Im Alltag hat genau dieser Bereich jedoch den größten Einfluss auf meine Produktivität.
Ich kannte Traefik bereits – aber nur als Nutzer
Docker nutze ich seit vielen Jahren. Container gehören für mich längst zum normalen Entwicklungsalltag.
Docker Compose ebenfalls.
Traefik war dagegen ein interessantes Beispiel.
Natürlich kannte ich Traefik bereits aus Projekten und Unternehmensumgebungen. Reverse Proxies sind nichts Exotisches. In vielen Unternehmen existieren sie einfach. Man nutzt sie, konfiguriert vielleicht gelegentlich eine Route und arbeitet anschließend mit den bereitgestellten Diensten.
Was ich bisher jedoch nie gemacht hatte, war der vollständige Betrieb einer solchen Infrastruktur für mich selbst.
Im Homelab war ich plötzlich nicht mehr der Entwickler, der vorhandene Infrastruktur konsumiert.
Ich war die Person, die sie entwerfen musste.
DNS.
Routing.
Docker-Netzwerke.
Hostnamen.
Service Discovery.
Plötzlich musste ich mir Gedanken darüber machen, wie neue Anwendungen überhaupt in das System integriert werden sollen.
Und genau an diesem Punkt begann sich meine Sicht auf lokale Entwicklungsumgebungen zu verändern.
Das eigentliche Problem war nie Docker
Rückblickend fällt mir auf, dass Docker selbst nie mein Problem war.
Docker funktionierte immer.
Die eigentliche Herausforderung war die Umgebung drumherum.
Jedes Projekt brachte seine eigene kleine Welt mit.
Eigene Ports.
Eigene Datenbanken.
Eigene Redis-Instanzen.
Eigene Sonderkonfigurationen.
Das funktionierte grundsätzlich problemlos. Aber je mehr Projekte gleichzeitig aktiv wurden, desto mehr kleine Reibungsverluste entstanden.
War Mailhog jetzt auf Port 8025 oder 8026?
Welche Anwendung belegt aktuell Port 8080?
Welche Datenbank gehört eigentlich zu welchem Projekt?
Warum funktioniert die Websocket-Verbindung in diesem Projekt anders als im nächsten?
Nichts davon ist technisch schwierig.
Aber alles davon verbraucht Aufmerksamkeit.
Und Aufmerksamkeit ist oft die knappste Ressource überhaupt.
Der Moment, in dem es Klick gemacht hat
Irgendwann begann ich damit, meine Projekte konsequent hinter Traefik zu betreiben.
Aus Ports wurden Hostnamen.
Aus kryptischen Adressen wurden sprechende Ziele.
Statt:
localhost:8080
oder
localhost:8025
öffne ich heute einfach:
- dashclip-delivery.lan
- dashclip-mailhog.lan
- dashclip-reverb.lan
Der Unterschied wirkt zunächst klein.
Im Alltag ist er erstaunlich groß.
Ich denke nicht mehr über Ports nach.
Ich denke nicht mehr darüber nach, wie ein Dienst erreichbar ist.
Ich öffne einfach die Anwendung.
Je länger ich das System nutze, desto mehr fällt mir auf, wie viel mentale Energie früher für solche Kleinigkeiten verloren gegangen ist.
Die Infrastruktur wurde plötzlich zur Plattform
Eine weitere interessante Erkenntnis entstand durch meine Open-Source-Projekte.
Anfangs war meine lokale Infrastruktur sehr eng mit den Projekten verknüpft.
Die Docker-Stacks gingen implizit davon aus, dass Traefik vorhanden ist.
Dass bestimmte Netzwerke existieren.
Dass lokale Domains konfiguriert sind.
Für mich funktionierte das hervorragend.
Bis ich mich fragte, warum eigentlich jeder andere Entwickler dieselbe Infrastruktur besitzen sollte.
Die Antwort war natürlich: gar nicht.
Die meisten Entwickler möchten ein Repository auschecken und direkt loslegen.
Sie möchten nicht zuerst mein Homelab nachbauen.
Also begann ich, Infrastruktur und Anwendung konsequent voneinander zu trennen.
Das Projekt beschreibt heute die Anwendung.
Meine persönliche Infrastruktur bleibt außerhalb des Projekts.
Für Entwickler ohne Traefik existieren zusätzliche Override-Dateien mit klassischen Portfreigaben.
Ich selbst nutze diese Dateien nicht.
Sie existieren ausschließlich für andere Entwickler.
Was zunächst wie ein kleines Detail klingt, hat meine Sicht auf Open Source nachhaltig verändert.
Docker Compose hat mir etwas gezeigt, das ich jahrelang übersehen habe
Eine Funktion von Docker Compose hatte ich lange Zeit völlig unterschätzt.
Mehrere Compose-Dateien können automatisch zusammengeführt werden.
Eigentlich ist das keine neue Funktion.
Neu war für mich die Konsequenz daraus.
Plötzlich musste ich meine Infrastruktur nicht mehr in jedes Projekt hineintragen.
Und ich musste meine Projekte nicht mehr an meine Infrastruktur anpassen.
Beides konnte unabhängig voneinander existieren.
Für einen Softwarearchitekten klingt das fast banal.
Für meinen Alltag war es ein echter Gamechanger.
Und dann kam Paperless
Paperless war ursprünglich überhaupt nicht geplant.
Ich wollte Home Assistant betreiben.
Mehr nicht.
Aber genau hier zeigte sich der eigentliche Vorteil einer gut aufgebauten Infrastruktur.
Die Hürde, neue Dienste auszuprobieren, war plötzlich nahezu verschwunden.
Container starten.
Konfiguration anpassen.
Fertig.
Keine neue Hardware.
Keine neue VM.
Keine aufwendige Installation.
Einfach ausprobieren.
Paperless lief innerhalb kurzer Zeit produktiv.
Und was mich dort besonders überrascht hat, war OCR.
Meine letzten ernsthaften Erfahrungen mit OCR liegen viele Jahre zurück. Damals waren solche Lösungen häufig teuer, cloudbasiert oder mit laufenden Kosten verbunden.
Heute läuft OCR lokal als Open Source.
Volltextsuche inklusive.
Das hat mich ehrlich beeindruckt.
Die größte Überraschung waren am Ende 16 GB RAM
Vielleicht ist das die Erkenntnis, die mich am meisten überrascht hat.
Wenn man die Diskussionen im Internet verfolgt, könnte man schnell den Eindruck gewinnen, dass für ein Homelab mindestens ein halbes Rechenzentrum notwendig ist.
Die Realität sieht bei mir deutlich unspektakulärer aus.
Das gesamte System läuft auf einer Debian-basierten Infrastruktur mit 16 GB Arbeitsspeicher.
Trotzdem laufen darauf mittlerweile knapp 20 Container sowie mehrere Docker-Stacks aus meinen eigenen Open-Source-Projekten.
Ja, Docker ist heute der größte Speicherverbraucher des Systems.
Aber gleichzeitig ist Docker auch der Grund, warum dieses Setup überhaupt möglich ist.
Vor einigen Jahren hätte ich viele dieser Dienste vermutlich in separaten virtuellen Maschinen betrieben.
Heute teilen sie sich denselben Kernel und laufen erstaunlich effizient nebeneinander.
Das hätte ich in dieser Form selbst nicht erwartet.
Fazit
Wenn mich heute jemand fragen würde, was der größte Gewinn meines Homelabs war, würde ich vermutlich eine andere Antwort geben als noch vor einem Monat.
Nicht Home Assistant.
Nicht Paperless.
Nicht KI.
Der größte Gewinn ist eine Entwicklungsumgebung, die endlich mit meinen Projekten skaliert.
Eine Infrastruktur, die neue Anwendungen aufnehmen kann, ohne jedes Mal neu erfunden werden zu müssen.
Eine Plattform, die Reibung reduziert, statt neue Komplexität zu erzeugen.
Und vielleicht ist genau das die wichtigste Erkenntnis aus dem ersten Monat:
Gute Infrastruktur erkennt man nicht daran, wie viel Aufmerksamkeit sie erzeugt.
Sondern daran, wie wenig man über sie nachdenken muss.
