Dieses winzige TMNT-Homelab ist niedlich und zugleich eine vollständige Produktionspipeline
Der Kanal-Unterschlupf ist mehr als ein Thema
Ein thematisches Homelab kann schnell danebengehen. Ein paar Namen aus einer Zeichentrickserie auf einen Haufen Maschinen klatschen, ein Foto posten, und plötzlich fühlt sich das Ganze an wie Dekoration, die Architektur vortäuscht. Dieses hier hat einen besseren Trick: Das Teenage-Mutant-Ninja-Turtles-Thema ist der uninteressanteste Teil, und genau deshalb funktioniert es. Der Cluster heißt sewer-lair, die Proxmox-Nodes heißen leonardo und donatello, und ja, das verleiht dem Setup einen kleinen Comic-Charme. Unter den lustigen Namen steckt allerdings eine kleine, echte, meinungsstarke Plattform, gebaut, um die moderne Infrastrukturkette auf die harte Tour zu lernen: indem tatsächliche Anwendungen darauf laufen.
Die Hardware ist auf die bestmögliche Art bescheiden. Zwei HP EliteDesk 705 G4 Minis, jeder mit einem AMD Ryzen 5 PRO 2400GE, 16 GB RAM, NVMe-Storage, dazu ein TP-Link-Managed-Switch und ein WD-NAS. Mit diesem Datenblatt gewinnt man keinen Rack-Flex-Wettbewerb. Es gibt keine Wand aus Enterprise-Servern, kein kreischendes Lüftergeräusch, keinen 10GbE-Glaubenskrieg und kein eBay-SAN, das wie ein Heizlüfter in der Ecke summt. Das Ganze ist kompakt, praktisch und genau die Art von Ausrüstung, die sagt: "Ich will Kubernetes lernen, nicht meiner Familie meine Stromrechnung erklären."
Das macht den Reiz aus. Das hier ist Self-Hosting mit einem Zweck, ein Portfolio mit Kabeln: Proxmox ganz unten, VMs obendrauf, k3s für Kubernetes, ArgoCD für GitOps, Longhorn für Storage, Traefik für Ingress, cert-manager und Let's Encrypt für TLS, Cloudflare Tunnel und Access für externes Routing und geschützte Services. Darauf leben echte Apps und keine Demo-Pods, die grün auf einem Dashboard blinken. Das Setup ist klein, hat aber die Form von etwas viel Größerem.
Ein Mini-PC-Cluster mit großer Plattform-Energie
Es gibt einen Grund, warum winzige Homelabs manchmal interessanter sind als riesige. Ein großes Lab kann schlechte Architektur hinter überschüssiger Hardware verstecken: mehr RAM, mehr Disks, mehr Nodes, mehr Ports, mehr von allem. Ein kleines Lab hat nirgends, wo es sich verstecken kann. Mit zwei Mini-PCs und 16 GB pro Node zählt jede Entscheidung. Wie viele VMs teilt man ab? Wo lebt die Control Plane? Was bekommt persistenten Storage, was läuft außerhalb von Kubernetes, was verdient eine dedizierte VM, und was bricht, wenn ein Node unter Disk-Druck steht? Die Grenzen erzwingen echtes Engineering statt Fantasie-Architektur.
Dieses Setup trifft ein paar kluge Entscheidungen. Proxmox VE betreibt die Virtualisierungsschicht, mit dedizierten VMs für die k3s-Control-Plane, den k3s-Worker, Home Assistant und Cloudflared. Diese Trennung ist sauber genug, um zu verhindern, dass der Host zur Rumpelkammer wird, und hält die Umgebung dennoch verständlich. Die k3s-VMs laufen unter Debian 13, was im besten Sinne eine langweilige Antwort ist. Kubernetes bringt schon genug Chaos mit, das Gast-Betriebssystem muss nicht auch noch um Aufmerksamkeit buhlen.
Der Stack selbst ist ganz das Starter-Kit für "modernes Homelab wird winziges Plattform-Team": ArgoCD, App of Apps, Namespaces für Apps, Infra, Monitoring, Storage, ArgoCD, Traefik, cert-manager und Longhorn. Das klingt nach Buzzword-Suppe, bis man merkt, wie viel praktisches Lernen darin steckt. GitOps-Sync- und Prune-Verhalten, PVC-Scheduling, Ingress-Routing, Zertifikatsautomatisierung, DNS-Challenges, Storage-Ausfälle, Datenbankmigration und Disk-Druck sind in echter Infrastruktur alle eine Falltür, und dieses Lab durchschreitet sie eine nach der anderen.
Ein Kommentator nannte es "sauber", was genau die Art kurzes Kompliment ist, das trifft, weil es nicht viel mehr braucht. Ein anderer bemerkte den Mini-PC und witzelte, dass er dieselbe Maschine als Haupt-PC nutzt, während der Erbauer sie als Server-Hardware verwendet. Das ist die Homelab-Ökonomie in einem Satz: Der Alltagsrechner des einen ist der Kubernetes-Worker-Node des anderen. Die Hardware-Grenze zwischen "Desktop" und "Server" war nie dünner, und winzige Boxen wie diese lassen sie fast albern aussehen.
GitOps macht das Lab ernst
Am stärksten ist an diesem Build der Workflow. Docker-Images werden lokal gebaut, in die GitHub Container Registry gepusht und von ArgoCD aus Git deployt. Das verändert die ganze Persönlichkeit des Labs. Es hört auf, "Ich habe ein paar Sachen installiert" zu sein, und wird zu "Ich habe eine Delivery-Pipeline". Das zählt, weil die moderne Infrastruktur-Kompetenzlücke selten daran liegt, dass man ein einziges Tool installiert bekommt. Sie liegt daran zu verstehen, wie Änderungen von Code über Container zu Registry zu Cluster zu Ingress zu Nutzern wandern, ohne zu einem Ritual manueller Klicks zu werden.
Das App-of-Apps-Muster ist besonders aufschlussreich. Es ist etwas enterprise-lastig für ein Zwei-Node-Homelab, sicher, aber genau das ist der Punkt. Ein Homelab darf leicht überbaut sein, wenn das Ziel Lernen ist. Niemand braucht ArgoCD, um ein persönliches Portfolio auf zwei Mini-PCs zu betreiben. Wenn das Ziel aber ist zu verstehen, wie Git zur Infrastruktur-Wahrheit wird, dann liefert ArgoCD genau die Lektion, um die es geht.
Diese Lektion wird real, sobald Dinge kaputtgehen. Der Erbauer hat sich bereits mit festhängenden oder fehlerhaften Longhorn-Volumes, Kubernetes-PVCs und Storage-Scheduling, Disk-Druck auf einem k3s-Node, der Erweiterung einer Debian-Root-Partition nach Vergrößerung der VM-Disk-Größe, PostgreSQL-Migration in Kubernetes, Cloudflare-Tunnel-Routing, Traefik-Host-Routing und ArgoCD-Sync- und Prune-Verhalten herumgeschlagen. Diese Liste ist mehr wert als das saubere finale Diagramm. Die glänzende Architektur ist das Titelbild, die Troubleshooting-Liste die eigentliche Bildung.
Es gibt einen Unterschied zwischen dem Ansehen von Tutorials und dem Tragen des Pagers für den eigenen Unsinn. Wenn Longhorn seltsam wird, lernt man, was verteilter Storage in der Praxis bedeutet. Wenn PVCs nicht geschedult werden, lernt man, dass Kubernetes kein magischer Storage-Automat ist. Wenn Disk-Druck auftaucht, lernt man, dass "kleiner Cluster" auch kleinen Explosionsradius bei kleiner Marge bedeutet. Und wenn ArgoCD etwas prunt, das man nicht erwartet hat, hört GitOps auf, ein Slogan zu sein, und wird zu einer geladenen Waffe.
Deshalb zählen kleine, echte Apps. Das Lab betreibt ein persönliches Portfolio, Proximity für die Amateurfunk-Community, Uptime Kuma, Home Assistant, einen PUBG-Portugal-Team-Discord-Bot, PostgreSQL, Traefik, ArgoCD, Longhorn und Cloudflared. Keine davon sind weltbewegende Workloads, aber sie sind real genug, um schlampige Änderungen zu bestrafen. Sie haben Daten, Routen, Zertifikate, Uptime-Erwartungen und kleine Abhängigkeiten, die das System lebendig wirken lassen.
Die Cloudflare-Tunnel-Wahl ist praktisch
Die Cloudflare-Seite des Setups ist eine jener Entscheidungen, die immer die Meinungen spaltet. Manche lieben Cloudflare Tunnel, weil es das Öffnen eingehender Ports vermeidet, öffentliches Routing sauber handhabt und sich gut mit Access für geschützte Services kombiniert. Andere werden nervös, wenn ein großer Drittanbieter in den Pfad selbstgehosteter Infrastruktur gerät. Beide Reaktionen sind berechtigt. In einem Lernlabor ist Cloudflare Tunnel jedoch ein sehr praktischer Schritt. Es lässt den Erbauer sich auf Ingress, DNS, TLS und identitätsähnliche Zugriffsmuster konzentrieren, ohne den Heimrouter zum Schlachtfeld zu machen.
Der Stack ist aufgeräumt: Traefik v3, cert-manager, Let's-Encrypt-Wildcard-Zertifikate, Cloudflare-DNS-01-Challenge, Cloudflare Tunnel und Cloudflare Access. Das ist eine überraschend vollständige Edge-Geschichte für zwei kleine Boxen. Sie lehrt den Unterschied zwischen internem Service-Routing und öffentlicher Exposition, macht TLS-Automatisierung real und macht DNS zu mehr als etwas, das man einmal anfasst und vergisst. Sie schafft außerdem genug bewegliche Teile, damit Debugging bedeutsam wird.
Es gibt das Argument, dass das zu viel für ein Homelab ist, dass ein Portfolio, ein Bot und Home Assistant keine GitOps, Wildcard-Zertifikate, Kubernetes-Ingress und geschützte Tunnel brauchen. Diese Kritik verpasst den Punkt. Das Ziel ist, die gesamte Kette zu verstehen: Hardware zu Proxmox, Proxmox zu VMs, VMs zu k3s, k3s zu Storage, Storage zu Ingress, Ingress zu TLS, TLS zu DNS, DNS zu GitOps, GitOps zu Monitoring, Monitoring zu echten Anwendungen. Genau diese Kette soll das Lab vermitteln.
Ein anderer Kommentator schlug vor, Ansible-Automatisierung und einen internen Docker-Registry-Proxy hinzuzufügen, um Docker-Hub-Pull-Limits zu vermeiden. Das ist genau die Art von Feedback, die ein Lab wie dieses einlädt, weil die Plattform bereits über "Was sollte ich installieren?" hinaus ist und bei "Wie reduziere ich lästige Routinearbeit?" angekommen ist. Ansible könnte VM-Einrichtung, OS-Härtung, Paketinstallation, Nutzerverwaltung und Basiskonfiguration standardisieren. Ein Registry-Mirror oder Pull-Through-Cache würde den Cluster widerstandsfähiger und weniger abhängig von den Launen öffentlicher Registries machen. Beides würde die Pipeline schärfen.
Vorsicht ist nur bei der Tool-Ausbreitung geboten. Sobald ein Lab aufregend wird, sieht jedes Tool aus wie die nächste Lektion. Ansible, Renovate, SOPS, external-secrets, Prometheus, Grafana, Loki, Velero, Talos, Cilium, Tailscale, Authentik, Harbor, MinIO: die Liste hört nie auf. Der Trick besteht darin, Tools hinzuzufügen, weil sie einen bereits spürbaren Schmerz lösen, und nicht weil im Diagramm noch Platz ist.
Longhorn ist der Punkt, an dem das niedliche Lab auf die Realität trifft
Storage ist der Punkt, an dem kleine Kubernetes-Labs entweder erwachsen werden oder sich selbst etwas vormachen. Longhorn ist eine kluge Wahl zum Lernen, weil es persistente Volumes zugänglich macht, aber es zeigt auch deutlich, dass verteilter Storage auf winzigen Nodes nicht kostenlos ist. Repliken brauchen Platz, Rebuilds brauchen I/O, Nodes brauchen Luft zum Atmen. Disk-Druck wird zu einem echten Ereignis statt zu einer theoretischen Warnung auf einem Dashboard. Der Erbauer hat bereits festhängende oder fehlerhafte Longhorn-Volumes erlebt, was ärgerlich ist, aber auch genau die Art Schmerz, die die richtigen Lektionen lehrt.
PostgreSQL 16 im Cluster laufen zu lassen, macht das noch ernster. Datenbanken verwandeln Storage von "startet die App?" in "vertraue ich meinen Daten hier?" Persistente Volumes für Apps, Datenbanken, Uploads, Logs und Bot-Daten bedeuten, dass das Lab kein zustandsloses Spielzeug mehr ist. Backups, Restore-Tests, Retention, Storage-Gesundheit und Ausfallsimulation werden allesamt wichtig. Uptime Kuma kann Ihnen sagen, dass etwas ausgefallen ist, aber es kann keine Datenbank retten, die nie richtig gesichert wurde.
Hier könnte ein WD-NAS in der Umgebung zu mehr als Hintergrund-Hardware werden. Es kann Teil einer echten Backup-Strategie sein, mit geplanten Backups, getesteten Restores, Off-Node-Kopien und vielleicht später sogar einem Offsite-Pfad, statt nur dem Gefühl "Ich habe ein NAS, also habe ich Backups". Wenn der ganze Sinn darin besteht, die gesamte Kette zu lernen, verdienen Backup und Restore eine Hauptrolle. Reif ist eine Plattform erst, wenn sie sauber wiederherstellen kann.
Da ist auch die Zwei-Node-Realität. Ein Zwei-Node-Proxmox-Cluster und ein Zwei-Node-k3s-Layout können viel lehren, haben aber Quorum- und Verfügbarkeitseinschränkungen. Das macht das Setup ehrlich. Ein dritter winziger Node, selbst etwas Stromsparendes, könnte die Form des Systems verändern, indem er dem Cluster eine bessere Witness-Geschichte gibt. Die richtige Antwort hängt davon ab, ob der Erbauer geringen Stromverbrauch und Einfachheit will oder realistischeres Ausfallverhalten.
Jemand machte den üblichen Stromkommentar und sagte, das Setup müsse viel verbrauchen. Verglichen mit vollformatigen Servern ist das wahrscheinlich nicht der Fall. Zwei EliteDesk-Minis, ein Switch und ein NAS sind kein Rechenzentrum-Lagerfeuer, und das ist Teil dessen, warum der Build funktioniert. Er sitzt im Sweet Spot, in dem er lange genug eingeschaltet bleiben kann, um nützlich zu sein, ohne zum Stromrechnungs-Bösewicht zu werden.
Ein Portfolio-Projekt mit Biss
Was dieses Homelab hervorstechen lässt, ist, dass es etwas versteht, das viele Lab-Builds verpassen: Ästhetik kann Aufmerksamkeit bekommen, aber Operations schafft Wert. Das TMNT-Namensschema macht Spaß, die Fotos sind sauber, die Mini-PCs sind charmant. Die eigentliche Geschichte ist der operative Kreislauf: bauen, pushen, deployen, routen, absichern, überwachen, kaputtgehen, reparieren, wiederholen. Das ist der Kreislauf, für dessen Verständnis Menschen bezahlt werden.
Auf einen Build wie diesen gibt es drei Reaktionen. Die erste ist reine Bewunderung: sauber, kompakt, thematisch und mit einem ernsthaften modernen Stack. Die zweite ist Skepsis: zu viel für zwei Mini-PCs, zu viele bewegliche Teile, zu Kubernetes-lastig für einfache Apps, zu abhängig von Cloudflare, zu fragil mit Longhorn auf kleinen Nodes. Die dritte ist die nützlichste und meiner Meinung nach die richtige: Ja, es ist überbaut, wenn das Ziel Hosting ist, aber es ist angemessen gebaut, wenn das Ziel Lernen ist.
Ein Homelab muss nicht der einfachste Weg sein, eine Webseite auszuliefern. Es kann ein bewusster Hindernisparcours sein. Dieses hier lehrt Kubernetes, GitOps, Storage, Ingress, TLS, DNS, Monitoring und echten Anwendungsbetrieb in einem einzigen kompakten System. Zusammen ergibt das einen Lehrplan.
Die nächsten Verbesserungen sollten wahrscheinlich langweilig sein, was ein Kompliment ist. Ansible für wiederholbare VM- und Host-Vorbereitung, ein Registry-Cache oder eine interne Registry, richtiges Secret-Management, Backup- und Restore-Übungen und Monitoring, das Node-Gesundheit, Longhorn-Gesundheit, Zertifikatsablauf, Tunnel-Status und Storage-Druck verfolgt. Dazu Dokumentation, damit das Ganze wiederaufgebaut statt nur bewundert werden kann, und vielleicht ein dritter Quorum-freundlicher Node, falls Verfügbarkeitstests die nächste Grenze werden.
Das Sewer-Lair-Thema macht das Lab einprägsam, der Stack macht es nützlich, das Troubleshooting macht es real. Und die Tatsache, dass es erst wenige Tage alt ist, macht das Ganze noch besser, denn am dritten Tag sieht fast jedes Lab sauber aus. Der eigentliche Test ist, ob es sich nach dreißig Tagen noch sauber anfühlt, nach dem ersten schlechten Upgrade, nach einem Longhorn-Rebuild, nach einer Zertifikatsüberraschung, nach einem ArgoCD-Prune-Fehler, nach dem ersten Restore-Test, der entweder funktioniert oder den Abend ruiniert. Ab da hört ein Homelab auf, ein Schaufenster zu sein, und wird zum Lehrer. Dieses hier ist bereits auf halbem Weg dorthin.