What Is GitOps? How Git-Driven Deployment Works

GitOps is a way of running software infrastructure where a Git repository, not a human operator or a one-off deployment script, is the single source of truth for what a system should look like. A desired state — Kubernetes manifests, Helm charts, or other configuration — lives in version control, and a software agent running inside the target environment continuously compares that declared state against what is actually running, then automatically pulls and applies any changes needed to make the two match. The approach is formalized by the CNCF-affiliated OpenGitOps project and implemented in practice by two CNCF-graduated tools, Argo CD and Flux.

The name comes from the practice of treating Git the way teams already treat it for application code: every change goes through a commit, a pull request, and a review, and the history of those commits becomes the audit trail for the entire system — not just the application, but the infrastructure and configuration around it too.

What problem GitOps actually solves

Most teams running Kubernetes before GitOps caught on used some variant of a push-based pipeline: a CI server builds an artifact, then a deploy step runs kubectl apply, helm upgrade, or a custom script that reaches out to the cluster's API server and pushes the new state in. That works, but it creates two recurring headaches.

First, the CI/CD system needs standing credentials with enough privilege to modify the cluster, and often that means long-lived, broadly scoped access sitting outside the cluster's own security perimeter. If the CI server is compromised, so is every environment it can reach. Second, nothing stops someone from making a manual, undocumented change directly against the cluster with kubectl edit or a dashboard click — and once that happens, the cluster's real state silently drifts away from whatever is in Git, with no record of who changed what or why.

GitOps flips the direction of the connection. Instead of an external system pushing into the cluster, an agent that lives inside the cluster pulls from Git. No outside system needs cluster-admin credentials, and because the in-cluster agent is always watching, it can also detect and reverse manual drift automatically, snapping the environment back to whatever Git says it should be.

The four OpenGitOps principles

The CNCF's GitOps Working Group, through the OpenGitOps project, defines GitOps with four specific principles rather than a loose description. Any system that satisfies all four can reasonably call itself GitOps.

That last principle is the one that separates GitOps from "we deploy from Git sometimes." A one-time pull on merge is not GitOps; a loop that keeps checking and correcting, indefinitely, is.

How the reconciliation loop works in practice

In both major GitOps tools, the loop looks roughly the same. A controller running inside the Kubernetes cluster watches one or more Git repositories (or, increasingly, OCI registries). On an interval, or when triggered by a webhook, it fetches the latest committed state, compares it to what is actually deployed, and computes a diff.

In Argo CD, this comparison step is literally called a "refresh": the controller compares the latest code in Git with the live cluster state to figure out what is different, then reports the result as a sync status — Synced if the two match, OutOfSync if they don't. Depending on configuration, Argo CD can then sync automatically or wait for a human to click approve.

Flux breaks the same idea into composable pieces: a GitRepository source object defines where the desired state lives, and a Kustomization object reconciles a set of resources against it on a schedule — every five minutes by default. Flux's own documentation is explicit about the drift-correction behavior this produces: manual changes made with kubectl edit, patch, or delete against a reconciled resource "will be promptly reverted."

Both projects are maintained under the Cloud Native Computing Foundation. Flux reached CNCF Graduated status on November 30, 2022, and the Argo project (which includes Argo CD) graduated days later, on December 6, 2022, according to the CNCF's own announcements — the top maturity level the foundation grants, reserved for projects it considers broadly adopted and operationally proven.

Argo CD vs. Flux, at a glance

Neither tool is strictly "better" — Argo CD's UI-centric, single-resource model tends to suit teams that want visibility into sync status at a glance, while Flux's smaller, composable controllers appeal to teams that want to wire GitOps into a broader custom pipeline. Some organizations even run both for different clusters or purposes.

GitOps vs. plain CI/CD

GitOps doesn't replace CI/CD, it replaces one half of it. The "CI" side — building, testing, and producing a versioned artifact or container image — still happens in a conventional pipeline, whether that's GitHub Actions, GitLab CI, or another runner. What changes is the "CD" side: instead of that pipeline having direct, credentialed access to push into every environment, it stops at updating a manifest or image tag in a Git repository. The in-cluster GitOps controller takes it from there.

