What if the most powerful deployment tool in your company was one you already use every day: a Git repository? That is the core idea behind GitOps, an operating model that has moved from a niche Kubernetes pattern to a mainstream way of running infrastructure. It changes who can change production, how changes are audited, and what happens when someone edits a live system by hand at 2 a.m.
This article explains what GitOps actually is, where it came from, how the reconciliation loop works, where it fits and where it does not, and the mistakes teams make when they adopt it.
What GitOps actually means
GitOps is an operational model in which a Git repository holds the desired state of your infrastructure and applications, and software agents continuously make the live system match that state. Nothing is deployed by a human running a command against production. Instead, a machine compares what Git says should exist with what actually exists, and closes the gap.
The term was coined in 2017 by Alexis Richardson, then CEO of Weaveworks, in a blog post about self-service IT. Weaveworks closed in early 2024, but the idea outlived the company. The OpenGitOps project, a working group under the Cloud Native Computing Foundation, now maintains a vendor-neutral specification of the principles.
Those principles are short enough to memorize:
- Declarative. The desired state is expressed as data, not as a list of imperative commands.
- Versioned and immutable. That state lives in Git, so every change has a commit, an author, and a timestamp.
- Pulled automatically. Agents inside the target environment fetch the desired state themselves; nobody pushes it in from outside.
- Continuously reconciled. Software constantly compares desired and actual state and corrects drift.
The fourth principle is the one that surprises newcomers. GitOps is not a deployment event. It is a loop that never stops running.
The reconciliation loop, step by step
The mechanics are simpler than the vocabulary suggests. A typical cycle looks like this:
- An engineer opens a pull request changing a manifest, a Helm value, or a Terraform variable.
- A reviewer approves it, and the change merges to the deployment branch.
- An agent running inside the cluster, such as Argo CD or Flux, notices the new commit.
- The agent compares the rendered desired state with the live state of the cluster.
- It applies the difference: creating, updating, or deleting resources.
- It reports health and sync status back to a dashboard and often to a chat channel.
- Minutes later, it checks again. If someone edited a live object by hand, the agent reverts it.
That last step is where drift gets handled. Drift is any difference between what Git declares and what is actually running: a hotfix applied with kubectl, a resource deleted during an incident, a configuration changed through a cloud console. In a GitOps model, drift is not a permanent state. It is a temporary condition that the reconciler erases.
Pull versus push, and why it matters for security
Traditional CI/CD pipelines push. A build server holds credentials for the target environment, and at the end of a pipeline it authenticates and applies changes. That works, but it means your CI system, and everyone who can alter a pipeline, has production access.
GitOps inverts the direction. The agent lives inside the environment and pulls from Git. The cluster’s credentials never leave the cluster. The CI system’s only job is to build artifacts and update a manifest. Flux’s documentation describes this pull-based architecture in detail, and the Argo CD documentation covers the same model from the application-sync side. (Pro Git book (official Git documentation))
The practical benefit is a smaller blast radius. If your CI runner is compromised, an attacker can propose changes to Git, but they still need to get them merged. They cannot simply apply whatever they want.
The trade-off is equally real, and it is the point most teams underestimate: the trust boundary moves to your Git repository. Whoever can merge to the deployment branch can change production. Branch protection rules, required reviews, signed commits, and tightly scoped repository permissions stop being paperwork and become production security controls. Treat your deployment repository the way you treat your cloud account.
A short history and the tools available
GitOps grew up alongside Kubernetes, and the two are still closely associated. Kubernetes objects are declarative by design, so storing them in Git and reconciling them is a natural fit. The official Kubernetes concepts documentation is the right starting point if declarative resource management is new to you.
Two projects dominate the tooling conversation, and both are CNCF projects:
| Tool | Origin | Model | Typical strength |
|---|---|---|---|
| Flux | Started at Weaveworks, donated to the CNCF, now community-maintained | Set of composable controllers | Lightweight, modular, strong at multi-tenant setups |
| Argo CD | Intuit | Centralized application controller with a UI | Rich visual dashboard, application-centric view |
Both implement the same four principles. The choice usually comes down to team preference, existing UI needs, and how much modularity you want. Neither is a wrong answer, and neither replaces good repository hygiene.
What GitOps is not
A lot of confusion comes from conflating GitOps with adjacent practices. The distinctions matter because they tell you what GitOps will and will not fix. (GitOps)
It is not CI. Continuous integration builds and tests code. GitOps handles the delivery of the resulting desired state. Most teams run both, with CI writing to a manifest repository and the GitOps agent doing the deploying.
It is not infrastructure as code by itself. Terraform and similar tools describe infrastructure declaratively, but running them from a laptop is not GitOps. You need the versioned source of truth plus automated reconciliation.
It is not a rollback button. Rolling back means reverting a commit. That is elegant and auditable, but it only works cleanly if your changes are truly declarative and your data migrations are handled separately. A database schema change does not un-happen because you reverted a YAML file.
It is not Kubernetes-only. The principles are written to be platform-agnostic. In practice, most adoption starts with Kubernetes because the ecosystem is mature there, but teams apply the same pattern to cloud resources and virtual machines.
Where GitOps pays off, and where it strains
The model shines in a few specific situations. Audit trails are the clearest win: every production change has a commit, a reviewer, and a linked ticket. Disaster recovery gets easier because a lost cluster can be rebuilt from the repository. Onboarding improves because new engineers can read the repository to understand how the system is configured. And configuration drift, the slow rot that makes environments diverge, gets corrected automatically instead of accumulating.
It strains in others. Secrets cannot live in Git in plaintext, so you need an external secret store or a sealed-secrets approach, which adds complexity. Teams with heavy manual approval processes sometimes find that the reconciliation loop fights them. Very fast-moving environments where engineers expect to patch live systems during incidents will feel friction until the culture adjusts. And if your manifests are generated by an opaque templating layer, the repository stops being readable, which quietly defeats the purpose.
For teams building out the surrounding platform, the broader cloud and infrastructure coverage on 9481.org’s cloud section is a useful companion read, and current tooling news appears under the news category.
Common mistakes and what actually works
Most GitOps failures are process failures, not tool failures. These are the patterns that show up again and again.
One giant repository for everything. It seems tidy until every team needs merge rights to the same place, and a single bad commit can affect unrelated systems. Splitting by team or by environment, with clear ownership, usually works better.
No environment separation. Applying the same manifests to staging and production without a clear promotion path means a merge can hit production directly. Use separate branches, directories, or repositories, and make the promotion step explicit.
Skipping the review discipline. If reviewers rubber-stamp manifest changes because “it’s just config,” you have automated the deployment of unreviewed changes. The pull request is now your change control, so treat it that way.
Ignoring the agent’s health. A reconciler that has been failing silently for three days is worse than no reconciler, because everyone believes the cluster matches Git. Alert on sync failures and on drift, as well as on pod crashes.
Forgetting that reconciliation is not instant. The gap between merge and rollout is measured in polling intervals, not seconds. Design your incident runbooks around that.
What works in practice is unglamorous: small repositories with clear ownership, protected branches with required reviews, a single obvious path from staging to production, alerts on sync status, and a written rule that emergencies are fixed by merging a revert rather than by editing the cluster. Teams that follow those habits get the audit trail and the recovery story. Teams that skip them get a slower version of what they had before.
Conclusion
GitOps is less a product than a discipline: declare what you want, store it in Git, and let software make reality match. Its real gift is not automation but legibility. Anyone with repository access can see exactly what production is supposed to look like, who changed it, and when. The cost is that your Git permissions become production permissions, and your review process becomes your change control board. Teams that understand that trade-off get a system that is easier to audit, easier to rebuild, and harder to break by accident. Those who treat GitOps as a tool to install rather than a habit to build tend to end up with a fancier pipeline and the same old problems.
Frequently asked questions
Is GitOps only for Kubernetes?
No. The four OpenGitOps principles are written to be platform-agnostic, and teams apply them to cloud infrastructure, virtual machines, and network configuration. Kubernetes is simply where the tooling is most mature and where most organizations start, because Kubernetes resources are already declarative.
Do I still need a CI pipeline with GitOps?
Yes, and the two do different jobs. Continuous integration builds, tests, and scans your code and container images, then updates a manifest with the new version. The GitOps agent handles delivery by reconciling the cluster to that manifest. Removing CI would leave you with no automated testing before a change reaches the deployment branch.
How do secrets work if everything lives in Git?
They generally do not live in Git in plaintext. Common approaches store encrypted secrets in the repository, or keep secrets in an external vault and have the cluster fetch them at runtime, with Git holding only a reference. This is one of the main sources of added complexity in a GitOps rollout, so plan for it early rather than retrofitting later.
What happens if someone changes production manually?
The reconciler detects the difference between the declared state and the live state and reverts it on its next pass. That is the drift-correction property. In practice, teams usually want an alert when this happens, because a manual change often signals that someone was working around a broken process that needs fixing.
Is GitOps safe for regulated environments?
It can be, and often it helps. Every production change carries a commit hash, an author, a timestamp, and a reviewer, which maps well onto change-management evidence requirements. The caveat is that the audit trail is only as good as your branch protection rules. If anyone can merge without review, the evidence shows an unreviewed change.
Which tool should a new team pick, Flux or Argo CD?
Both implement the same principles, so the decision is mostly about fit. Argo CD offers a centralized application view with a strong visual interface, which many teams find easier to adopt. Flux is a set of composable controllers that some teams prefer for modular, multi-tenant setups. Try one on a non-critical cluster before committing, and check the project documentation for the current feature set.
For ongoing context on platform engineering and delivery practices, the 9481.org blog covers related topics in more depth.
