onedr0p/home-ops: a GitOps home Kubernetes cluster you can read end to end

What onedr0p/home-ops actually is, and who it is for

The README opens by calling this a mono repository for one person's home infrastructure and Kubernetes cluster, and that framing matters. It is not a distribution, an operator, or a chart collection. It is the working configuration of a single cluster, kept in public so that the practices inside it can be copied.

The stated audience is implicit in the first paragraph: people who already accept Infrastructure as Code and GitOps and want to see those ideas applied to a real home setup rather than a demo. The README names Ansible, Terraform, Kubernetes, Flux, Renovate and GitHub Actions as the tools it tries to adhere to, and the repository layout backs that up. There is a bootstrap directory, a talos directory for machine configuration, and a kubernetes directory holding the cluster state.

The scope is deliberately narrow. The README describes the cluster as semi-hyper-converged: workloads and block storage share the same node resources, while a separate server with ZFS handles NFS and SMB shares, bulk file storage and backups. That split is a design decision, not an accident, and it tells you the author expects you to have more than one machine.

If you are looking for something to install and be running in an afternoon, this is the wrong repository. If you want to see how one person orders HelmRelease dependencies so that a database exists before the application that needs it, keep reading.

How Flux turns the kubernetes folder into a running cluster

The mechanism is recursive discovery. According to the README, Flux searches the kubernetes/apps folder recursively until it finds the most top level kustomization.yaml per directory, then applies every resource listed in it. That file generally contains a namespace resource and one or more Flux kustomizations, named ks.yaml in this repository. Each of those kustomizations then owns a HelmRelease or other application resources.

The result is a three-level hierarchy: a kustomization.yaml that declares a namespace and Flux kustomizations, a ks.yaml that defines the Flux kustomization itself, and the HelmRelease underneath it. Once you see that shape, the repository becomes navigable, because every application follows the same path. The README lists the three directories under kubernetes as apps for applications, components for reusable kustomize components, and flux for the Flux system configuration.

Dependency ordering is the part worth studying. The README states that a HelmRelease will usually depend on other HelmReleases, a Kustomization on other Kustomizations, and occasionally an app depends on both. Its example is concrete: atuin will not deploy or upgrade until the rook-ceph-cluster Helm release is installed or healthy. That is the mechanism that stops a storage-dependent application from starting against a Ceph cluster that has not finished forming.

Renovate sits alongside this. The README says it watches the entire repository for dependency updates and opens pull requests automatically. Merging a pull request is what causes Flux to apply the change. There is no separate deployment step, which is the whole point of the setup and also the whole risk.

Core components the cluster assumes before your first app

The README lists the components that everything else is built on, and the list is long enough that it functions as a prerequisite check. Cilium provides eBPF-based networking. Istio handles service-to-service communication with L7 proxying and traffic management. cloudflared secures ingress through Cloudflare, and external-dns keeps DNS records in sync automatically.

Security and secrets run through cert-manager for certificate management and external-secrets with 1Password Connect to inject secrets into Kubernetes. Storage is Rook for distributed persistent volumes, with kopiur handling backups and restores, and spegel running a stateless cluster-local OCI image mirror to improve reliability. Actions-runner-controller runs self-hosted GitHub Actions runners inside the cluster.

That is a lot of infrastructure to stand up before the first application appears. Each of those components has its own failure modes and upgrade path, and the README does not walk through any of them. It names what is used and moves on. The honest reading is that this repository documents the destination, not the route. The route is the cluster-template repository the README links to, which it describes as a way to follow along with some of the practices used here.

If you are deciding whether to adopt this pattern, count the components first. A home lab running Cilium, Istio, Rook, cert-manager, external-secrets and spegel is not a small surface area, and every one of them will eventually need attention at the same time you wanted to watch a film.

Installing from the template and reading your first Flux kustomization

The README does not give install commands for this repository. It points instead at onedr0p/cluster-template, described as a template for trying to follow along with the practices used here. That is the correct entry point, and the directory listing below is the one the README itself prints, so it doubles as a map of where to look first.

The README shows the contents of the kubernetes directory like this:

📁 kubernetes
├── 📁 apps       # applications
├── 📁 components # re-useable kustomize components
└── 📁 flux       # flux system configuration

That is the layout the recursive search operates on. The flux directory holds the system configuration, components holds reusable kustomize components, and apps holds the applications. Once you are inside apps, open any directory and read its kustomization.yaml first, then the ks.yaml it references. That pair is the unit of deployment, and reading two or three of them teaches the pattern faster than any description.

The README also gives the dependency graph in Mermaid form, and the part worth reading closely is the ordering between the storage layer and an application:

