Tiny TMNT Homelab Is Cute, but It Runs a Full Production Pipeline

The sewer lair theme is the least interesting part

A themed homelab can go wrong fast. Slap a few cartoon names onto a pile of machines, post a photo, and the whole thing starts to feel like decoration pretending to be architecture. This one gets away with it because the Teenage Mutant Ninja Turtles theme is the least interesting thing about it. The cluster is called sewer-lair, the Proxmox nodes are named leonardo and donatello, and yes, that gives the setup a little comic-book charm. 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 and NVMe storage, plus a TP-Link managed switch and a WD NAS. That spec sheet won't win a rack-flex contest. There's no wall of enterprise servers, no screaming fans, no 10GbE religious war, and no eBay SAN humming like a space heater in the corner. It's compact and practical, the kind of gear that says, "I want to learn Kubernetes, not explain my electricity bill to my family."

That's what I like about it. This is self-hosting with a purpose, closer to a portfolio with cables. Proxmox sits at the bottom with VMs on top, then k3s for Kubernetes, ArgoCD for GitOps, Longhorn for storage and Traefik for ingress. cert-manager and Let's Encrypt handle TLS, while Cloudflare Tunnel and Access take care of external routing and protected services. Real apps live in the stack, so it's more than 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

Sometimes tiny homelabs are more interesting than giant ones. 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, and 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, the k3s worker, Home Assistant and Cloudflared. That separation keeps the host from turning into a junk drawer while the environment stays understandable. The k3s VMs run Debian 13, which is a boring answer in the best sense. Kubernetes already brings enough chaos, and the guest OS does not need to audition for attention.

The stack itself is the starter kit for a modern homelab that has turned into a tiny platform team: ArgoCD, App of Apps, and namespaces for apps, infra, monitoring, storage, ArgoCD, Traefik, cert-manager and Longhorn. It sounds like buzzword soup until you count how much practical learning is packed into it, from GitOps sync and prune behavior, PVC scheduling and ingress routing to certificate automation, DNS challenges, storage failures, database migration and disk pressure. Every one of those is a trapdoor in real infrastructure, and this lab is walking through them one by one.

One commenter called it "clean," a 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 line between "desktop" and "server" has never been thinner, and tiny boxes like these make it look almost silly.

GitOps makes the lab feel serious

The strongest part of this build is the workflow, more than the hardware or the theme. Docker images are built locally, pushed to GitHub Container Registry, and deployed by ArgoCD from Git. That changes the personality of the lab from "I installed some stuff" to "I have a delivery pipeline." It 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 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. If the goal is to understand how Git becomes infrastructure truth, though, ArgoCD is the lesson itself.

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 worth more than the clean final diagram. The shiny architecture is the cover photo, and the troubleshooting list is where the education happens.

Watching tutorials is different from 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" means a small blast radius and also a small margin. And 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 runs 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, if not pure

The Cloudflare side of the setup will always split people. Some 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 edge stack is tidy: Traefik v3, cert-manager, Let's Encrypt wildcard certificates, the Cloudflare DNS-01 challenge, Cloudflare Tunnel and Cloudflare Access. That's a surprisingly complete edge story for two little boxes. It teaches the difference between internal service routing and public exposure, makes TLS automation real, and turns DNS into more than a thing you poke once and forget. It also has enough moving parts that debugging becomes meaningful.

You could argue 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. That criticism assumes the goal is hosting apps. Here 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, and 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. A lab like this invites exactly that kind of feedback, 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. Both of those would sharpen the pipeline, and neither is just another toy.

The one 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 you've 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 shows that distributed storage on tiny nodes has a cost. Replicas need space, rebuilds need I/O, and nodes need breathing room. Disk pressure becomes a real event instead of a theoretical warning in a dashboard. The builder has already seen Longhorn volumes stuck or faulted, which is annoying and also exactly the kind of pain that teaches the right lessons.

Running PostgreSQL 16 inside the cluster raises the stakes. A database turns the storage question from "does the app start?" into "do I trust my data here?" With persistent volumes for apps, databases, uploads, logs and bot data, the lab is no longer stateless playtime. Backups, restore tests, retention, storage health and failure simulation all start to matter. Uptime Kuma can tell you something is down. It can't save a database that was never backed up properly.

This is where the WD NAS could become more than background hardware and turn into part of a real backup strategy. "I have a NAS, therefore I have backups" doesn't count; what counts is scheduled backups, tested restores, off-node copies, and maybe an offsite path later. If the whole point is learning the full chain, backup and restore deserve a starring role. A platform that deploys smoothly still isn't mature until it can recover cleanly.

Then there's the two-node reality. A two-node Proxmox cluster and a two-node k3s layout can teach a lot, but they have quorum and availability limitations. That doesn't make the design bad, just honest. A third tiny node, even something low-power, could change the shape of the system by giving the cluster a better witness story. 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 hardly a data center bonfire, and 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

This homelab stands out because it understands something many lab builds miss: aesthetics get attention, but operations create value. The TMNT naming scheme is fun, the photos are clean and the mini PCs are charming. What matters more is the operational loop of build, push, deploy, route, secure, monitor, break, fix and repeat. That is the loop people get paid to understand.

A build like this draws three reactions. The first is pure admiration, because it's clean, compact, themed and running a serious modern stack. The second is skepticism: 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.

I'd side with that third view. A homelab does not have to be the simplest way to serve a web page, and 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 makes it a curriculum, and I wouldn't call it waste.

The next improvements should probably be boring, which is a compliment. Add Ansible for repeatable VM and host prep, a registry cache or internal registry, and proper secret management. Run backup and restore drills. Add monitoring that tracks node health, Longhorn health, certificate expiry, tunnel status and storage pressure, and write 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, and the troubleshooting makes it real. It's also only a few days old, which makes it more interesting to follow. Looking clean on day three is easy. The harder question is whether it still feels clean after thirty days, after the first bad upgrade, after a Longhorn rebuild, a certificate surprise, an ArgoCD prune mistake, and the first restore test that either works or ruins your evening. That's when a homelab stops being something to show off and becomes a teacher, and this one is already halfway there.