Pillar Guide · GitOps

What is GitOps?
Your repo is the source of truth.

GitOps is an operating model where the desired state of your entire system lives in version control, and software agents continuously reconcile the running infrastructure to match what's committed to Git. Weaveworks coined the term in 2017 to describe how they ran Kubernetes at scale; in 2021 the community distilled it into the vendor-neutral OpenGitOps standard under the CNCF. The idea is old-fashioned in the best way: if you want to know what's running in production, you read the repo.

The plain-English version: you stop pushing changes into your cluster with scripts and pipelines that hold production credentials, and instead describe what you want in declarative files (Kubernetes manifests, Helm charts, Kustomize overlays, Terraform), commit them, and let a reconciler running inside the environment pull those files and make reality match. Deployments become pull requests. Rollbacks become git revert. The audit log is the git history.

This guide covers what GitOps actually is, the four OpenGitOps principles, why pull-based delivery is safer than the push pipelines most teams still run, how Argo CD and Flux differ, how GitOps relates to CI/CD and Infrastructure as Code, and a practical path to adopting it without a repo-sprawl nightmare. If you're weighing whether the migration is worth it, our DevOps consulting team does this weekly.

Key takeaways

  • Git is the single source of truth — the repo declares desired state; the cluster is a function of the repo, not a pile of undocumented kubectl commands.
  • OpenGitOps defines four principles: desired state is declarative, versioned & immutable, pulled automatically, and continuously reconciled.
  • Pull beats push — an agent inside the cluster reconciles from Git, so production credentials never leave the environment and CI never needs cluster access.
  • Argo CD and Flux are the two CNCF-graduated tools — pick on operating model and team fit, not popularity.
  • The payoff is drift detection and instant rollback — the cluster can't silently diverge, and reverting a bad change is one commit.

The core idea: Git as the single source of truth

Traditional operations answer "what's running in production?" with a shrug and a scramble through kubectl, cloud consoles, and someone's shell history. GitOps answers it with a git clone. Every object that defines your system (deployments, config maps, ingress rules, network policies, even the cluster's own add-ons) is expressed declaratively and stored in a repository. The live environment is treated as a derived artefact: a projection of the repo, continuously enforced.

That single decision — the repo is authoritative, not the cluster — is what makes everything else fall out. Change control becomes code review. Access control becomes repository permissions. Auditing becomes git blame. There's no separate deployment ticket system because the pull request is the deployment ticket. It's Infrastructure as Code taken to its logical conclusion: not just defining infrastructure in files, but making those files the only sanctioned way to change anything.

The four OpenGitOps principles

In 2021 the OpenGitOps working group, under the CNCF, published a vendor-neutral definition so "GitOps" stopped meaning "whatever my tool happens to do." Four principles:

1. Declarative. The entire system is described declaratively — you state the desired end state, not the steps to reach it. Kubernetes manifests, Helm, Kustomize, and Terraform are all declarative; a bash script that runs kubectl apply in sequence is not.

2. Versioned and immutable. Desired state is stored so that it is immutable and retains a complete version history. Git is the obvious backing store, but the principle is what matters: every state is a versioned, tamper-evident snapshot you can return to.

3. Pulled automatically. Software agents automatically pull the desired state from the source. Nobody pushes into the cluster; the cluster reaches out for its own configuration.

4. Continuously reconciled. Agents continuously observe actual state and reconcile it toward desired state. This is a control loop, not a one-shot deploy — the same loop that makes Kubernetes work, pointed at your Git repo. Notice the word "Git" appears in only one of the four principles, and there only as an example. GitOps is really reconciliation-ops; Git just happens to be the best versioned, immutable store we have.

Push vs pull, and why pull is safer

Most teams deploy with a push model: a CI pipeline builds an artefact, then runs kubectl apply or helm upgrade or terraform apply against production. It works, but it has a structural weakness — the pipeline holds credentials to your production environment. Every CI runner, every third-party action, every compromised dependency in your build is now a path to your cluster. The blast radius of a leaked CI token is your entire infrastructure.

Pull-based delivery inverts the arrows. An agent (Argo CD or Flux) runs inside the target cluster, watches the Git repo, and pulls approved changes in. Credentials to the cluster never leave the cluster. CI's job ends at "build the image and update a tag in Git" — it never touches production. This also means GitOps works cleanly with private clusters that have no inbound network path: the agent only needs outbound access to Git. Pull isn't just tidier; it's a smaller, better-contained attack surface, which is why security-conscious platform teams treat it as the default.

