GitOps

Technical Definition

GitOps is an operational discipline for managing infrastructure and application configuration through declarative, version-controlled manifests, combined with automated agents that continuously reconcile the observed state of a target system against the state declared in a Git repository. A change is proposed as a commit or pull request, reviewed through normal version-control workflows, and merged; a reconciliation controller (running inside or alongside the target environment) then detects the change and applies it, typically using a pull-based model rather than a push-based deployment pipeline.

The three defining properties are: the repository as the single source of truth, declarative rather than imperative state definitions, and an automated reconciliation loop that continuously enforces convergence rather than applying changes once and stopping.

Operational Relevance

GitOps changes where operational risk concentrates. Because every change to production state passes through Git, the commit history becomes an audit trail, and rollback becomes a revert of a commit rather than a manual undo of live changes. This is materially different from imperative deployment pipelines, where the record of what was actually applied can drift from the record of what was intended.

Operationally, teams adopting GitOps must treat the Git repository itself as a critical control plane component. Access controls on the repository, branch protection, and review requirements become as operationally significant as access controls on the target infrastructure, because a compromised or misconfigured repository can propagate unwanted state automatically.

Architecture Relationship

GitOps depends on a reconciliation controller with sufficient permissions to observe and modify the target environment, a declarative state format the controller can parse (commonly YAML manifests), and a Git repository the controller can poll or receive webhook notifications from. The controller runs a continuous loop: read declared state, read observed state, compute the difference, and apply corrective actions to close that difference.

This relationship means GitOps is not itself a deployment tool; it is an operating pattern that specific tools implement (typically referred to as GitOps operators or controllers). The pattern is most commonly associated with container orchestration platforms, where a controller reconciles declared workload manifests against a running cluster, but the same pattern is applicable to other declarative infrastructure domains.

Example

Consider a team storing a set of deployment manifests in a Git repository. An engineer changes a resource limit value in a manifest file and opens a pull request. A reviewer approves the change and it is merged to the tracked branch. A reconciliation controller polling that repository detects the new commit, compares the updated manifest to the currently running configuration, and applies the resource limit change to the live workload. No engineer runs a manual apply command against the live environment; the controller performs the convergence step.

Misunderstanding

A common misunderstanding is that GitOps simply means storing configuration in Git or using Git as part of a CI/CD pipeline. Storing configuration files in Git is necessary but not sufficient: the defining characteristic is the continuous reconciliation loop that enforces the declared state, not the version-control step alone. A pipeline that pushes changes from Git to production once, on a triggered basis, without ongoing drift correction, implements a Git-triggered deployment pattern rather than GitOps in the strict operational sense.

Related Terms

• Declarative configuration
• Continuous reconciliation
• Infrastructure as code
• Pull-based deployment
• Configuration drift

Further Reading

Readers evaluating GitOps for a specific environment should confirm the reconciliation controller’s version, supported manifest formats and permission model against current vendor documentation before relying on version-specific behaviour, as reconciliation semantics and default settings vary between controller implementations and change between releases.

Verified Operational Checks and Next Steps

Before adopting a GitOps workflow in any environment beyond an isolated test, confirm the following in a non-production setting: that the reconciliation controller has only the minimum permissions needed to manage the intended resources (least privilege), that repository branch protection and review requirements are enforced before merge, and that a rollback path exists by reverting a commit and observing the controller reconcile back to the prior state. Treat any environment where these three checks cannot be demonstrated as not yet ready for production GitOps adoption, and escalate to a platform owner rather than proceeding.