If you run Kubernetes in production, you have probably heard the word GitOps. It comes up in job descriptions, tool documentation, and architecture discussions. But a lot of explanations are vague or overcomplicated.
This post explains GitOps clearly — what it actually is, how it works, and why it matters for DevOps engineers.
What Is GitOps?
GitOps is a way of managing infrastructure and application deployments where Git is the single source of truth.
Every change — whether it is a new deployment, a config update, or a scaling change — goes through a Git commit. A tool running inside your cluster watches the repository and automatically applies whatever is defined there to the live environment.
The term was coined by Weaveworks in 2017. By 2026, 91% of cloud-native organisations have adopted GitOps according to the CNCF Annual Survey.
How Traditional Deployment Works
In a traditional CI/CD pipeline, the flow looks like this:
Developer pushes code
→ CI builds and tests
→ CI/CD pipeline pushes changes to the cluster
→ kubectl apply or helm upgrade runs
The pipeline has credentials to access your cluster. It pushes changes directly. If something goes wrong, you have to dig through pipeline logs to figure out what happened and when.
There is another problem. Someone can log into the cluster and run kubectl apply manually — and that change is not tracked anywhere. Your cluster drifts away from what your code says it should be. This is called configuration drift and it causes incidents.
How GitOps Works
GitOps flips this model. Instead of pushing changes into the cluster, an agent running inside the cluster pulls changes from Git.
Developer pushes code
→ CI builds and tests
→ CI updates the image tag in the Git repository
→ GitOps agent detects the change in Git
→ Agent applies it to the cluster automatically
The cluster never needs external credentials. Nothing pushes into it from outside. The agent reads from Git and reconciles the live state to match.
If someone manually changes something in the cluster with kubectl, the agent detects the drift and reverts it back to what Git says it should be. Git wins — always.
The Four Core Principles
The OpenGitOps project defines four core principles:
1. Declarative The desired state of the system is described in files — YAML, Helm charts, Kustomize overlays. You describe what you want, not the steps to get there.
2. Versioned and immutable Everything is in Git. Every change has an author, a timestamp, and a commit message. You can see exactly what changed, when, and who approved it.
3. Pulled automatically The GitOps agent inside the cluster pulls changes from Git. The cluster does not need external access or credentials from CI/CD pipelines.
4. Continuously reconciled The agent continuously compares what is in Git with what is running in the cluster. If they differ, it corrects the cluster automatically.
A Real Example
Imagine you have a Kubernetes Deployment manifest in Git:
# k8s/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-server
spec:
replicas: 2
template:
spec:
containers:
- name: api
image: myregistry/api:v1.4.0
Your CI pipeline builds a new image and updates the tag in this file:
image: myregistry/api:v1.5.0
It commits the change to Git:
git commit -m "Deploy api v1.5.0"
git push origin main
Your GitOps tool — ArgoCD or Flux — detects the change within minutes (or instantly if webhooks are configured). It updates the Deployment in the cluster. The new pods come up. The old ones terminate.
No one ran kubectl apply. No pipeline had cluster credentials. The deployment happened through Git.
Why GitOps Matters
Audit trail built in Every deployment is a Git commit with an author and timestamp. Compliance teams love this. When an incident happens, you can trace exactly what changed and who approved it by reading git log.
Easy rollback Rolling back a bad deployment is a git revert:
git revert abc1234
git push origin main
The GitOps agent detects the revert and rolls the cluster back to the previous state automatically. No manual intervention needed during an incident.
No configuration drift If someone makes a manual change to the cluster, the agent detects it and reverts it. Your cluster always matches what is in Git. No surprises.
No cluster credentials in CI/CD Your CI/CD pipeline no longer needs credentials to access your cluster. It only needs access to the Git repository. This significantly reduces your attack surface.
Self-healing If a node fails and a pod is rescheduled with wrong config, the agent reconciles it back to the desired state automatically.
GitOps vs CI/CD — What Is the Difference?
People often confuse these. They are not the same thing and they work together.
| CI/CD | GitOps | |
|---|---|---|
| What it does | Builds, tests, and packages code | Deploys and keeps cluster in sync with Git |
| Who triggers it | Code commit → pipeline runs | Git change → agent reconciles |
| Direction | Pushes changes into the cluster | Pulls changes from Git |
| Credentials | Needs cluster access | No cluster access needed |
| Drift detection | No | Yes — continuously |
CI/CD handles the build and test. GitOps handles the deployment and ongoing reconciliation. Most teams use both — GitHub Actions or Jenkins for CI, ArgoCD or Flux for CD.
Push-Based vs Pull-Based GitOps
There are two models:
Push-based: Your CI/CD pipeline applies changes to the cluster directly after a Git commit. Faster to set up, but the pipeline needs cluster credentials.
Pull-based: An agent inside the cluster watches Git and pulls changes. More secure, no external credentials needed. This is the recommended approach and what tools like ArgoCD and Flux implement.
Most teams doing GitOps properly use the pull-based model.
GitOps Tools
Two tools dominate the GitOps space in 2026, both CNCF Graduated projects:
ArgoCD — centralized, web UI, hub-and-spoke multi-cluster management. 60% market share. Better for teams that want visual dashboards and fast onboarding.
Flux — decentralized, CLI-first, runs per cluster. Native SOPS support for secrets. Better for platform engineers who want a modular, Kubernetes-native approach.
For a detailed comparison, see our post: ArgoCD vs Flux — GitOps Tools Compared
For a step-by-step setup guide, see: How to Set Up ArgoCD on Kubernetes
When Should You Use GitOps?
GitOps works well when:
- You are running workloads on Kubernetes
- Multiple people deploy to the same cluster
- You need an audit trail for compliance
- You want to prevent configuration drift
- You want easy, safe rollbacks
GitOps is not the right fit when:
- You are managing highly dynamic runtime data that changes constantly
- Your team is very small and a simple CI/CD push pipeline is enough
- You do not yet have mature secret management — GitOps without secure secrets handling creates problems
Summary
GitOps is not a tool. It is a way of working. Git becomes the source of truth for everything. Changes go through pull requests. An agent inside the cluster applies them automatically. Drift is corrected automatically. Rollbacks are a git revert.
It makes deployments safer, more auditable, and easier to manage at scale. That is why it has become the standard for Kubernetes teams.