Overview
I run this homelab as a four-node Raspberry Pi 5 Kubernetes platform built on Talos Linux. ArgoCD reconciles the cluster from a public Git repository, giving me a realistic place to operate the same platform components together rather than testing each one in isolation.
It is production-inspired, but it is not production infrastructure. It is a learning and experimentation platform that I can take apart, rebuild and change as the repository evolves.
Motivation
I wanted an environment where I controlled the hardware, operating system and Kubernetes configuration. Running the platform exposes details that a diagram does not: reconciliation order, storage behaviour, secret delivery, networking failures and the work involved in upgrading components without losing sight of the whole cluster.
Goals
- Keep desired state reviewable in Git.
- Make routine changes reproducible rather than dependent on manual cluster edits.
- Manage networking, secrets, storage and observability as part of the platform.
- Run useful workloads while preserving space for experiments.
- Document decisions and trade-offs, not only installation steps.
Architecture
Four Raspberry Pi 5 nodes provide the physical foundation. Talos Linux supplies the API-managed operating system for Kubernetes. Cilium handles cluster networking, Longhorn provides persistent storage, External Secrets retrieves secret material from 1Password, and Prometheus and Grafana provide monitoring.
The ArgoCD structure keeps platform services and application workloads separate. Home Assistant and the other self-hosted applications sit above the platform components they depend on instead of being mixed into one set of manifests.
GitOps model
ArgoCD compares the public repository with the cluster and reconciles the declared state. I use an app-of-apps structure to bootstrap and compose the platform, with Helm and Kustomize handling package installation and configuration.
I chose this model so the path from a repository change to a running component remains visible. It also means ordering and dependencies need attention: a broken declaration can be applied just as reliably as a correct one.
Networking and ingress
Cilium provides Kubernetes networking, while ingress components expose selected services. I keep home-network addresses and internal names out of the public documentation because they add no value to understanding the design.
Networking problems are one reason I keep this environment running rather than treating it as a one-time installation. Routing and connectivity behaviour can be inspected alongside the manifests that describe the cluster.
Secrets management
I keep credentials outside Git. External Secrets retrieves values held in 1Password, while the application manifests describe which secret a workload needs without containing the value itself.
This keeps the repository useful and public without turning encrypted or encoded credentials into part of the project history. Secret delivery is still a dependency of the workloads, so a failed retrieval has to be visible during troubleshooting.
Storage
Longhorn provides persistent storage for workloads that cannot be recreated from configuration alone. This is also where the Raspberry Pi hardware is most visible as a constraint: the storage design and recovery options are not the same as those of a managed cloud service.
Observability
Prometheus collects metrics and Grafana makes them easier to inspect. I use that data to separate application behaviour from resource pressure, networking problems and node-level constraints when something does not behave as expected.
Applications
The cluster runs Home Assistant and other self-hosted applications. They make the environment useful day to day while exercising the same GitOps, secrets, storage and networking paths as the rest of the platform.
I keep application definitions separate from platform services so a change to a workload does not have to be understood as part of the cluster foundation.
Operational considerations
The lab borrows production practices where they help me operate it: changes are declarative, monitoring is part of the cluster, and recovery work is documented. The hardware and home setting still make it an experimentation environment rather than a production service.
The public portfolio website is intentionally hosted on Cloudflare Pages. A personal site should remain available independently of homelab maintenance, connectivity or experiments.
Decisions and trade-offs
I chose Talos Linux because its narrow, API-managed operating model fits a Kubernetes-only cluster. The trade-off is that familiar host-level administration is intentionally unavailable, so diagnosis and maintenance follow the Talos interfaces.
GitOps gives the repository a clear role as desired state, but adds reconciliation behaviour that I have to account for during failures. App-of-apps keeps the bootstrap path visible, but only stays understandable when the repository structure remains disciplined.
Raspberry Pi hardware keeps the cluster tangible and practical for experimentation. It also brings ARM compatibility, storage and resource constraints that would not shape every cloud or datacentre cluster in the same way.
Future improvements
The next improvements are driven by operating the cluster rather than by adding components for their own sake. Current priorities are clearer recovery documentation, sharper boundaries between platform and workloads, and evaluating upgrades against the limits of the hardware.
Repository
The public repository contains the declarative cluster configuration and supporting documentation. It is the best place to inspect the current implementation.