Why Gardener

What Gardener is

Gardener is an open-source Kubernetes cluster manager from SAP. It’s “Kubernetes that runs Kubernetes”. But what does this mean?

The architecture has three layers. A Garden cluster is the control plane of the whole system; it holds the operator’s configuration and orchestrates everything else. Seed clusters host the control planes of your workload clusters. This is also known as “Kubeception” (I don’t know why, but I like this word): Kubernetes in Kubernetes. The nice benefit is, that your controlplanes are virtualized in another cluster. This saves resources, is still highly available, and you can hibernate clusters, which deletes all the costly worker nodes and loadbalancers. It’s managed by Gardener. Then there are Shoot clusters, which carry your actual workload.This is also managed by Gardener. You define seeds and shoots in your Garden and and Gardener makes them happen on Hetzner Cloud or other supported infrastructure.

This architecture is battle-tested at a scale most platforms never reach. It powers SAP’s own Kubernetes service, T-Systems’ Open Sovereign Cloud, STACKIT’s cloud and several other commercial offerings. The people who built it have operated fleets of thousands of clusters in production for years. You will feel this all the time when tending your own little Garden. In a good way.

Why fleet tech is great for one person

Here is the counterintuitive part. Gardener was designed so a platform team can run hundreds of clusters cheaply and uniformly — automated lifecycle, consistent configuration, no snowflakes. That same design is what makes it viable for an indie hacker with an agent.

Without the fleet tech, even running a single cluster is tedious. I believe the first cluster is the hardest. You need to take care of integration with the underlying infrastructure, put many services on top, configure VPNs, integrate with surrounding services, and setup your CI/CD pipeline. When you really do it well, the others are a piece of cake. In a way, the first cluster is the problem Gardener solves extremely well. So well, that it works with hundreds or thousands of clusters. Every cluster is defined declaratively. Upgrades happen through the same path for all of them. Monitoring is consistent. Nothing is a special case.

That uniformity is what makes this great. You will have not just one cluster, because clusters become extremely easy to create, and are cheap, especially when you only run them for a few days. A cluster is in practice just a YAML document you can watch your agent rite and Gardener will reconcile it into existence. As you can set strict guardrails and you can always throw it away and do it again, this does not feel fragile or insecure, in any way.

The trade-offs

Gardener itself is still quite heavyweight on infrastructure and can be hard to understand and setup, initially. This is where I want to help with this site. I have managed to setup my Garden with my life cluster on less than 100 EUR/Month infrastructure. In June 2026, I must say, as the prices seem to rise every month now. For comparison, I had about 40 EUR/Month costs for Dokku based setup which consisted of two servers, one prod, one non prod and some storage. It’s more than twice as expensive. The overhead seems to make no sense to self-host Gardener for a single cluster. This will never be as cheap as a single server, but you get a flexibility and stability, you never get with a single server. And even just not having to worry about downtimes for updates makes it worthwhile for me.