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.

Pipeline diagram of a GitOps delivery flow: source, build and automated test feeding a Git repository that an in-cluster agent continuously reconciles against the live Kubernetes state

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, formalised 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 is 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 is the automation that turns commits into artifacts and pushes them somewhere. GitOps is 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).

Put concretely: you can write beautiful Terraform and still not be doing GitOps, if a human runs terraform apply from their machine and nothing watches for drift afterwards. 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:

Argo CD ships as an opinionated application-delivery platform with a strong built-in web UI. The dashboard, the visual diff between desired and live state, and the application-centric model make it the easier sell to teams that want reliability engineers and developers looking at the same screen. That visibility is a large part of why it dominates the survey numbers.
Flux ships as a modular toolkit of Kubernetes controllers you compose yourself. There is no bundled UI by design. If you are building a platform and want GitOps embedded as a set of primitives you assemble and automate against, Flux's Lego-brick model tends to fit better, and several managed cloud platforms embed it under the hood.

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. Do not let the tool debate consume the energy that belongs on repository structure and access control, which is where GitOps implementations actually succeed or fail.

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 - 69% cited replacing manual processes with automation as the biggest security gain, 62% valued shielding live production from direct human access, and 60% pointed to fast repair and rollback (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. First, 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. Second, 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.