Git takes ownership
Changes go through Git and Flux. This rule prevents a manual image or manifest update from fighting the declared state.
Case study · Kubernetes homelab
A small cluster built to expose real operational problems.
Three nodes, one control plane, two workers and enough services to meet the problems tutorials often leave out. The repository records decisions, incidents and system limits.
Explore the repository3Kubernetes nodes
GitOpswith Flux and Helm
NFSshared storage
CIchecks outside the cluster
01 / 04
Current architecture
Flux reconciles manifests from the in-cluster Forgejo instance. Local charts describe project-specific services. Infisical injects runtime secrets, while a Synology NAS provides shared persistent storage.
02 / 04
Decisions that mattered
Storage leaves the workers
Local persistent volumes depended on one worker. The affected workloads now use NFS-backed PVCs on the NAS.
Secrets stay out of the repository
Infisical supplies credentials at runtime. CI also searches for secrets committed by mistake.
CI works without the cluster
Scripts render charts, validate Kubernetes schemas and enforce a storage policy before a change reaches the cluster.
03 / 04
Path of a change
- 01
Commit
A chart or configuration change enters Git.
- 02
Check
Gitleaks, Helm rendering, kubeconform and storage rules inspect it.
- 03
Reconcile
Flux reads the Git source and applies the declared state.
- 04
Observe
Prometheus, Grafana and Loki provide signals after deployment.
04 / 04
What the system does not claim to be
This homelab is not a production-ready Kubernetes distribution. The control plane is a single node, the NAS is a central dependency, some services have one replica and several workloads depend on the available hardware. Those risks are accepted and documented, not hidden.
The repository contains the manifests, checks and runbooks.
Its public architecture and recovery procedures make the engineering choices open to inspection.
Read the code and documentation