GitOps

GitOps is a way of operating infrastructure and software deployments in which a Git repository holds the single, authoritative description of how a system should look, and automation keeps the running system matching it. The name joins Git — the version-control system engineers use to track code changes — with operations. Instead of logging into servers and changing settings by hand, a team writes the desired state of its infrastructure and applications as declarative configuration files, commits them to Git, and lets tooling apply them. Because Git already records who changed what, when, and why, GitOps gives operations the same history, review, and rollback that source code enjoys. It is a practice from cloud-native software engineering, not a marketing technique, though the auditable, reviewable change it brings is valuable anywhere systems are managed as code.

The mechanics rest on two ideas: declarative configuration and continuous reconciliation. Declarative means you describe the end state you want — this many servers, this version of the app, these settings — rather than the steps to get there. A GitOps agent running in the environment continuously compares the live system to the state declared in Git and corrects any drift, so the repository stays the source of truth. Changes flow through Git itself: an engineer opens a pull request, the team reviews it, and once it merges, the automation rolls the change out. If something breaks, reverting the commit rolls the system back. Popular tools such as Argo CD and Flux implement this pattern for Kubernetes clusters, but the principle — desired state in Git, automation enforcing it — is broader than any single tool.

GitOps is easy to confuse with DevOps and with CI/CD, but they sit at different levels. DevOps is a broad culture and set of practices for bringing development and operations together to ship software faster and more reliably; it is a philosophy, not a specific mechanism. GitOps is a concrete way to put part of that philosophy into practice — specifically, how you manage and deploy infrastructure and applications, using Git as the control point. So DevOps is the wider goal, and GitOps is one opinionated method for reaching it. You can do DevOps without GitOps, but GitOps is squarely a DevOps practice, applying version control and automation to operations the way DevOps applies them to the whole delivery pipeline.

CI/CD — continuous integration and continuous delivery or deployment — is the pipeline that builds, tests, and ships code, and it overlaps with GitOps without being the same thing. Traditional CI/CD often pushes changes out to environments from the pipeline itself. GitOps flips the last step: rather than the pipeline pushing to the cluster, an agent inside the environment pulls the desired state from Git and reconciles to it. That pull-based model is the signature difference. In practice teams combine them — CI builds and tests the code, then updates the Git repository, and GitOps automation deploys from there. The distinction to keep is that CI/CD describes the delivery pipeline, while GitOps specifically makes Git the source of truth for the deployed state and uses reconciliation to enforce it.

Using GitOps well means being disciplined about what lives in Git and how changes reach it. Everything that defines the system — configuration, manifests, policies — belongs in the repository, so the repository truly is the source of truth and no one changes the environment out of band. Changes go through pull requests so they are reviewed and recorded, giving you an audit trail and easy rollback. Secrets need careful handling, since plain credentials must never sit in Git; teams use encryption or dedicated secret stores. Good GitOps also means keeping the declared state and the live state genuinely reconciled, so drift is caught and corrected rather than allowed to accumulate. The payoff is consistency across environments, faster recovery, and operations that are as reviewable and reversible as code.

The failures start when teams break the model's core promise. If engineers make manual changes directly on servers, the live system drifts from Git and the repository stops being the truth, so the audit trail lies. Committing secrets in plain text into the repository is a serious security mistake. Sprawling, disorganized repositories with no review discipline turn GitOps into version-controlled chaos rather than control. And treating GitOps as a silver bullet — adopting the tools without the culture of review, small changes, and reconciliation — yields little. The discipline is to keep every change flowing through Git, keep secrets out of it, review before merge, and let automation enforce the declared state, so operations gain the history, rollback, and consistency that made version control valuable for code in the first place.

GitOps combines Git, the version-control system, with operations, naming the practice of running infrastructure through a Git repository as its source of truth.

Etymology: source.

Search interest for this term over the last five years:

View interest-over-time on Google Trends →

Areas of marketing where gitops is a core concern: