GitOps — Trivia & Interesting Facts¶
Surprising, historical, and little-known facts about GitOps.
GitOps is a set of principles, not a specific tool¶
Despite being closely associated with Argo CD and Flux, GitOps is a set of principles: declarative configuration, versioned and immutable desired state, automatically applied changes, and continuous reconciliation. Any tool that implements these principles qualifies as "GitOps," including custom scripts, Terraform with automation, and even Ansible with Git triggers.
The OpenGitOps project formalized the principles in 2021¶
The CNCF's OpenGitOps project, launched in 2021, created a formal specification of GitOps principles to end confusion about what "GitOps" actually means. The four principles — declarative, versioned and immutable, pulled automatically, and continuously reconciled — were ratified as version 1.0, providing an authoritative definition.
Pull-based GitOps was a direct response to webhook-based CD security concerns¶
The "pull" model in GitOps — where an agent inside the cluster pulls desired state from Git, rather than an external system pushing changes in — was designed to address security concerns. In a pull model, the cluster never needs to expose the Kubernetes API externally, and Git credentials never leave the cluster.
GitOps creates a complete audit trail for free¶
Because every change to infrastructure goes through a Git commit, GitOps provides a complete, immutable audit trail without any additional tooling. Every change has an author, timestamp, reviewer (via pull requests), and can be reverted. Compliance teams love this because it satisfies audit requirements that previously needed expensive dedicated tools.
Drift detection is GitOps' killer feature¶
GitOps' continuous reconciliation detects and optionally corrects "drift" — when the actual state of infrastructure diverges from the declared state in Git. This catches manual changes ("kubectl edit" in production), failed deployments, and resource modifications by other systems. Without GitOps, drift accumulates silently until it causes an incident.
The "Git as single source of truth" concept breaks down with secrets¶
Storing secrets in Git (even encrypted) is the most debated aspect of GitOps. Tools like Sealed Secrets, SOPS, and External Secrets Operator exist to bridge the gap between "everything in Git" and "secrets shouldn't be in Git." There's no consensus on the best approach, and every GitOps team eventually has to make a pragmatic compromise.
GitOps adoption doubles the number of Git repositories¶
Organizations adopting GitOps typically create separate "config repositories" alongside their application code repositories. A team with 10 microservices might end up with 10 code repos and 10 config repos (or one monorepo for configs). This repository proliferation is the most common complaint from teams adopting GitOps at scale.
Flux was the original GitOps tool, predating the term itself¶
Weaveworks' Flux was running in production before the term "GitOps" was coined. The tool existed first; the philosophy was named afterward. This is unusual — most tech movements start with a manifesto and then build tools. GitOps was a case of practitioners naming a pattern they were already successfully using.
Multi-cluster GitOps is where most implementations struggle¶
Managing a single Kubernetes cluster with GitOps is well-understood. Managing 10-100 clusters — with environment promotion, cluster-specific overrides, and coordinated rollouts — is where most GitOps implementations break down. ApplicationSets in Argo CD and Kustomize overlays help, but multi-cluster GitOps remains a significant operational challenge.
GitOps doesn't eliminate the need for imperative operations¶
Despite the "everything declarative" philosophy, real-world GitOps deployments still require imperative operations: database migrations, one-time data backups, certificate rotations, and emergency rollbacks. The GitOps community is still developing patterns for handling these "day 2 operations" within a declarative framework.