What if the answer to “who changed production, when, and why?” was as simple as opening a commit history? That question is central to GitOps, an operating model that has quietly reshaped how teams run Kubernetes clusters and cloud infrastructure over the past several years. Instead of engineers running commands against live systems, every change flows through Git, and software agents make reality match what the repository says. (Cloud)
The idea sounds almost too tidy to work at scale. Yet it has moved from a niche Kubernetes pattern to a mainstream practice with formal principles, dedicated tooling, and a home inside the Cloud Native Computing Foundation. This article walks through what GitOps actually means, how the reconciliation loop works, where pull-based delivery beats push-based pipelines, and which mistakes trip up teams in their first year.
Where GitOps Came From and What It Actually Means
The term GitOps was coined by Weaveworks in 2017. Alexis Richardson, the company’s CEO at the time, used it to describe operating Kubernetes clusters with Git as the single source of truth. Weaveworks itself ceased operations in early 2024, which is a useful reminder that the practice outlived the vendor that named it. Many early explainer pages lived on that company’s site and have since gone dark or moved to archives.
The definition that has stuck is broader than Kubernetes. GitOps is an operational model in which the desired state of infrastructure and applications is stored declaratively in Git, and an automated agent continuously reconciles the live system to match that state. Changes are made by merging pull requests, not by running commands against the cluster.
That last sentence is the cultural shift. In a traditional setup, an engineer with cluster credentials types a command, and the cluster changes. In GitOps, the engineer opens a pull request, a reviewer approves it, and an agent applies it. The cluster’s credentials never leave the cluster. The Git history becomes the audit log.
The Four OpenGitOps Principles
The OpenGitOps working group, hosted under the CNCF, distilled the model into four principles that are worth knowing because they settle most arguments about whether a setup “counts” as GitOps:
- Declarative desired state. The system’s configuration is expressed as data describing what you want, not as a sequence of commands describing how to get there.
- Versioned and immutable state. That desired state is stored in a way that keeps a complete history, with each version retrievable.
- Automatically pulled. Software agents pull the desired state from the source and apply it, without a human or external system pushing changes in.
- Continuously reconciled. Agents keep comparing actual state to desired state and correct drift, rather than acting only once at deploy time.
If any one of those is missing, you have something adjacent to GitOps rather than GitOps itself. A repository full of YAML that someone applies by hand on Fridays satisfies the first two principles and none of the last two. (GitOps)
How the Reconciliation Loop Works in Practice
The engine of any GitOps setup is the reconciliation loop. An agent runs inside the cluster, watches a Git repository, and on a schedule or on a webhook event, compares what the repository declares with what the cluster contains. (News)
When they match, nothing happens. When they diverge, the agent acts. If someone manually deletes a deployment at 2 a.m. to “fix” an incident, the agent notices and recreates it. If a new commit adds a replica, the agent scales the workload. The loop never stops, which is why the model is sometimes described as self-healing.
This works only because the configuration is declarative. Kubernetes manifests, Kustomize overlays, and Helm charts all describe an end state. Imperative shell scripts that run a sequence of commands cannot be diffed against reality, so an agent has no way to know whether the system has drifted. Kubernetes’ own documentation on declarative object configuration explains why the declarative approach is the foundation the rest of the model rests on. (Kubernetes Documentation: Overview)
Pull Versus Push: The Defining Difference
Most CI/CD pipelines push. A build server finishes a job and then reaches into the cluster with credentials to deploy. GitOps inverts that. The agent lives inside the cluster and pulls changes outward-in.
| Aspect | Push-based CI/CD | Pull-based GitOps |
|---|---|---|
| Who initiates deployment | External CI system | In-cluster agent |
| Cluster credentials location | Held by CI platform | Never leave the cluster |
| Drift correction | None by default | Continuous |
| Rollback method | Re-run an old pipeline | Revert a commit |
| Audit trail | Pipeline logs | Git history and PR approvals |
| Typical failure mode | Silent config drift | Agent misconfiguration or sync errors |
The security implication is easy to miss. In a push model, a compromised CI system can deploy anything anywhere. In a pull model, the blast radius is limited to what the agent is permitted to read and apply.
Tooling Overview
Two tools dominate. Argo CD, part of the Argo project, and Flux are both CNCF graduated projects and both implement the pull-based model. They differ in style more than philosophy. Argo CD ships with a rich web UI and an application-centric model that many platform teams find easier to hand to developers. Flux is more composable, built from a set of controllers and designed to be driven from the command line and Git itself.
The Argo CD documentation is a reasonable starting point for understanding how an application object maps a repository path to a cluster destination. Flux’s core concepts documentation takes a different angle, explaining sources, reconciliation, and how its controllers fit together.
Beyond those two, the ecosystem includes Kustomize for overlay-based configuration, Helm for packaging, and a long tail of policy engines that validate manifests before they ever reach a cluster. The tooling matters less than the discipline. A team with Flux and no review process will drift just as surely as a team with a shell script.
What GitOps Gets Right
The benefits are real, but they are specific. Teams that adopt GitOps for the wrong reasons tend to abandon it.
Auditability is the strongest argument. Every change has an author, a timestamp, a diff, and usually an approval. When an incident review asks what changed, the answer is a commit hash rather than a Slack archaeology project.
Rollback becomes trivial in principle. Reverting a commit returns the declared state to a previous version, and the agent reconciles toward it. In practice, rollback is clean only if the change was purely declarative. A migration that altered a database schema will not reverse itself because you reverted a YAML file.
Drift detection catches the changes nobody documented. Manual hotfixes, console edits, and forgotten experiments all surface as differences between Git and the cluster.
Developer experience improves when application teams can propose changes through the same pull request workflow they already use for code. No ticket to the platform team, no waiting for credentials.
Where Teams Stumble
The failure modes are consistent enough to warn about.
Putting secrets in Git is the classic mistake. Plaintext credentials in a repository defeat the entire security argument. Sealed secrets, external secret stores, and encryption at rest are not optional extras; they are prerequisites.
Treating GitOps as a deployment tool only misses the point. If the agent manages application deployments but the cluster itself, its networking, and its RBAC are configured by hand, drift returns through the back door. Mature teams manage cluster add-ons and infrastructure the same way.
Skipping environment promotion. Copying manifests between folders by hand reintroduces the toil GitOps was meant to remove. Overlays, branches, or dedicated promotion repositories handle this more cleanly.
Ignoring the reconciliation interval. An agent that syncs every ten minutes means a ten-minute window where the cluster and Git disagree. For most workloads that is fine. For a payment service during an incident, it may not be. Webhook-triggered syncs narrow the gap.
Forgetting that Git is now production. A broken manifest merged to the main branch will be applied. Branch protection, required reviews, and automated validation in CI are what stand between a typo and an outage.
GitOps Beyond Kubernetes
GitOps grew up around Kubernetes because Kubernetes was the first widely adopted system with a strong declarative API. The pattern has since spread to cloud infrastructure provisioning, where tools that describe infrastructure as data can be reconciled the same way. It has also become a common organizing principle for internal developer platforms, where the platform team exposes golden paths and the underlying resources are reconciled from repositories.
The trend is real but uneven. Systems with weak declarative APIs remain awkward to manage this way. The question to ask before adopting GitOps for a new domain is simple: can the desired state be expressed as data, and can something continuously compare it to reality? If the answer to either is no, the model will fight you.
For readers tracking how these practices evolve across cloud platforms and tooling, the cloud section of 9481.org covers related developments, and the blog rounds up broader industry shifts worth following. (Blog)
Conclusion
GitOps is less a product than a bargain: you give up the ability to change production by hand, and in return you get a complete history, automatic drift correction, and a smaller attack surface. The bargain holds only if the declarative state is genuinely complete, secrets are handled properly, and the repository is protected like the production system it has become. Teams that treat those conditions as non-negotiable tend to find the model quietly transformative. Teams that treat GitOps as a deployment plugin usually find themselves back where they started, wondering why the cluster no longer matches the repository.
Frequently Asked Questions
What is GitOps in simple terms?
GitOps is a way of running systems where the desired configuration lives in a Git repository, and automated software makes the live system match it. Instead of logging in and changing things directly, engineers change the repository, and the software applies the difference. Git becomes the record of what should exist, and the agent keeps reality in line with it.
Is GitOps the same as CI/CD?
No, though they overlap. CI/CD usually refers to building and testing code and then pushing deployments out to a cluster. GitOps specifically describes the delivery and operations side, where an in-cluster agent pulls changes rather than receiving a push. Many teams run CI to build container images and then use GitOps to deploy them, updating an image tag in a repository as the handoff point.
Do I need Kubernetes to use GitOps?
Kubernetes is where the practice originated and where the tooling is most mature, but it is not a hard requirement. Any system with a strong declarative API and a way to continuously reconcile state can be managed this way. In practice, most GitOps adoption today still centers on Kubernetes clusters and the infrastructure around them.
What is the difference between Argo CD and Flux?
Both are CNCF graduated projects that implement pull-based GitOps, and both are capable. Argo CD offers a graphical interface and an application-centric model that many teams find approachable. Flux is built from composable controllers and is often driven entirely from the command line and Git. The choice usually comes down to team preference and existing workflows rather than a meaningful capability gap.
How do you handle secrets in GitOps?
You do not commit plaintext secrets. Common approaches include encrypting secrets before they enter the repository, storing them in an external secret manager and referencing them from manifests, and using tooling that decrypts only inside the cluster. The principle is that the repository holds a reference or an encrypted blob, never a readable credential.
Can GitOps roll back a bad deployment automatically?
It can roll back the declared state quickly by reverting a commit, and the agent will reconcile toward the previous configuration. Whether that counts as a full rollback depends on the change. Stateless application configuration reverses cleanly. Database migrations, external side effects, and anything that touched persistent data usually need a separate plan.