The tooling: Argo CD vs Flux

Two CNCF-graduated projects dominate, and both are excellent. The choice is about operating model, not capability.

Argo CD is application-centric and UI-forward. It models everything as an Application object, gives you a genuinely good web UI for visualizing sync status and diffing live-versus-desired state, and scales to many teams through the "app of apps" pattern and ApplicationSets. Teams that want a console operators can look at, with strong multi-tenant RBAC out of the box, tend to land on Argo CD.

Flux is a toolkit of composable controllers with no mandatory UI. It's leaner, integrates tightly with Helm and Kustomize, and treats GitOps as a set of Kubernetes controllers you assemble. Teams that want everything expressed as CRDs, prefer CLI and automation over a dashboard, and value a small footprint tend to pick Flux.

Honest take: for most orgs the deciding factor is simply whether your operators want a UI (Argo CD) or want pure API- and CRD-driven infrastructure (Flux). Both are production-grade; neither choice is a mistake. What is a mistake is adopting either before your infrastructure is actually declarative — the tool doesn't create the discipline, it enforces it. This is the kind of decision a maturing platform team should make deliberately (it's one of the axes we unpack in DevOps vs SRE vs Platform Engineering), not by copying a conference talk.

GitOps vs traditional CI/CD

GitOps doesn't replace CI/CD; it reshapes the CD half. Continuous Integration — build, test, produce a versioned artefact — is unchanged and still essential. What GitOps changes is Continuous Delivery: instead of the pipeline pushing the artefact into production, CI's final step is a commit that updates the desired state in Git, and the in-cluster reconciler pulls it from there.

The clean way to think about it: CI is imperative and lives in your pipeline; CD becomes declarative and lives in your cluster. That separation is the whole point. Your build system no longer needs production credentials, your deployment history is your git history, and "what version is in staging?" is answered by reading a file, not querying a pipeline's run logs. For the broader delivery picture, see our What is DevOps? guide — GitOps is one of the strongest modern implementations of DevOps delivery.

Drift detection and rollback

Two capabilities justify most GitOps migrations on their own.

Drift detection. Because the reconciler continuously compares live state to Git, it notices the moment they diverge — someone runs kubectl edit at 2 a.m. during an incident, a mutating webhook rewrites a field, an operator fat-fingers a replica count. The agent flags the drift and, if you enable self-healing, reverts the live object back to what Git says. Your cluster physically cannot stay out of sync with the repo without you knowing. Pair this with real observability and on-call discipline so drift and reconciliation failures page the right people — the same alerting hygiene we cover in What is SRE?

Rollback. When a deploy goes bad, rollback is git revert followed by a normal reconcile. There's no special rollback tooling, no snapshot to restore, no "does anyone remember the previous config?" The last known-good state is a commit away, and because Git is immutable and versioned, you know exactly what you're rolling back to. Recovery becomes a code operation your whole team already knows how to do.

Where GitOps fits: Kubernetes-native, not Kubernetes-only

GitOps was born on Kubernetes for a reason: Kubernetes is already declarative and already runs reconciliation control loops. GitOps just points that existing machinery at a Git repo. If you're running Kubernetes, GitOps is close to the natural operating model, and it composes well with the platform work most teams are already doing. If you're mid-migration to Kubernetes, read our field notes on three Kubernetes migration mistakes for what tends to go wrong in practice before you layer GitOps on top.

It reaches beyond Kubernetes, though. Tools like Terraform Controller, Crossplane, and Config Sync bring GitOps reconciliation to cloud resources, databases, and non-Kubernetes infrastructure. The pattern — declarative state in Git, an agent reconciling reality toward it — is substrate-agnostic. Kubernetes is where it's easiest, not where it ends, which is why platform teams increasingly treat GitOps as the delivery interface for their internal platform.

How to adopt GitOps

