GitOps

What is GitOps?

GitOps is an operational model for managing infrastructure and application deployments where Git is the single source of truth for the desired state of your system, and automated agents continuously reconcile the live system to match what’s declared in Git. Instead of engineers running deploy commands or clicking in consoles to change production, they change the declarative configuration in a Git repository, and an automated controller detects the change and applies it to the cluster — and, crucially, continuously watches to ensure the live state never drifts from the Git-declared state. It emerged in the Kubernetes world and is closely associated with tools like Argo CD and Flux.

The core principles and why they matter

GitOps rests on a few tightly-connected ideas. Declarative: the entire desired state of the system (deployments, services, config, and often infrastructure) is expressed declaratively — you describe what you want, not the imperative steps to get there — which is what makes it reconcilable. Versioned and immutable in Git: because desired state lives in Git, you get everything Git provides for free — full history, code review on infrastructure changes (via pull/merge requests), audit trail of who changed what and when, and trivial rollback (revert the commit and the system reconciles back to the previous state). Pulled automatically and continuously reconciled: an in-cluster agent pulls the desired state from Git and applies it, and — this is the distinctive part — it runs a continuous reconciliation loop comparing actual state to desired state and correcting any divergence. That reconciliation loop delivers two big benefits: drift correction (if someone manually changes something in the cluster, the agent detects the drift from Git and reverts it, so the cluster can’t silently diverge from its declared config) and a degree of self-healing (deleted or altered resources are restored to their declared state). The pull model (agent inside the cluster pulls from Git) is also more secure than traditional push-based CI/CD deployment, because your CI system doesn’t need powerful cluster credentials — the cluster reaches out to Git rather than an external system reaching in with admin access.

The benefits, and the realities to respect

The payoff of GitOps is substantial: auditability and compliance (every production change is a reviewed, attributed Git commit — a compliance dream compared to ad-hoc console changes), easy and reliable rollback (git revert), consistency and drift-free environments, improved security (pull model, no external system holding cluster admin keys, and no humans making manual production changes), and a clear, reproducible process where the repo is the deployment. It’s become a leading pattern for Kubernetes operations for these reasons. But it isn’t free, and the honest caveats matter. Secrets management is the classic hard problem: you can’t just commit plaintext secrets to Git, so GitOps requires a proper approach — encrypted secrets in Git (Sealed Secrets, SOPS) or an external secrets manager the cluster reads from — and getting this wrong (committing credentials to the repo) is a serious exposure. It has a learning curve and operational overhead: running and maintaining the GitOps controllers, structuring repositories well (app config vs environment overlays), and handling promotion across environments takes real setup. Not everything fits neatly: some operational actions are awkward to express purely declaratively, and debugging “why isn’t my change reconciling?” introduces a new failure surface. And GitOps assumes discipline — its guarantees only hold if people stop making manual changes and route everything through Git; a team that keeps hot-fixing the cluster directly undermines the entire model (though drift correction will fight them). The recurring mistakes: committing secrets to Git, expecting GitOps to work while still making out-of-band manual changes, and underestimating the repo-structure and secrets-management work required to do it properly.

What people get wrong

• Committing secrets to Git — plaintext credentials in the source-of-truth repo is a serious exposure; GitOps needs encrypted secrets (SOPS/Sealed Secrets) or an external secrets manager.
• Still making manual changes: GitOps’s guarantees (audit, no drift, reliable rollback) hold only if all changes go through Git — out-of-band console fixes break the model and get reverted by reconciliation.
• Underestimating the setup — controllers, repo structure, and environment-promotion workflows take real effort; GitOps is an operating discipline, not just a tool you install.

Primary source: OpenGitOps principles