Key Takeaways
- GitOps manages Kubernetes deployments by treating Git as the single source of truth, with an in-cluster agent pulling and reconciling the desired state automatically.
- The shift from push-based to pull-based deployment is the single biggest architectural change, and it materially improves the security posture by keeping cluster credentials inside the cluster.
- Argo CD and Flux, both CNCF graduated projects, dominate the tooling landscape, with CNCF's own 2025 survey showing 97% of Argo CD users running it in production and roughly 60% of surveyed clusters managed through it.
- Adoption estimates vary by survey methodology, ranging from about 42% to roughly two-thirds of organizations, but the trend line points firmly toward GitOps becoming the default way to run Kubernetes at scale.
- The switch pays off most clearly in rollback speed, audit trails, and reduced attack surface, but it does require real planning around secrets management and repository structure before you see those benefits.
Kubernetes solved a lot of problems. It also created a new one: once you're running twenty, fifty, or two hundred clusters, how do you keep track of what's supposed to be running where, and roll back safely when something breaks? Manually applying kubectl commands doesn't scale, and neither does trusting a CI pipeline with standing production credentials. GitOps is the answer the cloud-native community settled on, and it's now the default way mature teams manage Kubernetes.
This post explains what GitOps is, how it changes the mechanics of deploying to Kubernetes, and what the adoption data says about where teams are on that journey in 2026. You'll also find comparison tables you can use as a quick reference for your own team.
What Is GitOps, Exactly?
GitOps is a way of managing infrastructure and application deployments where Git is the single source of truth. Instead of an engineer or a pipeline pushing changes directly to a cluster, you commit the desired state, what your infrastructure and applications should look like, to a Git repository. An automated agent running inside the cluster continuously compares that desired state against what's actually running, and reconciles any difference.
IBM's own definition of the practice frames it around exactly this idea: a methodology built on version control, collaboration, compliance, and CI/CD tooling, applied to both infrastructure automation and application deployment. The core shift is subtle but important. You stop telling the system what to do, and start declaring what it should look like. The system figures out how to get there.
The Four Principles That Define GitOps
Most descriptions of GitOps converge on the same four principles:
- Declarative configuration. The entire desired state of your system, infrastructure and applications, is expressed as code (usually YAML or similar manifests), not as a sequence of imperative commands.
- Git as the single source of truth. Every environment definition, every policy, and every change lives in version control, with a complete audit trail of who changed what and when.
- Automated pull-based reconciliation. Rather than a CI/CD pipeline pushing changes into the cluster from the outside, an in-cluster agent (like Argo CD or Flux) pulls the desired state from Git and applies it. This is the detail that most changes the security model, since the cluster's credentials never have to leave the cluster.
- Continuous, automated drift correction. If someone manually changes something in the cluster outside of Git (a "hotfix" applied directly with kubectl, for example), the GitOps agent detects the drift and reconciles it back to what's declared in Git.
How GitOps Changes the Deployment Model
To see why this matters, it helps to compare it directly to the CI/CD pattern most teams started with.
| Aspect | Traditional Push-Based CI/CD | GitOps (Pull-Based) |
|---|---|---|
| Who initiates the deployment | The CI/CD pipeline pushes changes into the cluster. | An in-cluster agent pulls changes from Git. |
| Where cluster credentials live | Often stored in the CI/CD system, outside the cluster. | They stay inside the cluster and are never exposed externally. |
| Source of truth | Deployment scripts and pipeline configuration. | The Git repository itself. |
| Change process | Direct kubectl apply commands or scripted deployments. | Pull request, review, merge, and then automatic synchronization. |
| Rollback | Re-run a previous pipeline job or manually revert changes. | Revert a Git commit, and the cluster reconciles automatically. |
| Auditability | Information is scattered across CI logs, tickets, and Slack threads. | A complete, centralized history exists in Git commit logs. |
| Drift handling | No built-in detection, so manual changes can go unnoticed. | Configuration drift is continuously detected and automatically corrected. |
| Access model | The cluster API is often exposed to external systems. | The cluster API can remain completely closed to the outside. |
The security implication is worth sitting with. In a push-based model, if your CI/CD pipeline is compromised, an attacker potentially has a path into every environment that pipeline can reach. In a pull-based GitOps model, credentials never leave the cluster, and the cluster's API doesn't need to be reachable from outside at all. That single architectural change removes a common single point of failure.
GitOps Tools: Argo CD vs. Flux at a Glance
Two open-source projects dominate the GitOps tooling landscape, and both are graduated projects under the Cloud Native Computing Foundation (CNCF).
| Feature | Argo CD | Flux |
|---|---|---|
| Interface | Rich web UI plus CLI. | Primarily CLI and Kubernetes-native CRDs. |
| Governance | CNCF graduated project. | CNCF graduated project. |
| Multi-cluster management | Strong and widely used in production at scale. | Strong and often paired with other CNCF tools. |
| Learning curve | Slightly gentler thanks to the UI. | Steeper initially, but very composable once learned. |
| Ecosystem fit | Popular as a standalone GitOps control plane. | Frequently used within broader platform toolchains. |
Adoption data gives a clear signal about where the market has settled. CNCF's 2025 Argo CD End User Survey found that 97% of respondents were running Argo CD in production, up from 93% two years earlier, with roughly 60% of respondents' Kubernetes clusters now managed through it. The same survey recorded a Net Promoter Score of 79, an unusually high satisfaction number for infrastructure tooling.
What the Adoption Numbers Actually Say
GitOps has moved well past the early-adopter phase, though the exact adoption percentage depends on which survey you're reading and which population it sampled.
The gap between the 42% and "two-thirds" figures isn't a contradiction so much as a reflection of how differently "GitOps adoption" gets defined across surveys, some count any use of a GitOps tool for any workload, others count organizations that have GitOps as their primary deployment method everywhere. Either way, the direction is the same: GitOps has gone from a niche practice to a majority approach among Kubernetes-heavy organizations in a short window.
Why Teams Are Making the Switch
The reasons organizations move to GitOps tend to cluster around a few consistent themes, and they line up closely with what the survey data shows teams experience once they adopt it.
Faster, safer rollbacks. Because every past state of the system is a commit in Git, reverting a bad deployment is as simple as reverting a commit rather than reconstructing a previous manual deployment from memory or documentation.
A real audit trail. Every change to infrastructure or application configuration goes through a pull request, which means every change has an author, a review, and a timestamp. That's a meaningfully different compliance posture than a mix of CI logs, tickets, and manual kubectl sessions.
Reduced blast radius from compromised pipelines. As noted above, the pull-based model keeps cluster credentials inside the cluster, closing off one of the more common attack paths into production infrastructure.
Developer self-service without direct cluster access. Developers can propose infrastructure and deployment changes through familiar Git workflows, pull requests, code review, and merges, without needing direct kubectl access or deep Kubernetes expertise for every change. This is a big part of why GitOps has become a core building block of internal developer platforms and the broader platform engineering movement, where the goal is giving developers self-service paths to production without requiring them to become infrastructure specialists.
Consistency across environments and clusters. For teams running multiple clusters across regions or clouds, GitOps makes it far easier to guarantee that every cluster reflects the same desired state, and to roll a change out (or back) across all of them consistently.
Common Challenges Teams Run Into
GitOps has a real learning curve, and it's worth being upfront about where teams typically struggle.
| Challenge | What It Looks Like in Practice |
|---|---|
| Secrets management | Storing sensitive values directly in Git is not an option. Teams need a dedicated secrets solution such as Sealed Secrets, External Secrets Operator, or Vault integration. |
| Repository structure | Choosing between a single monorepo, per-team repositories, or per-environment repositories involves important tradeoffs related to access control and blast radius. |
| Initial tooling investment | Implementing Argo CD or Flux, along with policy and RBAC controls, requires significant upfront work before deployment benefits become visible. |
| Drift from manual "emergency" changes | Teams working under incident pressure sometimes bypass Git and apply direct fixes, which can then be silently reverted by the GitOps agent unless the process is clearly understood across the organization. |
| Multi-cluster complexity at scale | Managing dozens of clusters with consistent policies requires deliberate planning and structure rather than simply enabling the tool. |
None of these are reasons to avoid GitOps, but they are reasons to treat the rollout as a real engineering project with its own planning, not a weekend tooling swap.
Where GitOps Fits Into a Broader DevOps Strategy
GitOps solves the deployment layer specifically. It doesn't replace the rest of your DevOps or platform strategy, it plugs into it. • Platform engineering. GitOps is frequently the deployment mechanism underneath an internal developer platform's self-service workflows, so it's usually part of the architecture by default for any team building or evaluating an IDP. • Cloud cost visibility. A declarative, versioned record of exactly what infrastructure is deployed at any point makes cloud cost management and cost optimization far more tractable, since a cost spike can be traced back to the exact commit that caused it. • Bringing in outside help. Getting secrets management, multi-cluster policy, and repository structure right the first time is exactly the kind of work DevOps consulting firms and managed DevOps service providers are commonly brought in for, particularly for teams without in-house Argo CD or Flux experience.
Conclusion
GitOps didn't just add a new tool to the Kubernetes toolchain, it changed the underlying model for how changes reach production. Moving from a push-based pipeline to a pull-based, Git-reconciled system closes off a real security gap, gives every change a permanent audit trail, and turns rollbacks into a one-line Git revert instead of a scramble. The adoption data backs up what that shift looks like in practice: CNCF's 2025 survey found 97% of Argo CD users running it in production, and separate industry research puts GitOps adopters at over 80% more likely to report higher infrastructure reliability and faster rollbacks than teams still deploying manually.
None of that means GitOps is free. Secrets management, repository structure, and multi-cluster policy all take real planning, and teams that skip that planning tend to be the ones who run into drift and access-control headaches later. But for any team running Kubernetes at meaningful scale, the direction of the industry is clear, and GitOps has moved from an early-adopter experiment to the default way mature teams manage deployments.