A pragmatic sequence that avoids the two classic failure modes (repo sprawl and half-migrated clusters):

  1. Make it declarative first. Before installing any tool, get your infrastructure expressed as manifests, Helm charts, or Kustomize overlays. GitOps enforces declarative config; it can't create it.
  2. Design the repo structure deliberately. Decide up front how you split application config from cluster and platform config, and how many repos you'll run. Sprawl is the single most common regret.
  3. Install one reconciler. Deploy Argo CD or Flux and put one non-critical application under its management end to end. Prove the loop before you bet the platform on it.
  4. Solve secrets properly. Never commit plaintext secrets. Adopt Sealed Secrets, the External Secrets Operator, or SOPS before you migrate anything sensitive.
  5. Define environment promotion. Make explicit how a change flows from dev to staging to production through Git — branches, directories, or overlays. Ambiguity here is where GitOps quietly breaks down.
  6. Turn on drift detection and alerting. Enable self-healing where safe, and wire reconciliation failures and drift into your on-call alerting so the control loop is observable.

Common pitfalls

  • Secrets in Git. The number-one beginner mistake. Plaintext secrets in a repo are a breach waiting to happen; use encryption or an external secrets operator from day one. This is where GitOps and secure delivery meet, and it is not optional.
  • Repo sprawl with no structure. Teams spin up a repo per app per environment and drown in duplication. Decide your structure early and keep it boring.
  • No promotion strategy. Without an explicit dev-to-prod flow, "GitOps" degrades into people hand-editing production overlays — exactly the situation you were escaping.
  • Treating the tool as the strategy. Installing Argo CD doesn't make you a GitOps shop any more than installing Jira makes you agile. The discipline is declarative-everything and Git-as-source-of-truth; the tool only enforces it.
  • Skipping drift and reconciliation alerting. A silent reconciler is worse than none — you'll trust a loop you aren't actually watching.

Thinking about a GitOps migration, or halfway into one and fighting repo sprawl and secret management? InfraZen runs a free 30-minute GitOps review that ends in an honest read on whether you're ready, which tool fits your team, and the highest-leverage first step. Book the review.

Related: DevOps Consulting services · What is DevOps? · What is SRE? · DevOps vs SRE vs Platform Engineering · Three Kubernetes migration mistakes · Managed DevOps vs in-house

Deployments that explain themselves.

Free 30-minute GitOps review. Argo CD vs Flux, repo structure, secrets, drift. We'll tell you honestly whether you're ready and where the first week of work should go.

last updated: 2026-07-10

DevOps services Book the Review →

Frequently asked questions

What is GitOps in simple terms?

GitOps is a way of running infrastructure where the desired state of your whole system is stored in Git, and an automated agent continuously makes the live environment match what is committed. Instead of pushing changes into production with scripts that hold cluster credentials, you commit declarative files and let a reconciler running inside the environment pull and apply them. Deployments become pull requests, rollbacks become git revert, and the audit log is your git history.

What is the difference between GitOps and CI/CD?

GitOps does not replace CI/CD; it reshapes the delivery half. Continuous Integration (build, test, produce a versioned artifact) is unchanged. What changes is deployment: instead of a pipeline pushing the artifact into production, CI ends by committing an updated desired state to Git, and an agent inside the cluster pulls it. The result is that your build system never holds production credentials and your deployment history is simply your git history.

Argo CD or Flux, which should I use?

Both are CNCF-graduated and production-grade, so the choice is about operating model rather than capability. Argo CD is application-centric with a strong web UI, good live-versus-desired diffing, and multi-tenant RBAC out of the box, which suits teams that want a console. Flux is a leaner toolkit of Kubernetes controllers with no mandatory UI, which suits teams that prefer pure CRD and CLI driven infrastructure. Neither is a wrong answer.

Does GitOps only work with Kubernetes?

No, but Kubernetes is where it is easiest. Kubernetes is already declarative and already runs reconciliation control loops, so GitOps just points that machinery at a Git repo. Beyond Kubernetes, tools like Terraform Controller, Crossplane, and Config Sync bring the same pattern to cloud resources and other infrastructure. The core idea, declarative state in Git with an agent reconciling reality toward it, is substrate-agnostic.

How does GitOps handle secrets?

You never commit plaintext secrets to Git. The standard approaches are to encrypt secrets before committing them (Sealed Secrets or SOPS) or to store only a reference in Git and fetch the real value at runtime from a secrets manager using the External Secrets Operator. Solving secrets properly is a prerequisite, not an afterthought, and skipping it is the most common and most dangerous GitOps mistake.

Is GitOps the same as Infrastructure as Code?

GitOps builds on Infrastructure as Code but adds two things. IaC means defining infrastructure in declarative files; GitOps makes those files in Git the single authoritative source and adds an agent that continuously reconciles the running system to match them. In short, IaC is the file format and GitOps is the operating model that enforces it, including drift detection and automated rollback.