GitOps Explained: Principles and Tools

At 02:14 on a Tuesday in March 2026, an on-call engineer SSHed into a production cluster and ran kubectl scale deployment/checkout --replicas=10 to ride out a traffic spike. It worked. Ninety seconds later the replica count snapped back to 3, the site fell over, and the pager screamed again. The fix wasn't a bug. It was GitOps doing exactly its job: the cluster's desired state said replicas: 3, nobody had committed the change to Git, so the controller quietly undid it.

That story is the whole point of GitOps in one incident. Let me unpack what GitOps is, the principles that define it, how the reconciliation loop works, and the tools you'll reach for in 2026.

What is GitOps, precisely?

GitOps is an operational model where Git is the single source of truth for your infrastructure and applications, and an automated agent continuously reconciles the running system to match what's committed. You describe the desired state declaratively, push it to a repo, and a controller makes reality converge on it. No kubectl apply from a laptop, no manual drift.

The word gets thrown around loosely, so here's the sharp version: GitOps is not just "CI/CD with Git" or "Terraform in a pipeline." The Git repository is authoritative. Every change is a commit, every deployment a merge, and every rollback a git revert. Observability closes the loop by flagging drift.

The model was named by Weaveworks in 2017 and later formalized by the OpenGitOps project under the CNCF, whose v1.0.0 spec distilled it into four principles. The point of naming it was to separate a real, checkable pattern from the vague "we use Git" claim every team makes.

The concept to hold onto is intent: you never tell the system how to change, only what the end state should be. The agent figures out the how.

What are the four principles of GitOps?

OpenGitOps defines four principles a system must satisfy to genuinely be GitOps. If any one is missing, you have something adjacent but not the real thing.

1. Declarative. The entire system is described declaratively. You state the desired outcome (three replicas, this image tag, this config) rather than scripting the steps to get there.
2. Versioned and immutable. Desired state is stored in Git, giving you an immutable, versioned history with a complete audit trail. Every state is a commit you can inspect or return to.
3. Pulled automatically. Software agents automatically pull the desired state from the source. Nobody pushes credentials into the cluster from outside; the agent reaches out from inside.
4. Continuously reconciled. Agents continuously observe actual state and reconcile it toward the desired state. Drift is detected and corrected without a human running a command.

That third principle is the one people fumble. A push-based pipeline that runs kubectl apply on merge satisfies principles 1 and 2 but not 3 or 4. Real GitOps inverts control: the cluster watches Git, not the other way around. Our 02:14 incident? Principle 4, working as designed.

How does the GitOps reconciliation loop work?

The reconciliation loop continuously compares the desired state in Git against the live state in the cluster and applies whatever changes close the gap. An in-cluster controller polls or subscribes to the repo, computes a diff, and converges the two. This is the engine that makes GitOps self-healing.

Here's the loop in concrete steps:

1. A developer opens a pull request changing a manifest (say, bumping an image tag).
2. Reviewers approve and merge to the environment branch or path.
3. The GitOps controller (Argo CD or Flux) detects the new commit within its sync interval.
4. It renders the desired state, often through Kustomize or Helm.
5. It diffs desired state against the cluster's actual state via the Kubernetes API.
6. It applies the delta, creating or updating resources.
7. It reports health and sync status back, marking the app Synced or OutOfSync.
8. If someone hand-edits the cluster, the next loop detects drift and reverts it to match Git.

A rollback, then, is just Git going backwards:

# Revert the offending merge, then reconcile
git revert 9f3c1a2 && git push origin main
argocd app sync checkout --prune

Because reconciliation never stops, an out-of-band kubectl edit gets undone automatically. Your cluster can't quietly diverge from what's reviewed and committed.

Which GitOps tools should you use in 2026?

Two CNCF-graduated tools dominate: Argo CD and Flux. Both implement the four principles well; they differ in surface area and philosophy. Argo CD ships a rich web UI and an app-centric model; Flux is a composable toolkit of controllers, native to Kubernetes and automation at scale.

