The Future of My Homelab

Seven weeks ago, this cluster was a README placeholder. Today it runs 60 pods across 11 applications and 12 infrastructure components, all on a single Dell laptop with 15.6 GB of RAM. Flux reconciles from Git every 10 minutes. Every namespace has default-deny network policies. Secrets are encrypted at rest with SOPS. Prometheus watches everything, Loki aggregates logs, and ntfy pushes alerts to my phone.

It works. And I'm already thinking about what comes next.

The Elephant in the RAM

Memory utilization sits at 80%. That's 12.1 GB out of 15.6 GB, and the biggest consumer isn't even an application: it's Longhorn's instance-manager at 5.3 GB. That's a third of my node's entire memory budget consumed by the storage engine's internal bookkeeping.

The kube-apiserver takes another 1.5 GB (Talos-managed, can't tune it). Cilium needs 286 MB. Prometheus holds 560 MB of time-series data. By the time the infrastructure gets its share, there's about 4 GB left for actual workloads. On a 15.6 GB node, that's tight.

I've already right-sized resource limits across 14 components, reduced Longhorn CSI replicas, and tuned Prometheus retention. There's no more fat to trim. The laptop has given everything it has.

The NUC: Immediate Relief

An Intel NUC with 32 GB of RAM and a 500 GB NVMe is sitting on my shelf, waiting. I've already written the playbook for adding it as a worker node: the Cilium L2 policy fix, the Talos image build, the Longhorn replica expansion. It's the next physical change to the cluster.

The NUC doubles my compute capacity and triples my available application memory. More importantly, it gives Longhorn a second node for data replication. Right now, every persistent volume exists as a single copy on one disk. If that NVMe dies, I'm restoring from Longhorn snapshots and NFS backups. With two nodes, every volume gets a live replica: not backup-tier protection, but real redundancy.

What the NUC doesn't give me is high availability. The Dell stays as the sole control-plane node. If it goes down, the API server goes with it, and nothing in the cluster can be managed until it comes back. That's an accepted tradeoff for now.

The Third Node Question

True HA requires three control-plane nodes for etcd quorum. Two is worse than one (split-brain on any failure). Three means the cluster survives losing a node without losing its brain.

I think about this, but I'm not building it yet. Here's why:

Three control-plane nodes means three copies of etcd, three API servers, three controller-managers, three schedulers. On resource-constrained hardware, that's a lot of overhead for a homelab that serves one person. The Dell laptop and NUC together give me 47 GB of RAM. That's enough for every app I can think of running, with room to spare. The availability improvement is real, but the cost is dedicating another machine to infrastructure I only use from my couch.

If I add a third node, it'll probably be a small form-factor PC that can run etcd and a scheduler without needing to carry heavy workloads. Something like a used Lenovo Tiny or another NUC. The goal would be quorum resilience, not more compute. I'll already have plenty of that.

Longhorn's Memory Problem

I need to decide whether Longhorn is the right storage engine for this cluster long-term. It works, and the Kubernetes-native volume management is excellent. But 5.3 GB of memory for instance-manager on a single node is hard to justify. That's more than all my applications combined.

The alternatives I'm watching:

• OpenEBS Mayastor: NVMe-optimized, potentially lower memory overhead, but less mature than Longhorn
• Local-path-provisioner: Zero overhead, no replication, no snapshots: just directories on disk. Good enough for stateless apps, but I'd lose Longhorn's volume management for everything else
• Hybrid approach: Local-path for low-value volumes (IT-Tools config, Homepage cache), Longhorn for data I actually care about (Vaultwarden, Ghost, Prometheus). Fewer volumes under Longhorn management means less memory consumed by instance-manager

I'm not making this change tomorrow. But when the NUC joins and Longhorn spins up a second instance-manager, the memory cost doubles. That might force the decision.

Apps I Want to Run

The current stack covers my daily needs: RSS, music, bookmarks, budgeting, password management, monitoring. But there are gaps:

• Immich: Self-hosted photo management. This is the big one. Google Photos is the last cloud service I rely on for personal data, and Immich has reached the point where it's a credible replacement. The challenge is storage: my photo library is 200+ GB and growing. That's NFS-to-Unraid territory, not Longhorn.
• Paperless-ngx: Document management with OCR. I have a filing cabinet I'd rather not have. This pairs well with the NAS storage I already have set up.
• Gitea or Forgejo: Self-hosted Git. Not to replace GitHub: for private repos, automation scripts, and configs that don't belong on someone else's servers. Lightweight, runs on SQLite, fits the cluster well.
• Tandoor Recipes or re-enable Mealie: I disabled Mealie during the memory-saving purge. With the NUC's 32 GB, there's room to bring it back.

Each of these follows the same deployment pattern I've templated across 11 apps: namespace, deployment, service, ingress, network policies, PVC. The infrastructure work is done. Adding an app is 15 minutes of YAML and a commit.

Security: What Keeps Me Up

The cluster's security posture is good. Default-deny network policies everywhere. SOPS-encrypted secrets. Cloudflare Tunnel with no open ports. Authentik SSO with forward-auth on most services. But "good" isn't "done."

What I want to improve:

• External Secrets Operator: SOPS works, but every secret change requires encrypting a file and committing it. ESO pulling from a proper secret store (even a self-hosted one like Vault or CyberArk Conjur) would be cleaner and more auditable. This matters more as the secret count grows.
• Real TLS for LAN: Every *.homelab.local service uses self-signed certificates from cert-manager. My browser throws warnings, my phone complains, and automated health checks need to skip TLS verification. A proper internal CA (or even Let's Encrypt with DNS-01 challenges) would fix this permanently.
• Image scanning: Renovate updates my container images, but I don't scan them for vulnerabilities. Trivy running as a CronJob or admission controller would catch known CVEs before they deploy. This is table stakes in production. No reason not to do it in a homelab.
• Falco or runtime security: Network policies control what talks to what, but I have no visibility into what runs inside containers. Runtime security monitoring would catch unexpected process execution, file access, or syscalls. This is the professional security engineer in me talking. Probably overkill for a homelab, but I'd sleep better.

Observability Gaps

Prometheus and Grafana give me metrics. Loki and Alloy give me logs. I have alerts for pod crashes, high memory, and log-level panics. What I don't have:

• Distributed tracing: With two nodes and services talking across them, traces would help debug latency issues. OpenTelemetry with Tempo is the natural fit since Grafana already supports it. But this is a "nice to have": my services are mostly independent, not a microservices mesh.
• Uptime SLO tracking: Uptime Kuma tells me if something is up or down right now. I want to know my 30-day uptime percentage per service. That's a Prometheus recording rule and a Grafana dashboard away.
• Cost tracking: Not dollars. Resources. Which apps consume the most CPU, memory, and storage over time? Prometheus has the data. I just need dashboards that surface it in a way that helps me make allocation decisions when the NUC joins.

The GitOps Pipeline Gap

Right now, pushing to main is the deploy mechanism. No CI, no tests, no validation. Flux picks up whatever lands in the repo and applies it. This works because I'm the only committer and I review my own changes before pushing. But it's a gap I feel.

What I want:

• Pre-commit manifest validation: kubectl kustomize dry-run and kubeconform schema validation before changes reach the cluster. Catches typos, missing fields, and schema violations at commit time instead of during reconciliation.
• GitHub Actions for PRs: Lint YAML, validate Kustomize overlays, run kubeval against the target Kubernetes version. Renovate already creates PRs for dependency updates. Those PRs should pass automated checks before I merge them.
• Diff preview: Show me what Flux will change before it changes it. Flux has flux diff kustomization for this, but it's manual. Automating it in CI would make every PR self-documenting.

None of this is hard. It's just time I haven't allocated yet because the cluster hasn't broken in a way that would have been prevented by CI. When it does (and it will), I'll build the pipeline that same day.

When Is a Homelab "Done"?

Never. That's the point.

A homelab isn't a product with a release date. It's a workshop. The value isn't in the final state: it's in the building, the breaking, the rebuilding. Every component I've deployed taught me something I use at work. Cilium network policies translated directly to how I think about conditional access scoping. The Authentik SSO marathon taught me more about OIDC than any documentation ever could. Debugging Cloudflare Tunnel redirect loops gave me intuition about protocol-layer issues that no cert exam covers.

The future of this homelab is whatever I'm curious about next. Right now that's multi-node storage, image scanning, and getting my photos off Google. Next month it might be service mesh evaluation or building a proper internal CA. The infrastructure is mature enough now that adding capability is incremental: a Helm chart here, a network policy there, a commit and a 10-minute wait.

The hard part was building the platform. The fun part is what comes next.