GitOps is an operating model for infrastructure and application delivery in which a Git repository holds the declarative desired state of a system and an automated agent continuously reconciles the live environment to match it. In DevOps, GitOps extends the practices of version control, code review and continuous delivery from application code to everything that runs in production, most commonly Kubernetes clusters.
The core idea is that nobody changes production by hand. A change is proposed as a commit or pull request, reviewed and merged, and a controller such as Argo CD or Flux detects the new state and applies it. The Git history therefore becomes a complete, auditable record of who changed what, when and why.
The four principles of GitOps
The OpenGitOps project under the Cloud Native Computing Foundation describes GitOps through four principles. A system that meets all four is GitOps in the strict sense; many teams adopt only some of them.
| Principle | Meaning | Practical consequence |
|---|---|---|
| Declarative | Desired state is described, not scripted | Manifests, Helm charts or Kustomize overlays |
| Versioned and immutable | State is stored with full history | Every change is a commit that can be reverted |
| Pulled automatically | Agents fetch the desired state themselves | No external system pushes into the cluster |
| Continuously reconciled | Agents correct any difference | Manual drift is detected and undone |
Git is the most common store, which gives the practice its name, but the principles only require a versioned, immutable source of truth. Some implementations also use OCI registries or object storage to deliver the rendered desired state.
How a GitOps reconciliation loop works
At the center of GitOps is a reconciliation loop that runs inside or next to the target environment. The controller repeatedly compares the desired state from the repository with the actual state reported by the platform and acts on any difference.
- Commit: an engineer or a CI pipeline changes a manifest or an image tag in the configuration repository.
- Review: the change is reviewed and merged according to branch protection rules.
- Detect: the controller polls the repository, typically every one to five minutes, or receives a webhook.
- Render: Helm charts or Kustomize overlays are rendered into final manifests.
- Compare: the controller computes the difference between desired and live state.
- Apply: changes are applied to the cluster, optionally with automatic pruning of removed objects.
- Report: health and sync status are reported back to dashboards and, often, to the commit.
Because the loop runs continuously, it also performs drift detection. If someone edits a resource directly with kubectl, the controller marks it as out of sync and, with self-healing enabled, restores the declared state.
GitOps compared with traditional CI/CD pipelines
GitOps does not replace continuous integration; it changes how deployment happens. In a classic push-based pipeline, the CI system holds cluster credentials and runs deployment commands. In a pull-based GitOps model, CI only builds, tests and publishes artifacts, then updates the configuration repository.
| Aspect | Push-based CI/CD | Pull-based GitOps |
|---|---|---|
| Who deploys | CI server runs deployment commands | In-cluster agent applies changes |
| Cluster credentials | Stored in the CI system | Stay inside the cluster |
| Drift handling | Not detected between runs | Detected and corrected continuously |
| Rollback | Rerun an earlier pipeline | Revert a commit |
| Audit trail | Pipeline logs | Git history and pull requests |
| Multi-cluster scale | One pipeline step per target | Each cluster pulls its own state |
The pull model improves security because the cluster API does not have to be reachable from outside and no deployment credentials leave the cluster. It also fits large fleets, since hundreds of clusters can each reconcile themselves from the same repository.
Tools and repository structure
The two most widely used GitOps controllers for Kubernetes are Argo CD and Flux, both graduated CNCF projects. The same principles are applied to cloud infrastructure with tools that reconcile Terraform or Crossplane resources.
| Tool | Scope | Notable features |
|---|---|---|
| Argo CD | Kubernetes applications | Web UI, sync waves, ApplicationSets for fleets |
| Flux | Kubernetes applications | Modular controllers, image automation, OCI sources |
| Crossplane | Cloud resources through Kubernetes APIs | Cloud infrastructure managed as custom resources |
| Terraform automation | Cloud infrastructure | Plan on pull request, apply on merge |
Most teams separate application source code from deployment configuration, keeping manifests in a dedicated repository or directory. Environments are represented by directories or overlays rather than long-lived branches, because promoting changes between branches tends to cause merge conflicts and hidden differences.
Challenges and common GitOps mistakes
GitOps brings discipline, but it also introduces new failure modes. The most frequent problems concern secrets, promotion and ownership of resources.
| Pitfall | Consequence | Remedy |
|---|---|---|
| Plain-text secrets in Git | Credentials exposed in history | Sealed Secrets, SOPS or external secret operators |
| Manual hotfixes in the cluster | Overwritten by reconciliation | Make every fix through Git |
| Branch per environment | Drift and painful merges | Directory or overlay per environment |
| Controllers fighting over fields | Endless sync loops | Ignore autoscaler-managed fields |
| Huge monolithic repository | Slow syncs, broad access rights | Split by team or domain with clear ownership |
GitOps also requires a cultural shift. Incident responders must accept that the fastest durable fix is a reviewed commit, and teams usually define an emergency path with expedited approval rather than allowing direct changes.
In plain words
Imagine a building whose official blueprint is kept in one shared folder. A robot walks through the building every few minutes, compares every room with the blueprint and fixes anything that does not match. If someone wants a change, they edit the blueprint, have it approved, and the robot does the rest.
GitOps works the same way for computer systems. The blueprint lives in Git, the robot is a small program in the cluster, and every change leaves a record of who made it and why. Undoing a mistake is as simple as restoring the previous version of the blueprint.
A real-world example
A logistics company operates 40 Kubernetes clusters in warehouses across several countries, many behind restrictive firewalls. Its old pipeline pushed deployments from a central CI server, which needed network access and credentials for every site, and failed deployments often left sites on different versions.
The platform team installs Argo CD in each cluster and stores all configuration in one repository with a directory per region. CI now only builds images and opens a pull request that updates the image tag. After merge, every warehouse cluster pulls the change within minutes. When a release causes errors, the team reverts one commit and all 40 sites return to the previous version, and the audit team receives a complete change history directly from Git.