Infrastructure as code establishes that infrastructure should be defined in version-controlled configuration rather than provisioned by hand. GitOps takes that idea a specific step further, adding an operational model — not just a way of writing configuration, but a way of continuously enforcing it.

The core idea: Git as the single source of truth

GitOps treats a Git repository as the authoritative, single source of truth for what a system’s desired state should be — not just for infrastructure definitions, but often for application deployment configuration too. The OpenGitOps project, a CNCF-sponsored effort to define the practice formally, describes its core principles: the desired state of a system is declaratively expressed and versioned in Git, and that state is continuously and automatically reconciled with the actual live system.

That word “continuously” is the key difference from simply running terraform apply by hand or in a one-off pipeline job. In a GitOps model, a dedicated agent — running inside the target environment, not just triggered externally — constantly compares the live system’s actual state against what’s declared in Git, and automatically corrects any drift back toward the declared state, without a human needing to notice the discrepancy and trigger a fix.

How this differs from a standard CI/CD pipeline

A conventional CI/CD pipeline, covered in detail elsewhere on this site, typically pushes changes outward: a pipeline runs, builds, tests, and then pushes a deployment to the target environment. GitOps inverts part of this model: the in-cluster agent pulls the desired state from Git and reconciles toward it, rather than an external process pushing changes in. This pull-based model has a specific security benefit — the deployment agent needs read access to the Git repository, but the CI system itself doesn’t need standing write credentials into the production environment, which shrinks a category of credential exposure discussed in Secrets Management in CI/CD Pipelines.

Drift correction: the practical payoff

Because GitOps continuously reconciles live state against the declared state in Git, a manual, out-of-band change — someone directly editing a production configuration outside the normal process — doesn’t quietly persist. The reconciliation loop detects the difference and reverts it back to what Git declares, on its own schedule, without anyone needing to notice and intervene. This directly addresses the configuration drift problem discussed in Infrastructure as Code: How Tools Like Terraform Actually Work: drift isn’t just detected eventually during an audit, it’s actively and continuously corrected.

Everything as a reviewable, auditable change

A direct consequence of treating Git as the source of truth is that every change to the system’s desired state goes through Git’s existing mechanisms: commits, pull requests, code review, and a complete history of who changed what and when. This gives infrastructure and deployment changes the same review and audit trail that’s long been standard for application code changes — which is also what makes GitOps a natural fit for monorepo versus polyrepo decisions, since it raises the same questions about where configuration for many services should actually live.

What GitOps doesn’t solve on its own

GitOps is an operational pattern for reconciling state, not a replacement for good infrastructure-as-code practices underneath it — a poorly designed or undocumented configuration is just as poorly designed whether or not a GitOps agent is continuously reconciling toward it. It also doesn’t eliminate the need for the testing and validation stages of a CI/CD pipeline; GitOps typically governs the deployment and reconciliation stage specifically, after a change has already been built and tested.

Key takeaway

GitOps adds a continuous reconciliation loop on top of infrastructure as code: a Git repository declares desired state, and an automated agent keeps the live system matching it, correcting drift automatically rather than waiting for someone to notice. The practical payoffs are a stronger security posture around deployment credentials, automatic correction of manual out-of-band changes, and a full Git-based audit trail for every change to the system.

This article explains general GitOps concepts; specific tools and implementation details vary. See our disclaimer.