This blog will cover the decisions that lead to creating my own gitops tool and why I didn't just use ArgoCD or FluxCD.
And maybe why you should start creating your own custom tools
What is a gitops tool?
Before we start, what is a gitops tool?
A GitOps tool is software that helps you manage infrastructure and application deployments using Git as the source of truth.
The basic idea is that you store the desired configuration of your system in a Git repository. The GitOps tool continuously compares what is running with what Git says should be running. When Git changes, the tool applies those changes to the environment.
Why not using the existing tools?
Tools like ArgoCD and FluxCD are good, and you should use them in production environments - I am by no means recommending you use Cabure for production (though you can at your own risk!)
The issue I had was that it took way to long to set each up, and when you just want the gitops feel within Minikube or a homelab cluster deploying either of these is a quite a process.
They both have dozens of features, of which you probably are going to only use at most 6 (even that is being generous.) I needed something simpler, something more specific, something that fits how I want to work.
Out of this came Cabure: https://github.com/GreedyKomodoDragon/cabure
So what is Cabure?
From the README:
Cabure is a minimal GitOps operator for a single Kubernetes cluster. It watches GitApplication resources, checks out a Git repository, renders plain YAML or a local Helm chart, applies the result with Kubernetes Server-Side Apply, and prunes objects removed from Git using a stored inventory.
It does just that, no more, no less. I have no plans to do:
- A web UI or public API
- No MCPs
- Multi-cluster management.
- Kustomize, Jsonnet, CUE, or plugin-based rendering
- Remote Helm values files or OCI chart sources for user applications
- Cross-namespace secret access
By removing all of these features we can very easily deploy and debug the gitops process.
Its a single binary, you don't even need a PVC if you don't want to use cache.
Creating your own tools
Creating a tool that fits your exact needs almost always make it simpler to manage e.g you don't need to wrangle how ArgoCD reconciles in specific cases, you can just extend your own tool.
Drop features you don't care about anymore, open source and popular tools have to often provide backward compatibility. In your own tools you can do whatever you want.
With AI now this has become even easier, the first version of cabure was largely scoped out by AI agents and only once I understood what I wanted I took more control over it.
The real reason: Learn by making
Fundamentally I have a desire to learn how all of these tools I use everyday work. You could get an AI agent to read all of the code in that repo and get a very shallow understanding, you'd never remember what it said & likely just have wasted the tokens.
By building a vertical slice of the existing tool gives you a better understand of why tools like ArgoCD work they do. This allows you to better use those tools as well.
Even if you use AI you can still get a lot of these learnings, as long as you look at the code and review it. Which is not that different from getting code you didn't make from a colleague.
Top comments (0)