graph TD
    A>Kustomization: rook-ceph] -->|Creates| B[HelmRelease: rook-ceph]
    A>Kustomization: rook-ceph] -->|Creates| C[HelmRelease: rook-ceph-cluster]
    C>HelmRelease: rook-ceph-cluster] -->|Depends on| B>HelmRelease: rook-ceph]
    D>Kustomization: atuin] -->|Creates| E(HelmRelease: atuin)
    E>HelmRelease: atuin] -->

Read that as a contract: atuin does not deploy or upgrade until rook-ceph-cluster is installed or healthy. Copy the shape, not the names, because your cluster will have different storage prerequisites. The repository root also carries a .justfile and a .mise directory, so task running and tool version pinning are part of the workflow, but the README does not document the recipes or the pinned versions, so treat those files as the source of truth rather than expecting a documented install sequence.

Where this repository will not help you

The licence is WTFPL. That is permissive to the point of being unserious, and it means there is no warranty, no support commitment and no compatibility promise of any kind. You are copying configuration, and if it breaks your cluster, the licence says what it says.

The bigger limitation is that this is one cluster's configuration, tuned to one person's hardware and one person's accounts. The secrets layer depends on 1Password Connect. The ingress path depends on Cloudflare. The storage layer depends on Rook and on a separate ZFS server for bulk storage and backups. None of those are abstractions you can swap by editing a value; they are assumptions threaded through the applications.

There is also no documented rollback procedure. The README describes how changes flow in through Renovate pull requests and Flux reconciliation, but it does not describe what to do when a merged pull request leaves the cluster unhealthy. Git gives you the revert, but the README is silent on whether Flux will reconcile the cluster back cleanly, and on how long that takes for stateful workloads.

Finally, the README is a description, not a guide. It explains the Flux workflow at a high level and shows a Mermaid graph of dependency ordering, then stops. Anyone expecting step-by-step instructions for bootstrapping from bare metal will not find them here.

How this differs from a cluster-template style starting point

The natural comparison is onedr0p/cluster-template, which the README itself links as the way to follow along with these practices. The difference in approach is the difference between a snapshot and a scaffold. This repository is the snapshot: a complete, opinionated cluster with every application the author actually runs, including the ones specific to his household. The template is the scaffold: a starting structure meant to be filled in.

That distinction changes what you do with each. With a template you delete what you do not need and add your own applications into an empty pattern. With this repository you read, and you copy selectively, because pulling the whole thing in brings along assumptions about storage, secrets and ingress that were never written down as requirements.

A second comparison point is the broader k8s-at-home lineage, which the related searches around this project keep surfacing. That community produced chart collections and guides aimed at running services on Kubernetes at home. This repository takes a different route: it does not publish charts for others to consume, it publishes the cluster that consumes them. The reusable parts live in kubernetes/components, which the README describes as reusable kustomize components, and those are the pieces most likely to transfer to your own repository without dragging the rest along.

Maintenance cost and what the licence does not cover

The last push to the repository was on 2026-09-24, four days before this was written, so the project is being worked on. There are no retrieved releases, which fits a repository that ships configuration rather than artifacts. There is no version to pin and no changelog to read. The state of main is the state of the project.

That has a direct cost. Renovate opens pull requests against the entire repository, so the maintenance burden is continuous and lands as review work rather than as periodic upgrades. Every dependency in the cluster, from Cilium to the applications, arrives as a pull request that someone has to judge. For a single operator this is manageable because the pull requests are the workflow. For a team it would be a queue.

The WTFPL places the software in the public domain as far as its terms go. It offers no patent grant, no attribution requirement and no warranty. If you are copying configuration into a commercial or regulated environment, that absence of any explicit patent language is worth raising with whoever handles licensing, because the licence simply does not address it. Nothing here is legal advice, and the licence text is short enough to read in full in under a minute.

Frequently asked questions

The questions below cover what a new reader most often needs to know before deciding whether to clone this repository or start from the template it points to.

Editorial conclusion

Adopt it as a pattern, not as a deployment. Anyone running a Talos or Kubernetes home lab who wants to see how Flux kustomizations, HelmReleases and dependency ordering fit together will get more from reading kubernetes/apps than from any tutorial. Do not clone it expecting a working cluster: the secrets layer assumes 1Password Connect, the storage layer assumes Rook, and the template the README points at (onedr0p/cluster-template) is the actual starting point. Before committing, verify that the Flux kustomization layout in kubernetes/flux matches your own repository root, since the recursive search described in the README depends on where that entry point sits.

Frequently asked questions

Official sources

1. Issues
2. License: WTFPL
3. onedr0p/home-ops on GitHub
4. Project website
5. README