This also changes what an audit trail looks like. In a push pipeline, "who deployed what" often lives in CI logs that rotate out or in a deployment tool's own history. In a GitOps setup, it's the Git log itself — the same commit history, pull request review, and approvals a team already relies on for application code now cover infrastructure and release state too, which is one reason the model is popular with platform and security teams, not just developers. Readers who haven't worked through the basics of continuous delivery pipelines may want our plain-English DevOps explainer as background before going further into GitOps specifics.

GitOps vs. Infrastructure as Code (Terraform)

GitOps is frequently confused with Infrastructure as Code, and the overlap is real: both describe system state declaratively and keep it in version control. Terraform, the best-known IaC tool, describes its own configuration files the same way OpenGitOps describes desired state — as declarative files that "describe the end state of your infrastructure." The difference is in what happens after a change is committed.

Terraform's core workflow is write, plan, apply: a human or a pipeline runs a plan to see what would change, then explicitly triggers an apply to make it happen. There's no persistent agent sitting in the target environment constantly re-checking that the infrastructure still matches the configuration; drift can creep in between runs and won't be corrected until someone runs Terraform again. GitOps tools add exactly that missing piece for the resources they manage — a controller that never stops comparing and correcting. In practice the two are often combined: Terraform (or a cloud provider's native IaC tool) provisions the Kubernetes cluster and its surrounding cloud resources, and then Argo CD or Flux takes over reconciling everything that runs inside that cluster.

Benefits, and the tradeoffs that come with them

The case for GitOps rests on a handful of concrete properties: every change is versioned and attributable, rollback is just reverting a commit, and drift is corrected automatically rather than discovered during an incident. Because the deploying agent lives inside the cluster rather than reaching in from outside, GitOps proponents also argue it narrows the attack surface compared with a push pipeline that needs standing admin credentials to every environment it targets.

That argument comes with a real caveat worth stating plainly: the tradeoff shifts rather than disappears. The in-cluster controller itself typically holds broad permissions over its cluster, so it becomes a high-value target in its own right, and write access to the Git repository it watches becomes equivalent to write access to production. Teams adopting GitOps still need to take repository protection, branch rules, and commit signing as seriously as they'd take cluster RBAC under a push model — GitOps moves the perimeter, it doesn't remove the need for one.

Where GitOps gets harder

Secrets are the most commonly cited pain point: a Git repository is a poor place to store database passwords or API keys in plaintext, so GitOps setups typically pair with a secrets manager or an encryption scheme (such as sealed or sops-encrypted secrets) layered on top, adding operational complexity. Multi-cluster and multi-tenant setups also raise real questions about repository structure — one repo per app, one per environment, or a single monorepo for everything — that teams tend to work out by trial and error rather than following one universally agreed pattern. And because reconciliation is continuous, a bad commit doesn't just fail a one-time deploy; it gets actively, repeatedly reapplied until someone reverts it or pauses the controller, which argues for strong pre-merge checks on anything a GitOps controller is allowed to reconcile.

Beyond Git: where the model is heading

Despite the name, the "Git" in GitOps is increasingly just one option for where desired state can live. Flux's documentation describes a "Gitless GitOps" delivery model built around OCI registries rather than a Git server, explicitly noting that in this mode "the Git server is no longer a production dependency" at runtime — the artifact registry becomes the thing the controller pulls from and reconciles against, while Git remains where the configuration is authored and reviewed. The core principles don't change: state is still declarative, versioned, pulled, and reconciled. Only the storage and distribution layer underneath it is becoming more flexible.

What to do now

If a team is already running Kubernetes and deploying through ad hoc kubectl apply commands or a push-style pipeline, the practical next step is to pick one low-risk application, put its manifests in a dedicated Git repository, and point either Argo CD or Flux at it in a non-production cluster first. Both projects publish getting-started guides on their own documentation sites, and both are free, open-source, and CNCF-governed, so there's no procurement step involved in trying one. From there, the usual adoption path is: stabilize the pattern on one app, add RBAC and branch-protection rules on the controlling repository, bring in a secrets-management layer before anything sensitive goes in, and only then expand to additional clusters or a full multi-tenant repository structure.

Written byFelix Moreau

Felix Moreau writes Pandromeda's software coverage and how-to guides. He covers Windows, macOS and Linux updates, the apps people rely on, emulators and developer tools, and turns official documentation into clear, numbered steps that work on the current version.

More from Felix MoreauAll Software & Guides coverage