GitOps is an operating model for managing infrastructure and applications: a versioned, declarative description records the intended state, and software agents repeatedly work to make the running system match it. It is especially common with Kubernetes, but GitOps is a way of working—not a single product. Its defining features are declarative desired state, versioned history, automatic pull, and continuous reconciliation.
What is GitOps?
In GitOps, a repository or another supported source holds the desired configuration for a system. A controller retrieves that configuration and applies it to the live environment, then keeps checking whether the environment still matches. The repository becomes a reviewable record of intended state; the controller performs the ongoing work of aligning the system with that intent.
OpenGitOps, a working group under the CNCF App Delivery SIG, describes the model through four principles. OpenGitOps principles are vendor-neutral, so they apply beyond any one GitOps tool.
- Declarative: Describe the desired result rather than relying only on a sequence of manual commands.
- Versioned and immutable: Store desired state in a way that provides versioning and a complete history, so teams can inspect how intent changed.
- Pulled automatically: Software agents retrieve the desired state from its source.
- Continuously reconciled: Agents observe actual state and attempt to apply the desired state. As OpenGitOps puts it, “Software agents continuously observe actual system state and attempt to apply the desired state.”
Pull requests, reviews, and approvals are useful ways to control changes, but they are workflow choices rather than one of these four principles.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →How does the GitOps reconciliation loop work?
- Record intent. A developer or operator commits a change to the versioned source—for example, a new application configuration or an updated deployment manifest.
- Retrieve and apply. A controller reads the source and applies the declared configuration to the target environment.
- Compare states. The controller observes the live system and compares it with the desired state.
- Reconcile differences. If the two diverge, the controller attempts to bring the live system back into line. This repeated comparison and correction is reconciliation.
The timing and mechanics depend on the tool and its configuration. For example, Flux documentation says its Kustomization reconciliation runs every five minutes by default and can be changed. That interval describes Flux’s documented default, not a universal GitOps schedule. See Flux Kustomization documentation.
Why a direct cluster edit may not stick
If someone changes a live resource with kubectl edit or kubectl patch, or deletes it with kubectl delete, the change may conflict with what the source declares. A later reconciliation can restore the declared version or recreate the deleted resource. To make a lasting change, normally update and commit the desired configuration. For an exceptional intervention, an operator may need to suspend the relevant reconciliation first, then resume it after the source and live state are brought back into agreement. Flux documents this behavior as an example of reconciliation; exact controls vary by tool.
What GitOps helps with—and what it does not guarantee
- Change history: Versioned desired state lets teams review what was intended and inspect the recorded history of changes.
- More consistent configuration: Declarative state gives a controller a target to apply and check, rather than relying solely on people to remember manual steps.
- Visible and correctable drift: Reconciliation can reveal differences between the live system and declared intent, and attempt to correct them.
- Repeatable operations: Applying the same declared configuration through an automated process can make operations more repeatable, provided the configuration and process are sound.
GitOps is not an automatic security, reliability, or error-prevention guarantee. Teams still need appropriate access controls, safe secret handling, monitoring, rollout strategies, and a clear process for emergencies. It also does not eliminate the organizational work of deciding how changes move between environments; promotion from staging to production remains a reported challenge for many Argo CD survey respondents.
Argo CD and Flux: how to choose
Argo CD and Flux are CNCF-graduated GitOps implementations for Kubernetes, but they have different product shapes. CNCF describes Argo CD as a declarative, GitOps-based continuous-delivery tool that runs as a Kubernetes controller, monitors Git repositories, and ensures declared application state is deployed across clusters. Flux is a set of specialized controllers and composable APIs for continuous delivery on Kubernetes.
| Consideration | Argo CD | Flux |
|---|---|---|
| Product shape | Application-oriented continuous-delivery tool and controller, as described by CNCF. | Modular collection of specialized controllers and composable APIs, as described by the Flux project. |
| Sources and integrations | CNCF’s project description says it monitors Git repositories. The linked project description does not enumerate other source types. | Flux documentation lists GitRepository, OCIRepository, HelmRepository, and Bucket sources, including S3-compatible buckets; it also documents Kustomize and Helm support, periodic and event-triggered reconciliation, Kubernetes RBAC integration, notifications, dependency management, and workflow-provider interoperability. |
| Operational question to resolve | Decide whether its application-oriented product shape fits how your team wants to inspect and manage delivery across clusters. | Decide whether your team wants a composable controller toolkit and can operate the components and APIs it requires. |
There is no universally best choice established by these descriptions. Compare the tools against your source formats, integrations, access-scoping needs, cluster and environment organization, promotion path, and the capacity your team has to maintain the system. In the 2025 Argo CD End User Survey announcement, CNCF says environment promotion remains challenging, with many teams relying on manual processes or custom scripts—an important issue to evaluate whichever tool you choose.
What the survey numbers do—and do not—say
Survey figures describe the respondents and questions in a particular survey; they are not universal adoption rates or direct comparisons between tools.
- CNCF’s 2024 Annual Survey reported that 77% of respondents said their deployment practices and tools adhered to GitOps principles to some, much, or nearly all extent. The survey was conducted in November and December 2024; the figure is based on 689 respondents, with “don’t know/not sure” responses excluded.
- In CNCF’s 2025 survey report, 23% of cloud-native adopters said much or all of their deployment practices and tools adhered to GitOps principles. The relevant question was shown only to end-user organizations, and the report identifies a sample of 380. Its maturity-group results were 0% for explorers, 50% for practitioners, and 58% for innovators; those subgroup values should not be treated as general-market rates. See the CNCF Annual Survey 2025.
- The 2025 Argo CD End User Survey reported that 97% of its Argo CD respondents used it in production, compared with 93% in the 2023 survey. In the same survey, 42% managed more than 500 applications per Argo CD instance, compared with 15% in 2023, and 25% connected instances to more than 20 clusters. Its reported Net Promoter Score was 79. These are Argo CD survey results, not measures of GitOps adoption or satisfaction across all tools.
How to get started with GitOps
Start with one application or a limited environment rather than trying to automate every operational process at once. The aim is to make the desired state understandable, decide who can change it, and verify that reconciliation behaves as expected.
- Choose a manageable target. Pick an application or set of resources whose configuration and ownership are clear.
- Describe its desired state declaratively. Put the configuration under version control, and keep sensitive values out of plain-text manifests. Choose a suitable secret-handling approach before expanding the scope.
- Choose a controller and source. Check that the tool supports your source formats, access model, and deployment workflow. Flux’s official getting-started guide walks through its bootstrap path.
- Install and connect the controller. In Flux’s documented bootstrap model, install Flux components, establish source and Kustomization resources, and commit manifests to an existing or new repository. Flux can manage its own configuration through the same model it uses for other resources.
- Test both normal changes and drift. Commit a harmless configuration change and confirm that the controller applies it. Then make a controlled live change and observe whether reconciliation returns the environment to the declared state.
- Define promotion and emergency procedures. Decide how changes progress between environments, how access is scoped, how reconciliation is paused when needed, and how an emergency change is recorded back into the source.
For a vendor-neutral framework, consult OpenGitOps. Flux’s getting-started documentation is a free implementation-specific resource. Readers who want a deeper, practical follow-up can consider GitOps Cookbook by Natale Vinto and Alex Soto Bueno, published by O’Reilly in 2023; the publisher describes it as intermediate to advanced, so it is not a prerequisite for learning the basics.
Free tools Windows power users keep installed
One-click scans. No signup required.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
