GitOps in 2026: Reconciliation, Drift, and the Argo CD vs Flux Decision

GitOps stopped being a debate somewhere around 2023. In the CNCF's GitOps microsurvey, 60% of respondents had already been running it for more than a year and another 31% had started within the previous twelve months, which puts adoption north of 90% among cloud-native practitioners (CNCF, 2023). Both of the reference implementations, Argo CD and Flux, reached CNCF "graduated" status in late 2022, the highest maturity tier the foundation awards (CNCF, 2025). So the interesting question for a senior engineer in 2026 is no longer "should we do GitOps" but "what exactly are we committing to, and which engine do we run it on." This piece answers both, with the audit and drift angles that matter to regulated Benelux teams.

What is GitOps, precisely?

GitOps is not "using Git for infrastructure," which most teams already do. It is a specific operating model with four principles, formalized by the CNCF-governed OpenGitOps working group (OpenGitOps, v1.0.0). A system is doing GitOps only if all four hold:

• Declarative. The desired state of the whole system is expressed as data, not as scripts. You describe what should exist, not the steps to create it.
• Versioned and immutable. That desired state is stored so it is immutable, fully versioned, and keeps a complete history. In practice this is a Git repository, which is where the name comes from, but the principle is the version store, not the tool.
• Pulled automatically. Software agents pull the desired state from the source themselves. Nobody runs kubectl apply from a laptop, and the CI system does not push into production.
• Continuously reconciled. Agents continuously observe the actual running state and work to make it match the declared state.

The last two are what separate GitOps from a well-run CI/CD pipeline. In a classic push pipeline, a job authenticates into the cluster and applies a change once; after that, the pipeline has no opinion about what happens to the cluster. In GitOps, an agent living inside the cluster pulls the repository and keeps enforcing it. That inversion, from push to pull and from one-shot to continuous, is the entire point.

Drift, reconciliation, and self-healing

The problem GitOps is built to kill is configuration drift: the slow divergence between what you think is running and what is actually running, caused by a hotfix applied by hand during an incident, a failed partial deploy, an autoscaler mutation, or a well-meaning engineer with cluster access and a deadline. Drift is corrosive precisely because it is invisible until the next deploy fails for reasons nobody can explain, or an audit asks you to prove the running configuration and you cannot.

Continuous reconciliation is the countermeasure. The in-cluster agent compares live state against the declared state on a loop and, on divergence, either corrects it automatically or flags it as out of sync. Manually delete a resource that Git says should exist and the agent recreates it. Hand-edit a running config and the agent reverts it to what the repository declares. That closed loop is what gives GitOps its self-healing reputation, and it is why the reconciliation engine, not the Git repository, is the part that actually earns its keep. Git is just the source of truth; the controller is the enforcement.

GitOps vs Infrastructure as Code and CI/CD

These three overlap enough to cause real confusion, so it is worth drawing the lines.

Infrastructure as Code

The practice of declaring resources in files; a Terraform or OpenTofu plan describes what should exist. IaC tells you nothing about who applies it or how often.

CI/CD

The automation that turns commits into artifacts and pushes them somewhere.

GitOps

An opinionated way of wiring the two together for the runtime: declarative definitions (the IaC part), stored in version control, pulled and continuously reconciled by an agent (the operating-model part).

GitOps is less a new technology than a discipline layered on top of IaC and CI, moving the act of applying changes out of imperative pipelines and into a pull-based control loop. For the reasoning around declarative infrastructure and drift more broadly, our piece on Infrastructure as Code in 2026 covers the policy and Terraform-vs-OpenTofu side.

Argo CD vs Flux: which GitOps engine?

Both are CNCF graduated, both are production-proven, and choosing between them is mostly a question of team shape rather than capability. The market has a clear leader: the 2025 CNCF end-user survey found that nearly 60% of Kubernetes clusters managed by respondents rely on Argo CD, with 97% of its users running it in production (up from 93% in 2023) and a Net Promoter Score of 79 (CNCF, 2025).

The practical distinction:

A useful heuristic: choose Argo CD when the audience for GitOps includes humans who need to see state, and Flux when the audience is mostly other automation. Neither choice is a mistake, and both are boring in the good sense.

Why regulated teams should care: audit and access

For teams under DORA, financial-sector supervision, or any regime that asks "who changed what, when, and who approved it," GitOps is less a productivity play than a compliance one. Because every change to production is a version-controlled commit, you inherit an audit trail for free: author, timestamp, reviewer, and diff, for every mutation, without bolting on a separate change-management system. The same practitioners in the CNCF survey ranked the security benefits accordingly (CNCF, 2023):

That "no direct access" property is the underrated one. When the only sanctioned path to production is a merged pull request that an agent then applies, you can remove standing human write access to the cluster entirely. Break-glass access becomes an exception you log and review, not the daily norm. For an auditor, "production can only be changed through reviewed Git commits, enforced by a controller with no interactive human credentials" is a far stronger control statement than "we have a change-approval process people are supposed to follow."

Where GitOps gets hard

Two failure modes are worth naming up front.

• Secrets. You cannot commit plaintext credentials to the repository that is now your source of truth, so GitOps forces a real secrets strategy (sealed secrets, an external secrets operator, or a vault integration) rather than letting you defer it.

• Skills. The same CNCF survey found nearly 70% of respondents had done no GitOps training and had no plans to, which shows up later as reconciliation loops nobody fully understands and drift alerts nobody triages. GitOps moves the operating model, and a team that adopts the tool without adopting the discipline gets a controller quietly reverting their manual fixes and no shared mental model of why.

None of this argues against GitOps; it argues for treating it as an operating-model change with a real rollout, not a weekend tool install. Done properly, the payoff for a regulated, high-scale team is exactly the combination they struggle to buy elsewhere: a system that self-heals toward a known-good state, an audit trail that comes for free, and a production environment no human can quietly touch.

Sources

1. CNCF End User Survey Finds Argo CD as Majority Adopted GitOps Solution for Kubernetes - Cloud Native Computing Foundation, July 24, 2025
2. CNCF GitOps Microsurvey: Learning on the Job as GitOps Goes Mainstream - Cloud Native Computing Foundation, November 7, 2023
3. OpenGitOps Principles (v1.0.0) - OpenGitOps / CNCF GitOps Working Group
4. GitOps in 2025: From Old-School Updates to the Modern Way - Cloud Native Computing Foundation, June 9, 2025