This Tiny TMNT Homelab Is Cute Until You Realize It’s a Full Production Pipeline

# This Tiny TMNT Homelab Is Cute Until You Realize It’s a Full Production Pipeline ## The Sewer Lair Is Not Just a Theme A themed homelab can go wrong fast. Slap a few names from a cartoon onto a pile of machines, post a photo, and suddenly the whole thing feels like decoration pretending to be architecture. But this one has a better trick: the Teenage Mutant Ninja Turtles theme is the least interesting part, and that’s exactly why it works. The cluster is called `sewer-lair`, the Proxmox nodes are named `leonardo` and `donatello`, and yes, that gives the whole setup a little comic-book charm. But under the fun names is a small, real, opinionated platform built to learn the modern infrastructure chain the hard way: by running actual applications on it. The hardware is humble in the best possible way. Two HP EliteDesk 705 G4 Minis, each with an AMD Ryzen 5 PRO 2400GE, 16GB of RAM, NVMe storage, a TP-Link managed switch, and a WD NAS. That’s not the kind of spec sheet that wins a rack-flex contest. There’s no wall of enterprise servers, no screaming fans, no 10GbE religious war, no eBay SAN humming like a space heater in the corner. It’s compact. It’s practical. It’s the kind of gear that says, “I want to learn Kubernetes, not explain my electricity bill to my family.” And that is the real beauty of it. This isn’t just self-hosting for the sake of self-hosting. It’s a portfolio with cables. Proxmox at the bottom. VMs on top. k3s for Kubernetes. ArgoCD for GitOps. Longhorn for storage. Traefik for ingress. cert-manager and Let’s Encrypt for TLS. Cloudflare Tunnel and Access for external routing and protected services. Real apps living in the stack, not just demo pods blinking green on a dashboard. It’s small, but it has the shape of something much bigger. ## A Mini PC Cluster With Big Platform Energy There’s a reason tiny homelabs are more interesting than giant ones sometimes. A big lab can hide bad architecture behind excess hardware. More RAM, more disks, more nodes, more ports, more everything. A small lab has nowhere to hide. With two mini PCs and 16GB per node, every decision matters. How many VMs do you carve out? Where does the control plane live? What gets persistent storage? What runs outside Kubernetes? What deserves a dedicated VM? What breaks when one node is under disk pressure? The limits force real engineering instead of fantasy architecture. This setup makes a few smart choices. Proxmox VE runs the virtualization layer, with dedicated VMs for the k3s control plane, k3s worker, Home Assistant, and Cloudflared. That separation is clean enough to avoid turning the host into a junk drawer, while still keeping the environment understandable. The k3s VMs run Debian 13, which is a boring answer in the best possible sense. Kubernetes already brings enough chaos. The guest OS does not need to audition for attention. The stack itself is very much the “modern homelab becomes tiny platform team” starter kit: ArgoCD, App of Apps, namespaces for apps, infra, monitoring, storage, ArgoCD, Traefik, cert-manager, and Longhorn. That sounds like buzzword soup until you realize how much practical learning is packed into it. GitOps sync and prune behavior. PVC scheduling. Ingress routing. Certificate automation. DNS challenges. Storage failures. Database migration. Disk pressure. Every one of those topics is a trapdoor in real infrastructure, and this lab is walking through them one by one. One commenter called it “clean,” which is exactly the kind of short compliment that lands because it doesn’t need much else. Another noticed the mini PC and joked about using the same machine as a main PC while the builder uses it as server hardware. That’s the homelab economy in one sentence. One person’s daily driver is another person’s Kubernetes worker node. The hardware line between “desktop” and “server” has never been thinner, and tiny boxes like these are making that line look almost silly. ## GitOps Makes the Lab Feel Serious The strongest part of this build is not the hardware or the theme. It’s the workflow. Docker images are built locally, pushed to GitHub Container Registry, and deployed by ArgoCD from Git. That changes the whole personality of the lab. It stops being “I installed some stuff” and starts becoming “I have a delivery pipeline.” That matters because the modern infrastructure skill gap is rarely about installing one tool. It’s about understanding how changes move from code to container to registry to cluster to ingress to users without turning into a ritual of manual clicks. The App of Apps pattern is especially telling. It’s a little enterprise-flavored for a two-node homelab, sure, but that’s the point. A homelab is allowed to be slightly overbuilt when the goal is learning. Nobody needs ArgoCD to run a personal portfolio on two mini PCs. But if the goal is to understand how Git becomes infrastructure truth, then ArgoCD is not overkill. It’s the lesson. That lesson gets real once things break. The builder has already dealt with Longhorn volumes stuck or faulted, Kubernetes PVCs and storage scheduling, disk pressure on one k3s node, expanding a Debian root partition after increasing VM disk size, PostgreSQL migration into Kubernetes, Cloudflare Tunnel routing, Traefik host routing, and ArgoCD sync/prune behavior. That list is more valuable than the clean final diagram. The shiny architecture is the cover photo. The troubleshooting list is the actual education. There’s a difference between watching tutorials and carrying the pager for your own nonsense. When Longhorn gets weird, you learn what distributed storage means in practice. When PVCs don’t schedule, you learn that Kubernetes is not a magic storage vending machine. When disk pressure appears, you learn that “small cluster” also means “small blast radius, but also small margin.” When ArgoCD prunes something you didn’t expect, GitOps stops being a slogan and starts being a loaded weapon. This is why small real apps matter. The lab is running a personal portfolio, Proximity for the amateur radio community, Uptime Kuma, Home Assistant, a PUBG Portugal Team Discord bot, PostgreSQL, Traefik, ArgoCD, Longhorn, and Cloudflared. None of those are world-ending workloads. But they are real enough to punish sloppy changes. They have data, routes, certificates, uptime expectations, and little dependencies that make the system feel alive. ## The Cloudflare Tunnel Choice Is Practical, Not Pure The Cloudflare side of the setup is one of those choices that will always split people. Some people love Cloudflare Tunnel because it avoids opening inbound ports, handles public routing cleanly, and pairs nicely with Access for protected services. Others get twitchy about putting a big third party in the path of self-hosted infrastructure. Both reactions are fair. In a learning lab, though, Cloudflare Tunnel is a very practical move. It lets the builder focus on ingress, DNS, TLS, and identity-ish access patterns without turning the home router into a battlefield. The stack is tidy: Traefik v3, cert-manager, Let’s Encrypt wildcard certificates, Cloudflare DNS-01 challenge, Cloudflare Tunnel, and Cloudflare Access. That is a surprisingly complete edge story for two little boxes. It teaches the difference between internal service routing and public exposure. It makes TLS automation real. It makes DNS more than a thing you poke once and forget. It also creates enough moving parts that debugging becomes meaningful. There’s an argument that this is too much for a homelab. That a portfolio, a bot, and Home Assistant don’t need GitOps, wildcard certificates, Kubernetes ingress, and protected tunnels. But that criticism misses the point. The goal is not merely to host apps. The goal is to understand the whole chain: hardware to Proxmox, Proxmox to VMs, VMs to k3s, k3s to storage, storage to ingress, ingress to TLS, TLS to DNS, DNS to GitOps, GitOps to monitoring, monitoring to real applications. That chain is the product. Another commenter suggested adding Ansible automation and an internal Docker registry proxy to avoid Docker Hub pull limits. That’s exactly the kind of feedback a lab like this invites because the platform is already past “what should I install?” and into “how do I reduce toil?” Ansible could standardize VM setup, OS hardening, package installation, user management, and baseline configuration. A registry mirror or pull-through cache would make the cluster more resilient and less dependent on public registry mood swings. That’s not just adding toys. That’s sharpening the pipeline. The only caution is tool sprawl. Once a lab gets exciting, every tool starts looking like the next lesson. Ansible, Renovate, SOPS, external-secrets, Prometheus, Grafana, Loki, Velero, Talos, Cilium, Tailscale, Authentik, Harbor, MinIO — the menu never ends. The trick is adding tools because they solve a pain already felt, not because the diagram has room. ## Longhorn Is Where the Cute Lab Meets Reality Storage is where small Kubernetes labs either grow up or start lying to themselves. Longhorn is a smart choice for learning because it makes persistent volumes approachable, but it also exposes the hard truth that distributed storage on tiny nodes is not free. Replicas need space. Rebuilds need I/O. Nodes need breathing room. Disk pressure becomes a real event, not a theoretical warning in a dashboard. The builder has already seen Longhorn volumes stuck or faulted, which is annoying but also exactly the kind of pain that teaches the right lessons. Running PostgreSQL 16 inside the cluster makes that even more serious. Databases turn storage from “does the app start?” into “do I trust my data here?” Persistent volumes for apps, databases, uploads, logs, and bot data mean the lab is no longer stateless playtime. Backups, restore tests, retention, storage health, and failure simulation all become important. Uptime Kuma can tell you something is down. It can’t save a database that was never backed up properly. This is where a WD NAS in the environment could become more than background hardware. It can be part of a real backup strategy. Not just “I have a NAS, therefore I have backups,” but actual scheduled backups, tested restores, off-node copies, and maybe even an offsite path later. If the whole point is learning the full chain, backup and restore deserve a starring role. A platform is not mature when it deploys smoothly. It’s mature when it can recover cleanly. There’s also the two-node reality. A two-node Proxmox cluster and two-node k3s layout can teach a lot, but it has quorum and availability limitations. That doesn’t make it bad. It makes it honest. A third tiny node, even something low-power, could change the shape of the system by giving the cluster a better witness story. But the right answer depends on whether the builder wants low power and simplicity or more realistic failure behavior. Someone made the usual electricity comment, saying the setup must be burning a lot. Compared with full-size servers, it probably isn’t. Two EliteDesk minis, a switch, and a NAS are not exactly a data center bonfire. That’s part of why the build works. It sits in the sweet spot where it can stay on long enough to be useful without becoming a utility-bill villain. ## A Portfolio Project With Teeth What makes this homelab stand out is that it understands something many lab builds miss: aesthetics can get attention, but operations create value. The TMNT naming scheme is fun. The photos are clean. The mini PCs are charming. But the real story is the operational loop: build, push, deploy, route, secure, monitor, break, fix, repeat. That is the loop people get paid to understand. There are three reactions to a build like this. The first is pure admiration: it’s clean, compact, themed, and running a serious modern stack. The second is skepticism: it’s too much for two mini PCs, too many moving parts, too Kubernetes-heavy for simple apps, too dependent on Cloudflare, too fragile with Longhorn on small nodes. The third is the most useful: yes, it’s overbuilt if the goal is hosting, but it’s appropriately built if the goal is learning. That third view is the right one. A homelab does not have to be the simplest way to serve a web page. It can be a deliberate obstacle course. This one is teaching Kubernetes, GitOps, storage, ingress, TLS, DNS, monitoring, and real application operations in a single compact system. That’s not waste. That’s curriculum. The next improvements should probably be boring, which is a compliment. Add Ansible for repeatable VM and host prep. Add a registry cache or internal registry. Add proper secret management. Add backup and restore drills. Add monitoring that tracks node health, Longhorn health, certificate expiry, tunnel status, and storage pressure. Add documentation so the whole thing can be rebuilt instead of merely admired. Maybe add a third quorum-friendly node if availability testing becomes the next frontier. The sewer-lair theme makes the lab memorable. The stack makes it useful. The troubleshooting makes it real. And the fact that it’s only a few days old makes the whole thing even better, because the real test is not whether it looks clean on day three. It’s whether it still feels clean after thirty days, after the first bad upgrade, after a Longhorn rebuild, after a certificate surprise, after an ArgoCD prune mistake, after the first restore test that either works or ruins your evening. That’s when a homelab stops being a showcase and becomes a teacher. This one is already halfway there.