Dieses winzige TMNT-Homelab ist niedlich - bis Sie merken, dass es eine vollständige Produktionspipeline ist
Der Kanal-Unterschlupf ist nicht nur 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. Aber 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 gesamten Setup einen kleinen Comic-Charme. Aber unter den lustigen Namen steckt 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, einem TP-Link-Managed-Switch und einem WD-NAS. Das ist nicht die Art von Datenblatt, die einen Rack-Flex-Wettbewerb gewinnt. Es gibt keine Wand aus Enterprise-Servern, kein kreischendes Lüftergeräusch, keinen 10GbE-Glaubenskrieg, kein eBay-SAN, das wie ein Heizlüfter in der Ecke summt. Es ist kompakt. Es ist praktisch. Es ist die Art von Ausrüstung, die sagt: "Ich will Kubernetes lernen, nicht meiner Familie meine Stromrechnung erklären."
Und genau das ist die eigentliche Schönheit daran. Das ist nicht nur Self-Hosting um des Self-Hostings willen. Es ist 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. Echte Apps, die im Stack leben, nicht nur Demo-Pods, die grün auf einem Dashboard blinken. Es ist klein, aber es hat 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? 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. Disk-Druck. Jedes dieser Themen ist eine Falltür in echter Infrastruktur, und dieses Lab durchschreitet sie eines nach dem 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 diese Grenze fast albern aussehen.
GitOps macht das Lab ernst
Der stärkste Teil dieses Builds ist nicht die Hardware oder das Thema. Es ist 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. Es geht darum 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. Aber wenn das Ziel ist zu verstehen, wie Git zur Infrastruktur-Wahrheit wird, dann ist ArgoCD kein Overkill. Es ist die Lektion.
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-/Prune-Verhalten herumgeschlagen. Diese Liste ist wertvoller als das saubere finale Diagramm. Die glänzende Architektur ist das Titelbild. Die Troubleshooting-Liste ist 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 "kleiner Explosionsradius, aber auch kleine Marge" bedeutet. 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, nicht rein
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. Es lehrt den Unterschied zwischen internem Service-Routing und öffentlicher Exposition. Es macht TLS-Automatisierung real. Es macht DNS zu mehr als etwas, das man einmal anfasst und vergisst. Es schafft auch 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. Aber diese Kritik verpasst den Punkt. Das Ziel ist nicht nur, Apps zu hosten. 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. Diese Kette ist das Produkt.
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. Das sind nicht nur zusätzliche Spielzeuge. Das ist das Schärfen der Pipeline.
Die einzige Vorsicht gilt der Tool-Ausbreitung. 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, 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 legt auch die harte Wahrheit offen, 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, nicht 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. 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. Nicht nur "Ich habe ein NAS, also habe ich Backups", sondern tatsächliche geplante Backups, getestete Restores, Off-Node-Kopien und vielleicht sogar später ein Offsite-Pfad. Wenn der ganze Sinn darin besteht, die gesamte Kette zu lernen, verdient Backup und Restore eine Hauptrolle. Eine Plattform ist nicht reif, wenn sie reibungslos deployt. Sie ist reif, 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 es nicht schlecht. Es macht es 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. Aber 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. 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. Aber 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.
Es gibt drei Reaktionen auf einen Build wie diesen. 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: Ja, es ist überbaut, wenn das Ziel Hosting ist, aber es ist angemessen gebaut, wenn das Ziel Lernen ist.
Diese dritte Sichtweise ist die richtige. 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. Das ist keine Verschwendung. Das ist Lehrplan.
Die nächsten Verbesserungen sollten wahrscheinlich langweilig sein, was ein Kompliment ist. Ansible für wiederholbare VM- und Host-Vorbereitung hinzufügen. Einen Registry-Cache oder eine interne Registry hinzufügen. Richtiges Secret-Management hinzufügen. Backup- und Restore-Übungen hinzufügen. Monitoring hinzufügen, das Node-Gesundheit, Longhorn-Gesundheit, Zertifikatsablauf, Tunnel-Status und Storage-Druck verfolgt. Dokumentation hinzufügen, damit das Ganze wiederaufgebaut statt nur bewundert werden kann. Vielleicht einen dritten Quorum-freundlichen Node hinzufügen, 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 der eigentliche Test ist nicht, ob es am dritten Tag sauber aussieht. Es 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.
Das ist der Moment, in dem ein Homelab aufhört, ein Schaufenster zu sein, und zum Lehrer wird. Dieses hier ist bereits auf halbem Weg dorthin.