What if every change to your servers and apps had to go through the same review process as a code change? No secret logins. No one-off scripts run at midnight. Just a pull request, a review, and an automatic rollout. That idea is the heart of GitOps, a term that has gone from a niche blog post to one of the most talked-about practices in cloud computing. But ask ten engineers to define it and you may get ten slightly different answers. This article cuts through the noise: where the term came from, what the core principles actually say, how it differs from older approaches, and where the definition gets fuzzy. (Blog)
Where the GitOps Term Came From
The word GitOps was coined in a 2017 blog post by Alexis Richardson, then CEO of Weaveworks. He described it as a way to manage Kubernetes clusters and deliver applications in which the entire system is described declaratively and versioned in Git, with an automated process making sure the running system matches what is stored in the repository. The name itself is a simple mashup: Git plus operations. (Pro Git Book)
The timing mattered. Kubernetes was spreading fast, and teams were drowning in YAML files, manual kubectl commands, and drift between what they thought was deployed and what was actually running. GitOps offered a mental model that felt familiar to developers: treat infrastructure like application code, store it in version control, and let automation handle the rest.
A year later, Weaveworks published a follow-up post that laid out what many people still call the four principles of GitOps: the whole system is described declaratively, the desired state is versioned in Git, approved changes are applied automatically, and software agents continuously observe and reconcile the actual state against the desired state. That framing spread widely, even though the exact wording has been repeated and paraphrased so often that pinning down the original text is harder than it should be.
The Vendor-Neutral Definition: OpenGitOps
Vendor blogs are useful, but they have an obvious incentive to describe the world in a way that favors their product. That is why the OpenGitOps project, which sits under the Cloud Native Computing Foundation, published a set of vendor-neutral principles. These are the closest thing the industry has to an agreed-upon definition. The OpenGitOps principles describe a system that is:
- Declarative. The desired state is expressed as facts about what the system should look like, not as a list of commands to run.
- Versioned and immutable. The desired state is stored in a way that keeps a complete history, so you can see what changed, when, and why.
- Pulled automatically. Software agents pull the desired state from the source rather than having it pushed to them by an outside system.
- Continuously reconciled. Agents keep watching and correcting the live system so it stays in line with the desired state.
If you want the full text and the reasoning behind each point, the OpenGitOps project publishes the complete set of GitOps principles. Notice what is not in that list: no mention of a specific tool, no requirement that you use Kubernetes, and no endorsement of any vendor. That neutrality is deliberate. It also explains why the definition travels well beyond the Kubernetes world where it started.
The CNCF also keeps a glossary entry that defines GitOps as a set of practices using Git repositories as the single source of truth for declarative infrastructure and applications, with automated agents reconciling the live state to the declared state. Short, practical, and consistent with the principles above.
Declarative, Versioned, Pulled, Reconciled: What Each Piece Means
The four principles sound abstract until you see them in action. Here is what each one actually changes about the way a team works.
Declarative means you describe the end result, not the steps. Instead of a script that says “create three servers, then install this package, then open this port,” you write a file that says “there should be three servers with this package and this port open.” The system figures out how to get there. This is the same shift that made Kubernetes popular, and it is the foundation everything else rests on.
Versioned and immutable means every change is a commit. You get a full audit trail for free: who changed what, when, and why, all tied to a review conversation. If something breaks, rolling back is a revert, not an archaeology project. This is also where GitOps earns its security reputation, because the repository becomes the only place where changes can originate.
Pulled automatically is the principle that causes the most debate. In a pull-based model, an agent running inside the cluster watches the repository and pulls changes when they appear. Nothing outside the cluster needs credentials to reach in. That is a real security difference from older pipelines where a CI server holds broad keys and pushes deployments directly.
Continuously reconciled is what separates GitOps from a one-time deployment. The agent does not apply changes once and walk away. It keeps comparing the live state to the desired state and corrects drift. If someone edits a resource by hand at 2 a.m., the agent notices and puts it back.
GitOps vs. Infrastructure as Code vs. CI/CD
People often use these terms interchangeably, which causes real confusion in job interviews and architecture reviews. They are related, but they are not the same thing.
| Concept | Core idea | What it adds |
|---|---|---|
| Infrastructure as Code | Define infrastructure in files instead of manual steps | Repeatability and version control |
| CI/CD | Automate building, testing, and delivering software | Faster, more reliable releases |
| GitOps | Use Git as the source of truth, with agents that reconcile continuously | Drift correction and a full audit trail |
A useful way to think about it: Infrastructure as Code is the raw material, CI/CD is the delivery pipeline, and GitOps is the operating model that ties them together. Some practitioners treat GitOps as a subset of Infrastructure as Code. Others see it as a superset that adds continuous reconciliation on top. Both views appear in the wild, and neither is clearly wrong.
The practical difference shows up in day-to-day work. With a traditional push pipeline, a deployment succeeds the moment the pipeline finishes, even if the cluster drifts out of shape five minutes later. With GitOps, the deployment is never really “done.” The agent keeps checking, which means the system self-heals but also means you need to trust your reconciliation loop.
The Pull vs. Push Debate
If there is one place where definitions of GitOps genuinely conflict, it is the pull model. The OpenGitOps principles list automatic pulling as a core requirement. But plenty of teams run what they call GitOps with a pipeline that pushes changes into the cluster after reading from Git. Is that still GitOps? (GitOps)
The honest answer is that the community has not settled this. Some argue that without pull-based reconciliation, you have version-controlled deployments but not GitOps. Others say the label matters less than the outcome: Git as the source of truth, automation applying changes, and drift being corrected. For a deeper look at how the pull model works in practice, the Argo CD documentation walks through the reconciliation loop step by step, and the Flux documentation shows an alternative reference implementation of the same principles.
For teams making this decision, the practical guidance is simple. If security and credential management are your main concern, pull-based is worth the extra setup. If you are migrating an existing push pipeline and want incremental progress, start there and tighten later. What actually fails in practice is claiming GitOps while still allowing manual changes to slip past review.
What GitOps Looks Like in Real Teams
The theory is clean. The practice is messier. Here are the patterns that tend to work and the mistakes that tend to hurt.
What works:
- Keeping one repository per environment or per team, with clear ownership, so reviews do not become bottlenecks.
- Treating the repository as the only path to production. If a change can bypass Git, the audit trail is a fiction.
- Starting small. One application, one cluster, one agent. Prove the loop works before scaling.
- Automating the boring parts: policy checks, secret management, and drift alerts.
Common mistakes:
- Storing secrets in plain text in the repository. Git history is forever, and a leaked key is a leaked key.
- Letting the repository sprawl into hundreds of unowned folders until nobody knows which file controls what.
- Forgetting that reconciliation can fight with autoscaling or other dynamic systems if the desired state is too rigid.
- Assuming GitOps replaces testing. It does not. It changes how changes reach production, not whether they are correct.
A recurring theme in industry coverage is that GitOps adoption succeeds when it is treated as a cultural shift, not merely a tool install. Teams that keep the old habits, like hotfixing production by hand, end up with the worst of both worlds. You can follow how these practices evolve across the industry in the news section at 9481.org, which tracks cloud and operations trends as they develop. (News)
The Tooling Options
Two tools dominate the conversation: Argo CD and Flux. Both are CNCF projects, both implement the pull-based reconciliation model, and both have large communities. Argo CD leans toward a visual dashboard and application-centric management. Flux leans toward a composable, command-line-first approach. Neither is objectively better; the choice usually comes down to team preference and existing workflows.
Beyond those two, the tool set includes policy engines, secret managers, and progressive delivery tools that plug into the reconciliation loop. The important thing to remember is that none of these tools define GitOps. They implement it. If you swapped every tool tomorrow, the principles would still stand. That separation between definition and implementation is exactly what the vendor-neutral framing was designed to protect.
For readers who want to see how these tools fit into wider cloud architecture, the cloud category at 9481.org covers related topics like infrastructure automation and platform engineering. And for a broader view of how teams are putting these ideas into practice, the blog at 9481.org collects practical write-ups on operations workflows. (Cloud)
Why the Definition Keeps Shifting
GitOps started as a Kubernetes management technique. Today it is applied to cloud resources, edge devices, and even machine learning pipelines. Each new domain stretches the definition. Does GitOps require Kubernetes? The principles say no, but most tooling assumes it. Does it require a specific Git provider? No, though the tool market leans heavily on GitHub and GitLab.
There is also no formal standards body definition. No ISO or IEC standard defines GitOps, which means the term is shaped by community consensus rather than a committee. That is both a strength and a weakness. It keeps the practice flexible and vendor-neutral, but it also means marketing departments can stretch the word until it means almost anything.
The most reliable way to judge whether something is genuinely GitOps is to check it against the four principles. If a system is declarative, versioned, pulled, and continuously reconciled, it qualifies. If it is missing reconciliation, it is something else wearing the label.
Conclusion
The GitOps definition is simpler than the debate around it suggests. It is a set of practices that use Git as the single source of truth for declarative systems, with automated agents that continuously reconcile the live state to the desired state. It grew out of Kubernetes management, but its principles are tool-agnostic and increasingly apply to any infrastructure a team wants to run reliably.
What makes GitOps valuable is not the label. It is the audit trail, the drift correction, and the discipline of routing every change through review. Teams that adopt those habits, whether they use Argo CD, Flux, or something else entirely, get the real benefit. Teams that adopt the vocabulary without the practices get a repository full of YAML and the same old problems.
Frequently Asked Questions
What is GitOps in simple terms?
GitOps is a way of managing infrastructure and applications where all the desired settings live in a Git repository, and automated software keeps the live system matching that repository. Instead of running commands by hand, you make a change in Git, and the system applies it automatically and keeps checking that nothing drifts.
Who invented GitOps?
The term was coined by Alexis Richardson, then CEO of Weaveworks, in a 2017 blog post about self-service IT. Weaveworks later popularized the four-principles framing, and the vendor-neutral OpenGitOps project under the CNCF published a formal set of principles that most of the industry now references.
Is GitOps the same as Infrastructure as Code?
No, though they overlap. Infrastructure as Code means defining infrastructure in files instead of manual steps. GitOps adds Git as the source of truth plus continuous reconciliation by automated agents. You can practice Infrastructure as Code without GitOps, but GitOps almost always includes Infrastructure as Code.
Does GitOps require Kubernetes?
Not according to the principles. GitOps originated in Kubernetes management, and most tools assume it, but the core ideas, declarative state, version control, and continuous reconciliation, can apply to cloud resources, edge devices, and other systems. In practice, most teams adopting GitOps today are running Kubernetes.
What is the difference between push and pull in GitOps?
In a push model, an external system like a CI server sends changes into the cluster. In a pull model, an agent inside the cluster watches Git and pulls changes itself. Pull-based is considered a core GitOps principle because it avoids giving outside systems broad credentials, though some teams run push-based setups and still call them GitOps.
What are the most common GitOps tools?
Argo CD and Flux are the two most widely used tools, and both are CNCF projects that implement pull-based reconciliation. The wider tool set also includes policy engines, secret managers, and progressive delivery tools that plug into the reconciliation loop. The tools implement GitOps; they do not define it.
