In early 2024, the company that coined the term “GitOps” shut its doors. Weaveworks, the London-based startup that popularized the idea, closed after roughly seven years of championing it. You might expect the concept to fade with its loudest evangelist. Instead, GitOps kept spreading, because the idea had already outgrown the company that named it. That is the strange, useful story behind one of the most durable operating models in modern infrastructure. (What is GitOps?)
What Is GitOps? A Plain Definition
GitOps is an operating model in which the desired state of infrastructure and applications is declared in Git, and automated software agents continuously reconcile the live system to match that declared state.
Read that sentence twice; the wording is exact. The desired state lives in version control. A machine agent runs inside or alongside the target environment. It pulls changes instead of waiting for a pipeline to push them. And it reconciles continuously, rather than once during deployment.
The term was coined around 2017 by Alexis Richardson, then CEO of Weaveworks. The core insight was simple but powerful: if Git already holds the single source of truth for your code, why not let it hold the truth for everything else too?
The Four OpenGitOps Principles That Define It
The OpenGitOps project, a vendor-neutral effort under the Cloud Native Computing Foundation (CNCF), distilled the model into four principles and published version 1.0 of those principles in 2022. They are the closest thing the industry has to an official definition.
| Principle | What It Means in Practice |
|---|---|
| Declarative | The entire desired state is expressed as declarations, not as a list of imperative commands. You describe what you want, not how to get there. |
| Versioned and immutable | The desired state is stored in a way that preserves full history and immutability. Git is the canonical example, though the principle is tool-agnostic. |
| Pulled automatically | Software agents pull the desired state from the source. Nobody hands the cluster a deployment package; it fetches one. |
| Continuously reconciled | Agents constantly compare actual state to desired state and act to close any gap, including drift caused by manual changes. |
That fourth principle is the one teams underestimate. Most people picture GitOps as “deploying with Git.” The reconciliation loop is what actually makes it GitOps. A pipeline that applies a manifest once and walks away is not doing GitOps, no matter how much YAML it pushed. (GitOps)
How GitOps Differs From Traditional CI/CD
Here is where confusion creeps in. Many teams already run continuous integration and continuous delivery pipelines, so GitOps can sound like a rebrand. It is not. The difference is architectural, and it shows up most clearly in the direction of trust.
| Dimension | Traditional Push-Based CI/CD | GitOps |
|---|---|---|
| Direction of deployment | Pipeline pushes changes into the cluster | Cluster-side agent pulls changes from Git |
| Credentials | CI system holds cluster credentials | Cluster holds read access to Git; CI never touches production |
| Source of truth | Pipeline configuration and scripts | Git repository |
| Drift handling | Detected manually or not at all | Reconciled continuously by an agent |
| Rollback | Re-run a previous pipeline | Revert a commit |
| Audit trail | Scattered across pipeline logs | Native Git history |
In a push model, your CI server is a very privileged machine. If it is compromised, so is production. In a pull model, the CI system builds and tests artifacts, then updates a manifest. The cluster notices the change on its own. That separation of duties is a genuine security improvement, and it is one reason regulated industries have warmed to the model.
Argo CD and Flux
GitOps is not tied to Kubernetes, but Kubernetes is where it grew up, and two CNCF projects dominate the space.
Argo CD is a declarative continuous delivery tool that treats a Git repository as the source of truth for application definitions. It ships with a visual dashboard, which explains much of its popularity with platform teams who need to show non-engineers what is running where. Both Argo CD and Flux reached graduated status within the CNCF in 2022, signaling broad production adoption.
Flux takes a more composable approach, built from a set of controllers that each handle a slice of the reconciliation job. Teams that prefer assembling their own stack tend to favor it.
Neither tool is mandatory. The principles matter more than the product. A team using a homegrown reconciler that follows the four principles is doing GitOps; a team using Argo CD to run one-off push commands is not.
Why Teams Adopt It: The Practical Benefits
Strip away the marketing and the benefits are concrete.
Auditability comes free. Every change to production is a commit with an author, a timestamp, and a message. When something breaks at 2 a.m., you can ask Git what changed and who changed it. That is a far better answer than digging through pipeline logs on three different systems.
Recovery gets simpler. If a cluster is destroyed, the agent re-syncs everything from Git. Disaster recovery becomes a reinstall plus a sync, not an archaeology project.
Drift becomes visible. Someone edits a deployment by hand during an incident. In a push model, that change lingers invisibly until the next deploy overwrites it. In a GitOps model, the agent reverts it or flags it. Both outcomes are better than silence.
Onboarding improves. New engineers read the repository to understand how the system is wired. The infrastructure documents itself, at least in theory.
Common Mistakes and What Actually Works
First-hand accounts from platform teams converge on a handful of pitfalls. These are not edge cases; they are the norm.
Storing secrets in Git. This is the classic mistake. Plain-text credentials in a repository, even a private one, is a breach waiting to happen. Working teams use sealed secrets, external secret operators, or a dedicated vault that injects values at runtime. The Git repository should hold references, never raw secrets.
Letting repositories sprawl. Ten teams, ten repos, ten different conventions, and suddenly nobody can answer “what is deployed right now?” A platform repository with clear ownership boundaries and consistent structure solves this. It requires governance, and governance requires someone to own it.
Skipping the reconciliation interval. Agents sync on a schedule and on webhooks. Teams that rely only on webhooks get burned when a webhook fails silently. Short polling intervals catch what webhooks miss.
Treating GitOps as a CI replacement. It is not. You still need to build, test, and scan images. GitOps governs the delivery and runtime state, not the build pipeline.
Ignoring the learning curve. Git becomes a production control plane. That means branch protection, review requirements, and permissions matter enormously. A careless merge can now change production. Teams that treat the repo casually learn this lesson the hard way.
What actually works, in practice, is starting narrow. Pick one non-critical service. Wire up a single agent. Watch the reconciliation loop do its job. Then expand. The organizations that succeed treat GitOps as an operating discipline, not a tool installation.
GitOps Beyond Kubernetes
The principles are portable, and adoption is spreading. Database schema management, network configuration, and even machine learning model deployments increasingly follow the same pattern: declare state, version it, reconcile continuously. The pull-based model fits any system that can run an agent and expose its current state.
The Weaveworks shutdown in 2024 raised eyebrows, but the ecosystem barely flinched. Argo and Flux are CNCF projects with broad contributor bases, and the OpenGitOps principles are stewarded by a vendor-neutral foundation. The concept outlived its creator, which is usually the sign of an idea with real substance.
For teams weighing whether to adopt it, the honest answer is that GitOps solves specific problems: auditability, drift, recovery, and credential exposure. If those problems are not yours, the added complexity may not pay off. If they are, few models address them as cleanly.
Conclusion
GitOps is not a tool, a product, or a rebrand of CI/CD. It is an operating model built on four principles: declarative state, versioned and immutable storage, automatic pulling, and continuous reconciliation. Git holds the truth. Agents enforce it. Humans review the commits. That loop, simple as it sounds, changes how teams reason about production. The term survived the company that coined it because the model works, and the four principles give teams a clear yardstick for judging whether their setup deserves the name.
Frequently Asked Questions
What is GitOps in simple terms?
GitOps means storing the desired state of your systems in Git and letting automated agents keep the live environment matching that stored state. You change a file, commit it, and the system updates itself. Git becomes the single source of truth, and the agent handles the rest.
Who coined the term GitOps?
Alexis Richardson, then CEO of Weaveworks, coined the term around 2017. Weaveworks popularized the concept through blog posts and open-source tooling. The company shut down in early 2024, but the model continued to grow through CNCF projects and the OpenGitOps initiative.
Is GitOps the same as CI/CD?
No. CI/CD pipelines typically push changes into an environment, and the CI system holds privileged credentials. GitOps reverses the direction: an agent inside the environment pulls changes from Git. CI still builds and tests artifacts, but it does not deploy them directly.
Do you need Kubernetes to do GitOps?
No. Kubernetes is where GitOps gained traction because its declarative nature fits the model well, but the four OpenGitOps principles are tool-agnostic. Any system that can run a reconciliation agent and expose its state can follow the pattern.
What are the four GitOps principles?
The OpenGitOps project defines them as declarative, versioned and immutable, pulled automatically, and continuously reconciled. Version 1.0 of these principles was published in 2022. Together they distinguish genuine GitOps from simple scripted deployment.
What is the biggest mistake teams make with GitOps?
Storing plain-text secrets in Git. It is common, convenient, and dangerous. Working teams keep credentials out of the repository entirely, using sealed secrets, external secret managers, or vault injection at runtime. The repo should hold references to secrets, never the secrets themselves.
The second most common mistake is subtler: treating the repository as a dumping ground rather than a contract. A GitOps repo is an interface between teams, and interfaces need design. Environment promotion, for example, should be explicit — a pull request from staging to production manifests, reviewed like any other change. When promotion happens through ad-hoc directory copies or manual tag edits, the audit trail degrades into guesswork, and the model loses the very property that justified it.
There is also a cultural point worth stating plainly. GitOps shifts authority from operators with cluster access to reviewers with merge rights. That is a governance change as much as a technical one, and it will surface organizational friction. Teams accustomed to hotfixing directly in production will feel constrained. The answer is not to weaken the model but to make the Git path fast: short review cycles, automated policy checks, and clear ownership so that a legitimate fix can move through the pipeline in minutes, not days.
Looking ahead, expect the reconciliation pattern to keep absorbing adjacent problems. Policy-as-code engines already hook into the same loop, rejecting non-compliant state before it lands. Progressive delivery tools layer canary analysis on top of the sync. The principles stay constant while the surface area grows.
For anyone starting today, the advice is unglamorous and effective: read the OpenGitOps principles once, pick a single workload, and let the loop run. Watch what it does when someone edits a resource by hand. That demonstration converts skeptics faster than any slide deck. GitOps earns belief through observation, not argument — and once a team has seen drift corrected automatically, going back to push-based deploys feels like flying blind.
