GitOps is an operating model in which the desired state of managed resources is versioned, often in a Git repository. Agents observe these resources, compare desired and actual state, and attempt to apply the described state [1].

The comparison that holds up is the stock list in a warehouse. The list says what should be on the shelves. The warehouse keeper does not walk the aisles on shouted instructions, but reconciles the shelves against the list. Whoever wants to change something changes the list, not the shelf.

This article explains the model, its four principles and the limits it runs into in practice. Product names appear only in the second-to-last section.

The four principles

The OpenGitOps working group of the CNCF has pinned the model down to four principles [1]:

  • Declarative. The desired state is expressed as a description, not as a command sequence.
  • Versioned and immutable. Desired states are versioned immutably and their history is retained. Storage and access rules must be configured accordingly.
  • Pulled automatically. The environment fetches changes itself instead of someone pushing them in.
  • Continuously reconciled. Agents continuously observe actual state and attempt to apply the desired state.

How this relates to infrastructure as code

GitOps builds on infrastructure as code and declarative configuration. It adds agents that automatically fetch the versioned desired state and continuously reconcile it with managed resources.

The difference shows in everyday work. With IaC alone, a person or pipeline often triggers a run. In the GitOps model, agents handle continuous reconciliation. Direct changes remain technically possible; their detection and correction depend on the managed scope and the tool settings.

Push and pull: who triggers the change

In the push model, the pipeline applies changes directly to the target environment. In the pull model, an agent fetches the versioned desired state and applies it there [2].

The CI pipeline therefore does not need direct production access for deployment [2]. Repository write permissions and agent permissions become particularly important. Continuous reconciliation can also detect changes made outside the pipeline.

What GitOps pays for immediately

The first gain is traceability. Changes to the desired state are versioned and can be linked to explanations and reviews. Required reviews must be configured as approval rules [5]. Direct interventions in the environment also need operational audit logging.

A revert can make an earlier declarative configuration the desired state again. Data already changed or external side effects are not automatically reversed; they need separate recovery procedures.

Where the model reaches its limits

Secrets. Passwords and keys do not belong in a repository in plain text. In practice they live encrypted in the repository or in an external vault the description only points to. Both paths work, neither is free.

Database migrations. A schema change is not a state that can be continuously reconciled, but a transition with an order to it. GitOps provides the frame, the migration itself still needs a procedure of its own.

The emergency intervention. Continuous reconciliation can overwrite a direct intervention. Teams therefore need an agreed procedure to pause reconciliation when necessary, log the intervention and then update the desired state.

Example: Argo CD and Flux

Argo CD and Flux are two widely used GitOps projects for Kubernetes within the CNCF [3][4]. Both reconcile managed resources with the desired state. In Argo CD, automatic correction of existing resources (self-healing) and removal of resources no longer declared (pruning) are configured separately [2].

As with IaC tools, the benefit depends on the process configured: managed scope, synchronisation, access rights, approvals and recovery need to fit the environment.

Key takeaway

GitOps combines versioned desired states with continuous reconciliation. Required reviews, protected repository access and limited agent permissions must be configured [5][6]. Data and other system state still require their own recovery procedures.

What you can decide afterwards

  • Whether your delivery should switch to a pull model and which direct access the pipeline no longer needs.
  • How your team handles the emergency intervention, before it happens for the first time.
  • Where your secrets should live: encrypted in the repository or in an external vault.

Frequently asked questions

Does GitOps strictly require Kubernetes?

No, the model is independent of it. The mature agents, however, come from the Kubernetes world, where continuous reconciliation is easiest to get.

Does GitOps replace the CI pipeline?

No. The pipeline still builds and tests. GitOps takes over the last step: rolling out and holding the state. Together they form the path from the change into operation.

What happens to changes someone makes directly in the environment?

For managed resources, the agent detects the deviation. Whether it corrects it automatically depends on the configuration. In Argo CD, self-healing controls automatic correction of existing resources; pruning controls removal of resources no longer declared [2].

Sources

Read on

Fundamentals What is Infrastructure as Code? Fundamentals What is Platform Engineering? Engineering practice Terraform for teams: state, modules, review Service Platform Engineering at Hueskotech