GitOps in 2026: Pull Requests Are Becoming the Control Layer for Cloud Operations

GitOps sounds more complicated than it really is. Teams describe in Git how an application or cloud environment should look, review any proposed change through a pull request, then let controllers such as Argo CD or Flux keep the live environment aligned with that approved state. What started around Kubernetes deployment is now spreading into a broader way of controlling infrastructure change.

Among organizations classified as cloud-native “innovators,” 58% now say most or all of their deployment practices follow GitOps principles. Among Argo CD users, 42% manage more than 500 applications from a single instance and a quarter connect more than 20 clusters (CNCF, 2026; CNCF, 2025).

Underneath that workflow is a fairly simple operating model. Git stores the declared state, while software agents continuously compare it with what is actually running and reconcile any differences. OpenGitOps formalizes four principles around that model: declarative configuration, versioned state, automatic pull, and continuous reconciliation (OpenGitOps, 2026).

Much of its appeal comes from the way cloud environments behave under pressure. An engineer may increase capacity during a product launch, change a network rule during an outage or adjust permissions to get a workload moving. Those decisions can be perfectly sensible in the moment, yet enough of them eventually leave production describing a different system from the one sitting in the repository. Continuous reconciliation keeps that divergence visible. An emergency change can be committed back into Git and become part of the approved configuration, or the controller can restore the previous state. Either route leaves an auditable trail rather than letting yesterday’s workaround become tomorrow’s unexplained infrastructure.

CNCF’s Argo CD survey suggests platform teams are already using GitOps this way. Platform engineers accounted for 37% of respondents, and 97% of surveyed Argo CD users ran it in production. Yet one problem stood out: moving applications between environments still depends heavily on manual processes and custom scripts (CNCF, 2025). So, GitOps has become very good at keeping an environment aligned with declared state; deciding how state should progress from development to production remains messier.

Platform engineering pushes the model a bit further. Developers can request environments through an internal platform while Git records the resulting configuration underneath. GitOps controllers then apply and reconcile it. The developer gets a simpler interface, while infrastructure teams retain a reviewable record of what the platform asked production to become. But AI adds another reason to keep that record: an agent can draft Terraform, explain a failed policy check, or suggest a Kubernetes change inside a pull request. Existing tests, policies, and approvals then evaluate the proposal before deployment. For infrastructure teams experimenting with agentic operations, that gives machine-generated changes somewhere visible to land before they acquire production permissions.

Once Git repositories and reconciliation controllers become part of the path into production, their permissions deserve production-level scrutiny. OpenGitOps explicitly treats access control around the state store, deployments, and runtime as part of the managed system itself (OpenGitOps, 2026).

Essentially GitOps buys teams a cleaner line between decision and execution. The change is proposed, checked and recorded before production absorbs it, which makes cloud operations far easier to interrogate later.