The current state as of July 2026:

A few honest notes from running both in production:

• Argo CD wins when humans need to see state. The UI's diff and OutOfSync badge save real debugging time, and app-of-apps scales to many teams. The 3.0 jump tightened defaults: fine-grained policies no longer leak to sub-resources, and pod-log RBAC is on by default. The 3.5 release candidate (June 2026) adds internal mTLS and Git commit signature verification.
• Flux wins when you want GitOps as Lego bricks: its image-automation controller bumps tags for you, and its source/kustomize controllers compose cleanly into a larger platform. Flux 2.8 (GA February 2026) brought native Helm v4 support, so you're not stuck on the Helm 3 line.
• Don't run both against the same namespaces. Two reconcilers fighting over the same resources is a genuinely bad afternoon.

For cloud infrastructure (not just Kubernetes workloads), pair either tool with Crossplane or drive Terraform through a controller so infra also lives behind the loop. Still choosing your IaC layer? Our Terraform vs Pulumi comparison covers that call.

What are the benefits and trade-offs of GitOps?

The benefits concentrate in auditability, recovery, and consistency. Because every change is a commit, you get a free audit log, one-command rollbacks, and disaster recovery that amounts to pointing a fresh cluster at the same repo. But GitOps isn't free, and pretending otherwise sets teams up to bounce off it hard.

What you gain:

• Auditability. Git history is your change log. Who changed what, when, and why, with review baked in.
• Fast rollback. git revert plus a sync returns you to a known-good state in seconds.
• Drift correction. The cluster self-heals toward Git, killing config drift.
• Consistent environments. The same repo pattern reproduces dev, staging, and prod.

What it costs:

• Secrets are awkward. You can't commit plaintext secrets, so you need Sealed Secrets, SOPS, or an external secrets operator wired in from day one.
• Learning curve. The pull model and reconciliation semantics are a genuine mental shift for teams used to imperative pipelines.
• Repo sprawl. Environments, apps, and config split across repos need a deliberate structure, or you drown in YAML.

My opinionated take: GitOps pays off the moment you have more than one environment and more than one person with cluster access. Below that bar, the secret-management overhead can outweigh the gains. We migrated a 40-service platform to Argo CD over a quarter. Rollbacks went from a nervous 20-minute scramble to a reverted commit, and "who changed prod?" incidents effectively stopped. The tax was two weeks getting secrets right with SOPS before we trusted it.

Building the pipeline that feeds this? Read our guide on how to build a CI/CD pipeline, and pair it with Kubernetes mistakes to avoid before production. Our observability deep dive on logs, metrics, and traces covers closing the feedback loop, and platform engineering shows where GitOps fits in a larger internal platform.

Frequently Asked Questions

Is GitOps only for Kubernetes?

No, but Kubernetes is where it shines. GitOps needs a declarative system and an agent that can reconcile state, and Kubernetes provides both natively. You can apply the same model to Terraform-managed cloud infra or other declarative platforms, but the mature tooling (Argo CD, Flux) is Kubernetes-native, so that's the well-worn path in 2026.

What is the difference between GitOps and DevOps?

DevOps is a culture of shared ownership between development and operations. GitOps is a specific operational pattern, using Git as the source of truth with automated reconciliation, that implements continuous delivery. GitOps is one concrete way to practice DevOps; DevOps is the broader philosophy GitOps serves.

How does GitOps handle secrets?

Never commit plaintext secrets. Use an encryption layer such as Sealed Secrets or SOPS to store encrypted values in Git, or an External Secrets Operator that pulls from a vault (HashiCorp Vault, AWS Secrets Manager) at reconcile time. The agent decrypts or fetches at apply time, so Git only ever holds ciphertext or references.

Is GitOps the same as CI/CD?

Not quite. CI/CD is the broader pipeline that builds, tests, and delivers software. GitOps runs the CD half using a pull-based reconciliation loop. A common 2026 setup: CI builds and tests the image, commits a new tag to the config repo, and a GitOps agent handles the actual deployment.