In 2017, a small team at Weaveworks published a blog post titled “GitOps: Operations by Pull Request.” It argued that the same workflow developers already used to ship code could govern entire production systems. Less than a decade later, that idea sits at the center of how many organizations run Kubernetes and cloud infrastructure. The Cloud Native Computing Foundation now hosts a formal GitOps working group, and two GitOps tools, Argo CD and Flux, have traveled the full path from side projects to graduated CNCF status. The concept has moved from a clever hack to a default operating model. (What is GitOps?)
Yet “GitOps” remains one of those terms people use confidently and define loosely. This article breaks it down: where it came from, what it actually requires, where it breaks, and how to tell whether your team is genuinely doing it or just storing YAML in a repository and hoping for the best.
What GitOps Actually Means
GitOps is an operating model in which a Git repository is the single source of truth for the desired state of a system, and automated software continuously makes the live system match that repository. That is the full definition.
The key word is continuously. Storing infrastructure definitions in Git is just version control. GitOps adds an agent that watches both the repository and the running environment, compares them, and reconciles any difference without a human pushing a button. If someone manually changes a setting in production, the agent notices and reverts it. If a developer merges a pull request, the agent applies it.
This is why GitOps is often described as declarative infrastructure plus continuous reconciliation. You describe what you want, not how to get there, and a controller closes the gap on a loop.
The Four OpenGitOps Principles
The OpenGitOps project, a CNCF sandbox initiative, distilled the model into four principles that have become the closest thing to a canonical definition. They are worth knowing precisely, because most failed GitOps adoptions violate one of them.
- Declarative. The entire desired state must be expressed declaratively. Imperative scripts that say “create this, then patch that” do not qualify, because the system cannot reliably determine whether the end state was reached.
- Versioned and immutable. The desired state lives in a repository with full history. Every change is a commit, attributable to a person, timestamped, and reversible.
- Pulled automatically. Software agents pull the desired state from the source rather than having an external system push it in. This matters more than it sounds, and the next section explains why.
- Continuously reconciled. Agents constantly observe the actual state and act to converge it toward the desired state, including correcting drift and recovering from failures.
Notice what is absent: nothing in these principles mentions Kubernetes. That is deliberate. The OpenGitOps definition is deliberately generic, applying to any system with a declarative interface. In everyday conversation, though, most people mean Kubernetes, because that is where the tooling matured first.
Pull Versus Push: The Security Argument
The pull-based requirement confuses newcomers, so it deserves its own explanation. In a traditional CI/CD pipeline, a build server holds credentials to the production cluster and pushes changes into it. That means your CI system is a high-value target: compromise it and you own production.
In a pull model, the cluster reaches out to Git. The agent runs inside the cluster, watches the repository, and applies changes locally. No external system needs cluster credentials. Your CI pipeline only needs to build images and update a manifest, and the cluster decides when to fetch it.
There is a second benefit that practitioners appreciate more over time: drift detection. Push-based deployments tell you what happened at deploy time. Pull-based reconciliation tells you what is true right now. When someone hotfixes a deployment by hand at 2 a.m., the agent flags or reverts it, and you find out immediately rather than during the next incident review.
Tooling
Two tools dominate, and choosing between them is a common practical decision.
| Tool | Model | Strength | Typical Fit |
|---|---|---|---|
| Argo CD | Pull-based, in-cluster agent | Rich web UI, visual diffing, multi-cluster management | Teams that want visibility and a dashboard-first workflow |
| Flux | Pull-based, in-cluster controllers | Composable controllers, strong CLI and automation focus | Teams that prefer a toolkit assembled from small pieces |
| Terraform / OpenTofu controllers | Pull-based, extends pattern to cloud resources | Manages infrastructure outside Kubernetes | Organizations standardizing on one reconciliation model |
| Traditional CI push pipelines | Push-based | Simple, familiar | Not GitOps by the strict definition |
Both Argo CD and Flux are graduated CNCF projects, which signals production maturity and broad adoption. The choice between them usually comes down to culture rather than capability: Argo CD suits teams that want to see state in a browser, while Flux suits teams that live in a terminal and prefer to assemble their own stack.
For a broader look at how major vendors are rethinking cloud infrastructure behind the scenes, the analysis of Apple private cloud compute and Google cloud in 2026 offers useful context on where platform engineering is heading.
What GitOps Looks Like in Practice
A typical workflow runs like this:
- A developer opens a pull request that changes a container image tag in a manifest.
- CI builds and tests the image, then a reviewer approves the manifest change.
- The pull request merges to the main branch.
- The in-cluster agent detects the new commit within its polling interval.
- The agent applies the change and reports sync status.
- If the applied state diverges later, the agent reconciles it back.
The practical consequence is that every production change has an audit trail in the form of a commit, a reviewer, and a timestamp. For regulated industries, this alone justifies adoption. Auditors who once asked for screenshots of deployment logs can be pointed at a repository history.
Common Mistakes That Sink GitOps Projects
The pattern is simple in principle and easy to get wrong in practice. A few failure modes recur.
Storing secrets in Git. Plaintext credentials in a repository defeat the entire security model. Teams need a secrets manager or an encrypted-secrets tool, and they need it before the first commit, not after an incident.
Splitting the source of truth. If half the configuration lives in Git and half is applied by hand or by a legacy pipeline, reconciliation fights itself. The agent reverts manual changes, operators get frustrated, and eventually someone disables auto-sync. Decide early that Git wins, and migrate everything.
Treating the repository as a dumping ground. A single monorepo with no structure becomes unreviewable. Most teams separate application manifests from cluster-level infrastructure and use directory conventions or Kustomize overlays to manage environment differences.
Ignoring the reconciliation interval. Auto-sync sounds instant but is not. Understanding polling and webhook behavior matters when you are coordinating a deploy with a database migration.
Skipping the rollback plan. Reverting a commit is easy. Reverting a commit that also triggered a schema change is not. GitOps gives you the mechanism; it does not give you the discipline.
Where GitOps Fits Alongside Other Trends
GitOps is not isolated. It intersects with several broader shifts in how software organizations operate.
The rise of AI-assisted engineering is one. As teams lean on tools like Leonardo AI and its pricing plans for generative workloads, the infrastructure those models run on increasingly gets managed declaratively. Reproducibility matters more when a model’s behavior depends on its environment.
Biomedical research is another unexpected corner. Large computational pipelines in life sciences benefit from the same auditability, and the Zuckerberg Chan CZI Biohub shift toward AI in biomedical work illustrates how reproducible compute is becoming a research requirement rather than an ops nicety.
Even corporate events ripple through platform decisions. Discussions around a Tesla and SpaceX merger vote at the December 6 AGM show how governance and infrastructure strategy intertwine at scale, and how much organizations depend on traceable decision records.
Is GitOps Right for Your Team?
GitOps pays off most when three conditions hold: you run Kubernetes or another declaratively managed system, you have more than a handful of services, and you care about auditability or drift control.
It pays off least when you run a single monolith on a couple of virtual machines with a simple deploy script. Adding a reconciliation agent there is ceremony without benefit. The same applies to teams without review discipline: GitOps amplifies whatever process you already have, good or bad.
A reasonable middle path for many organizations is to start with one non-critical service, run it in read-only sync mode for a few weeks to observe drift, and only then enable automated reconciliation. Watching what drifts before you start auto-correcting teaches you more about your environment than any architecture document.
For teams that also consider operational risk outside the data center, the breakdown of home and household insurance coverage options is a reminder that redundancy and clear documentation matter in every domain, production clusters included.
Conclusion
GitOps succeeded because it turned an operational problem into a software problem. Instead of asking how to safely change production, teams ask how to review and merge a pull request, a workflow they already trust. The four OpenGitOps principles, declarative state, immutable versioning, automatic pulling, and continuous reconciliation, are strict enough to be meaningful and flexible enough to apply beyond Kubernetes.
The model is not a silver bullet. It demands secrets discipline, a single source of truth, and a rollback plan that accounts for stateful changes. Teams that treat it as a checkbox end up disabling auto-sync within a quarter. Teams that treat it as an operating discipline, one where Git genuinely wins every argument about what production should look like, get something rarer than automation: a system whose current state is always explainable by reading a commit log.
What is the difference between GitOps and DevOps?
DevOps is a broad cultural and organizational movement focused on collaboration between development and operations. GitOps is a specific technical operating model within that movement. You can practice DevOps without GitOps, and you can implement GitOps in an organization with weak DevOps culture, though the results are usually worse. GitOps is best understood as one concrete way to deliver on DevOps goals like fast feedback and reliable releases. (GitOps)
Does GitOps only work with Kubernetes?
No, though Kubernetes is where the tooling and community practice are most mature. The OpenGitOps principles are defined generically for any system with a declarative interface. Terraform and OpenTofu controllers extend the pattern to cloud infrastructure, and some teams apply it to network devices and configuration management. In practice, most adoption starts with Kubernetes because Argo CD and Flux make it straightforward there.
Why is pull-based deployment considered more secure than push?
In a push model, an external CI system holds credentials to production, making it a valuable target for attackers. In a pull model, an agent inside the cluster fetches changes from Git, so no external system needs production credentials at all. The blast radius of a compromised CI pipeline shrinks considerably, and the cluster controls the timing of its own updates.
What happens if someone changes production manually?
The reconciliation agent detects the difference between the live state and the desired state in Git, then either flags it or reverts it, depending on configuration. Most teams start with alerting only and move to automatic correction once they trust the setup. This drift detection is one of the most valued features in practice, because it surfaces undocumented changes immediately rather than during an incident.
How do you handle secrets in a GitOps repository?
Never commit plaintext secrets. Teams typically use an external secrets manager that injects values at runtime, or an encryption tool that lets encrypted secrets be safely stored alongside manifests. The important rule is that the repository remains the source of truth for structure while sensitive values are resolved separately. Getting this wrong is the most common security failure in early GitOps adoptions.
Can GitOps handle database migrations?
Partially. GitOps manages the declarative state of the database infrastructure and can trigger migration jobs, but it cannot make a schema change inherently reversible. Reverting a commit does not undo a destructive migration. Teams need a separate migration strategy with backward-compatible changes and careful sequencing, treating GitOps as the delivery mechanism rather than the safety net.
