--- title: "The GitOps Paradox: Why Your Devs Need an API You Don't Want To Build weight: 13 tags: - platformengineeringday --- {{% button href="https://colocatedeventseu2026.sched.com/event/2DY82" style="error" icon="calendar" %}}Sched Link{{% /button %}} {{% button href="https://github.com/ConfigButler/gitops-reverser" style="info" icon="code" %}}Code{{% /button %}} {{% button href="https://revertgitops.dev" style="info" icon="link" %}}Website/Homepage{{% /button %}} ## Baseline - We all like files, humans like them, they are easy to use and AI can use them - Git is a good version manager - GitOps is cool and we want to keep it - **Problem**: I want to do something and now i need to create a yaml file and open a pr -> High toil - **Question**: Should git always be the primary entry path for changes - **Idea**: Use kubernetes api as our api server, have an operator that handels creation of manifests in git + promotions and so on and the changes to the "real" clusters are always made via gitopös ## The paradox - We shield people from the kubernetes api and force them to use git - We build our own custom apis on top of the kubeapi anyways - Solution: Why not go back to using the Kubernetes API (humans and robots can use it) ## Principles of the reverse gitops manifest 1. API first (via Kubeapi) to reuse auth, crds, status, controllers and more 2. Capture intent not implementation -> Not api-only (if you can do it bi-directional) with reversible&declarative resources 3. GitOps applies -> Changes are always piped through gitops for reviews, history, rollback, promotions, ... ## Implemantations examples - Use KRO as the abstraction that captures the intention - [GitOps Reverser](https://github.com/ConfigButler/gitops-reverser)