GitOps is a way of operating systems where the desired state of your infrastructure and applications lives in a Git repository, and an automated process continuously makes the running system match what the repository says it should be. Instead of someone running commands to change production, you change a file in Git, and the system converges to the new declared state on its own. Git becomes the single source of truth for what should be running, and the act of deploying or changing infrastructure becomes the act of merging a change to a repository, with all the review, history, and auditability that comes with it.
The reason GitOps exists is that operating systems through manual commands and ad hoc changes is error-prone, hard to audit, and impossible to reproduce reliably. When the running state of production is the result of a long series of manual actions that no one fully recorded, you cannot easily say what is running, why, or how to recreate it, and recovering from a disaster means reconstructing state from memory and scattered scripts. GitOps fixes this by making the declared state in Git the authority and the running system a reflection of it, so the answer to what should be running is always in the repository, and the running system is continuously reconciled to match.
The mechanism that makes GitOps work is reconciliation: an automated agent that constantly compares the actual state of the running system to the desired state in Git and corrects any difference. If someone changes production directly, the reconciler notices the drift from the declared state and either corrects it or flags it, so the system resists the unrecorded manual changes that cause configuration drift over time. This continuous reconciliation is what distinguishes GitOps from simply storing configuration in Git, because it is not just that the desired state is version-controlled, it is that the running system is actively and continuously kept in agreement with it.
By 2026 GitOps has become a mainstream approach to deployment and infrastructure management, especially in environments built on Kubernetes, where the declarative model maps cleanly onto how GitOps works. The Kubernetes ecosystem, with its declarative resource definitions and its reconciliation-based design, fits GitOps naturally, and tools that implement the GitOps pattern have matured into widely adopted parts of the cloud-native stack. The appeal is concrete: deployments that are auditable because they are Git history, reproducible because the state is declared, and resistant to drift because reconciliation enforces the declared state, which together make operations more reliable and more understandable.
This page covers what GitOps is, how it uses version control as the source of truth, the patterns that work in production, and where GitOps fits and where it does not. The specific tools will keep evolving. The underlying idea, that the desired state of your systems should live in version control and the running system should be continuously reconciled to match it, is durable, and understanding it is what lets a team decide whether and how to adopt GitOps to make their operations more reliable, auditable, and reproducible.
The foundational move is declaring the desired state, rather than scripting the steps to achieve it, and storing that declaration in Git. Instead of writing commands that change the system, you describe what the system should look like, the applications, their configuration, the infrastructure, and you commit that description to a repository. This declarative approach is what makes Git a meaningful source of truth, because the repository contains a complete statement of what should be running, not a history of commands whose cumulative effect you would have to reconstruct, and the system's job is to make reality match that statement.
Because the desired state lives in Git, every change to the system goes through the normal Git workflow, which brings operational changes under the same discipline as code changes. A change to production is a commit, reviewed through a pull request, recorded in the history, and attributable to a person and a reason, so operations gain the review, audit trail, and collaboration practices that software development already has. This is a large part of GitOps's value: the practices that make code changes safe and traceable, peer review, version history, the ability to see who changed what and why, now apply to infrastructure and deployment, which were previously the domain of unreviewed manual actions.
Git as the source of truth also makes the system's state reproducible and recoverable, because the complete desired state is captured and versioned. If you need to recreate an environment, you apply the declared state from the repository; if a change causes problems, you revert the commit and the system reconciles back to the previous state; if you lose infrastructure, you rebuild it from the declaration. The running system becomes a reproducible function of the repository rather than a fragile accumulation of manual changes, which transforms disaster recovery and environment creation from anxious reconstruction into a repeatable application of declared state.
The single source of truth also resolves the ambiguity about what is actually supposed to be running, which is a chronic problem in systems operated by manual change. When production is the result of many undocumented manual actions, no one can authoritatively say what should be running or why, but when the desired state lives in Git, that question always has a clear answer: whatever the repository declares. Any difference between the repository and reality is drift to be reconciled, not a legitimate state, which gives the whole operation a clarity it otherwise lacks and makes the running system something you can reason about rather than something you have to investigate.
Reconciliation is the engine of GitOps, the continuous process that compares what is running to what Git declares and works to eliminate the difference. A reconciliation agent watches both the repository and the running system, and whenever they diverge, because someone merged a change to Git or because the running system drifted, it acts to bring the running system back into agreement with the declared state. This is an ongoing loop, not a one-time deployment, which means the system is continuously held in the desired state rather than merely set to it once and left to drift, and that continuous enforcement is the heart of what GitOps provides.
The reconciliation loop is what makes GitOps resistant to configuration drift, which is one of its most valuable properties. In systems operated manually, the running state slowly diverges from any documented intent as people make undocumented changes, until production is a mystery no one fully understands. Under GitOps, when someone changes the running system directly, the reconciler detects the divergence from Git and corrects it or surfaces it, so unrecorded manual changes do not silently accumulate. This active resistance to drift keeps the running system honest to its declared state over time, which is a guarantee that manual operations simply cannot provide.
Reconciliation also changes how deployment works, making it a pull rather than a push in the common GitOps pattern. Instead of a pipeline pushing changes into production from outside, an agent running inside the environment pulls the desired state from Git and applies it, which has security and reliability advantages because the environment is not exposing access to an external deployment system and the agent is continuously ensuring convergence rather than acting only when a pipeline fires. This pull-based reconciliation is a defining characteristic of how many GitOps tools work, and it is part of why the pattern fits environments like Kubernetes where an in-cluster agent can continuously reconcile the cluster's state.
Because reconciliation is continuous and automatic, it shapes how you make and reverse changes, which is mostly to the good but requires understanding. A change deploys when it merges to Git and the reconciler picks it up, and a rollback is a revert in Git that the reconciler then applies, so the deployment and rollback story flows through version control naturally. But it also means that direct manual changes to production are transient, since the reconciler will undo them, which is the intended behavior but can surprise people used to operating by hand. Working with GitOps means working through the repository rather than around it, because the reconciler enforces the repository's authority continuously, and fighting that by making manual changes just produces a tug of war the reconciler is designed to win.
The pattern that works most cleanly is GitOps on Kubernetes with a dedicated reconciliation tool, because the declarative, reconciliation-based nature of Kubernetes matches GitOps almost exactly. Kubernetes already works by reconciling its actual state to declared resource definitions, so adding a GitOps agent that keeps those definitions in agreement with Git extends Kubernetes's own model outward to the repository, producing a coherent system where the cluster continuously reflects what Git declares. This natural fit is why GitOps adoption has been strongest in the Kubernetes ecosystem and why the mature GitOps tools center on it, and for teams already running Kubernetes, GitOps is often the obvious way to manage deployments.
Separating the application code repository from the deployment configuration repository is a pattern that works well in practice, keeping concerns clear. The application code lives in its own repository with its own pipeline that builds and tests it, while the declared desired state of what runs in each environment lives in a separate configuration repository that the reconciler watches. This separation means the deployment state has its own clear history and review process distinct from code changes, and it lets the same application be deployed to different environments through different declared configurations, which keeps the deployment story clean as the number of applications and environments grows.
Using GitOps to manage configuration and infrastructure, not just application deployment, is a pattern that extends its benefits across operations. The same approach that declares which applications run can declare the cluster's configuration, its policies, its networking, and increasingly its underlying infrastructure, so that the whole operational state is version-controlled and reconciled rather than just the application layer. This broader application of GitOps brings the auditability, reproducibility, and drift resistance to more of the operation, and it is a common direction for teams that have adopted GitOps for application deployment and want the same properties for the configuration and infrastructure underneath.
Combining GitOps with progressive delivery is a pattern that addresses GitOps's main gap around release safety, and the mature tooling increasingly supports it. Because GitOps reconciles to the declared state, a naive setup would roll out a change to everything at once when it merges, so pairing GitOps with progressive delivery, releasing the change gradually to a subset first and expanding if it is healthy, keeps the safety of canary and blue-green deployments within the GitOps model. This combination lets a team keep the auditability and reproducibility of GitOps while not giving up the gradual, reversible releases that make frequent deployment safe, and it is part of how GitOps works for serious production use rather than just simple deployments.
GitOps fits best where the system can be meaningfully described as declarative state, which is why it suits Kubernetes and cloud-native infrastructure so well and is more awkward elsewhere. When what should be running can be expressed as a declaration that a reconciler can compare against reality and converge toward, GitOps works cleanly, but when the system is inherently imperative or stateful in ways that resist declarative description, forcing it into GitOps is harder and less rewarding. Assessing whether your system fits the declarative model is the first question in deciding whether GitOps is the right approach, because GitOps's benefits flow from that declarative foundation.
GitOps fits organizations that want the auditability and discipline of version-controlled operations and are willing to work through the repository rather than around it. The benefits, the audit trail, the review, the reproducibility, the drift resistance, come from making Git the authority and respecting that authority, which requires a cultural commitment to operating through the repository rather than by hand. Teams that embrace this gain real reliability and clarity, while teams that adopt the tooling but keep making manual changes get the tug of war between their hands and the reconciler without the benefits, so the cultural fit matters as much as the technical fit.
Where GitOps fits less well is in handling secrets and certain kinds of sensitive or rapidly changing state, which need careful design because putting them plainly in Git is unacceptable. Secrets cannot live in a repository in the clear, so GitOps setups need a deliberate approach to secret management, encrypting secrets or referencing them from a separate secure store, and state that changes faster than a commit-and-reconcile cycle can comfortably handle may not fit the model well. These are not reasons to avoid GitOps, but they are real considerations that a serious adoption has to address rather than assume away, because the naive approach of just putting everything in Git breaks down at exactly these points.
GitOps is also not a complete operations strategy by itself, and treating it as one is a mistake, because it is a pattern for managing desired state and reconciliation, not for everything operations involves. It does not replace monitoring, incident response, capacity planning, or the broader practice of running reliable systems; it is one valuable piece that makes deployment and configuration management more reliable and auditable. Understanding GitOps as a strong approach to a specific part of operations, rather than as a philosophy that handles all of operations, is what lets a team adopt it where it helps and not stretch it into places it does not fit, which is the realistic way to get value from it.
The most reliable way to adopt GitOps is incrementally, starting with one application or environment rather than converting the whole operation at once. Beginning with a single, non-critical workload lets the team learn how reconciliation behaves, how the repository structure should be organized, and how to work through Git rather than around it, before the stakes are high. A big-bang adoption that puts the entire operation under GitOps before anyone understands it tends to produce confusion and resistance, while a gradual rollout builds the competence and the cultural habits that GitOps depends on, so the pattern proves itself on small workloads before carrying critical ones.
Designing the repository structure deliberately is worth doing early, because a structure that grows organically tends to become a tangle that is hard to reason about. Decisions about how to organize the declared state, whether to separate environments into different repositories or directories, how to handle shared configuration, and how to keep the deployment configuration distinct from application code, all shape how manageable the system is as it grows. Getting this structure thought through before there are dozens of applications under GitOps avoids a painful reorganization later, and it makes the repository the clear, navigable source of truth that GitOps is supposed to provide rather than a confusing sprawl.
The cultural shift is the part most likely to undermine adoption, because GitOps only delivers its benefits if people actually operate through the repository, and old habits of manual change die hard. Engineers used to fixing production by hand will be tempted to keep doing so, especially under pressure during an incident, and every such manual change either gets undone by the reconciler or, if reconciliation is disabled to allow it, breaks the discipline that makes GitOps valuable. Investing in helping the team adopt the new way of working, and making the GitOps path fast and convenient enough that operating through Git is genuinely easier than working around it, is what makes the cultural shift stick rather than producing quiet circumvention.
Planning for incidents within the GitOps model, rather than treating GitOps and incident response as at odds, is what keeps the discipline intact when it is most tested. During an incident the instinct is to bypass the repository and fix production directly, so the adoption has to provide a fast path to make emergency changes through Git, or a clear, controlled way to make a temporary manual change that is then reconciled back into the repository afterward. Teams that work out their incident response within the GitOps model in advance keep the audit trail and the single source of truth intact even under pressure, while teams that have no plan for incidents end up abandoning GitOps exactly when its drift resistance and traceability would have been most useful, which defeats much of the reason they adopted it.
It is a way of operating systems where the desired state of your infrastructure and applications lives in a Git repository, and an automated process continuously makes the running system match what the repository declares. Instead of running commands to change production, you change a file in Git and the system converges to the new declared state on its own. Git becomes the single source of truth for what should be running, and deploying or changing infrastructure becomes merging a change to a repository, with all the review, history, and auditability that comes with version control.
The difference is reconciliation. Storing configuration in Git gives you version history, but GitOps adds an automated agent that continuously compares the actual running state to the declared state in Git and corrects any difference. It is not just that the desired state is version-controlled; it is that the running system is actively and continuously kept in agreement with it. If someone changes production directly, the reconciler detects the drift and corrects it or flags it. That continuous convergence is what makes GitOps an operating model rather than just a place to keep configuration files.
Reconciliation is the continuous process that compares what is actually running to what Git declares and works to eliminate the difference. A reconciliation agent watches both the repository and the running system, and whenever they diverge, because a change merged to Git or the running system drifted, it acts to bring reality back into agreement with the declared state. It is an ongoing loop rather than a one-time deployment, so the system is continuously held in the desired state instead of merely set to it once. This is the engine of GitOps and the source of its resistance to configuration drift.
Because Kubernetes already works by reconciling its actual state to declared resource definitions, so it matches the GitOps model almost exactly. Adding a GitOps agent that keeps those definitions in agreement with Git simply extends Kubernetes's own reconciliation outward to the repository, producing a coherent system where the cluster continuously reflects what Git declares. This natural fit is why GitOps adoption has been strongest in the Kubernetes ecosystem and why the mature GitOps tools center on it. For teams already running Kubernetes, GitOps is often the obvious way to manage deployments and configuration.
Auditability, because every change is a reviewed, attributable commit in Git history, so you can always see who changed what and why. Reproducibility, because the complete desired state is declared and versioned, so you can recreate environments and recover from disasters by reapplying it. Drift resistance, because reconciliation continuously enforces the declared state and undoes unrecorded manual changes. And clarity, because the question of what should be running always has a clear answer in the repository. Together these make operations more reliable and more understandable than operating through ad hoc manual commands.
A deployment happens when you merge a change to the desired state in Git and the reconciler picks it up and converges the running system to match. A rollback is a revert in Git, which the reconciler then applies to bring the system back to the previous state. So both flow through version control naturally, with the same review and history as any code change. One consequence is that direct manual changes to production are transient, since the reconciler will undo them, which is the intended behavior but can surprise people used to operating by hand. You work through the repository, not around it.
Handling secrets, which cannot live plainly in Git and need encryption or a separate secure store. State that changes faster than a commit-and-reconcile cycle can comfortably handle, which may not fit the model well. The cultural shift to operating through the repository rather than by hand, since teams that keep making manual changes get a tug of war with the reconciler instead of the benefits. And recognizing that GitOps fits declarative systems cleanly but is more awkward for systems that resist declarative description. These are addressable but have to be designed for rather than assumed away.
Not entirely; it changes the deployment part. A common setup keeps the CI pipeline that builds and tests the application code, but instead of that pipeline pushing changes directly to production, it updates the declared state in a configuration repository, and a GitOps reconciler converges the running system to match. So continuous integration still verifies changes, while GitOps handles the delivery to production through reconciliation. This pull-based approach has security and reliability advantages, since the environment is not exposing access to an external deployment system and the reconciler continuously ensures convergence rather than acting only when a pipeline fires.
No, and treating it as one is a mistake. GitOps is a strong approach to managing desired state and keeping the running system reconciled to it, which makes deployment and configuration management more reliable, auditable, and reproducible. But it does not replace monitoring, incident response, capacity planning, or the broader practice of running reliable systems. It is one valuable piece of operations, not the whole of it. Understanding GitOps as a powerful pattern for a specific part of operations lets a team adopt it where it helps without stretching it into places it does not fit.
