GitOps

Updated September 30, 20262 min read

In short

GitOps is a way of managing infrastructure and deployments where Git holds the desired state of a system and an automated agent keeps the live system in sync.

What is GitOps?

GitOps is an operations practice that uses a Git repository as the single source of truth for how a system should look. The desired state, such as which application versions run, how many replicas they have, and how they are configured, is written as declarative files, usually in YAML. To change production, you change those files through a commit or pull request instead of running commands against the servers.

An automated agent, often running inside a Kubernetes cluster, continuously compares the live state with what the repository says. When they differ, for example after a new commit or because someone changed the cluster by hand, the agent reconciles them by applying the files from Git. This pull-based model means the CI pipeline does not need direct credentials to production, and the Git history becomes a full audit log of every change.

It is like a thermostat: you set the temperature you want, and the system keeps adjusting the room to match it, rather than you switching the heater on and off yourself. GitOps is widely used for Kubernetes platforms, multi-cluster setups, and teams that want reviewed, repeatable changes to their environments. Rolling back becomes as simple as reverting a commit.

GitOps is often confused with CI/CD and with infrastructure as code. Infrastructure as code describes infrastructure in files, and GitOps adds the rule that those files live in Git and are applied automatically by a reconciling agent. CI still builds and tests the code, while GitOps usually takes over the delivery step by syncing the approved state to the cluster.

Key takeaways

Git is the single source of truth for the desired state of the system.
Changes go through commits and pull requests, not manual commands.
An agent continuously reconciles the live system with the repository.
Drift caused by manual changes is detected and corrected automatically.
A rollback is a git revert, and the Git log doubles as an audit trail.

Example

Deploying a new version the GitOps waybash

# Change the desired state: bump the image version in the manifest
sed -i 's/web-app:1.4.0/web-app:1.5.0/' apps/web-app/deployment.yaml

# Propose the change for review like any other code
git switch -c release-web-app-1.5.0
git commit -am "Deploy web-app 1.5.0"
git push -u origin release-web-app-1.5.0

# After the pull request is merged, the GitOps agent
# notices the new commit and updates the cluster to match.

# Rolling back is just another commit
git revert <commit>

Readers ask

What is the difference between GitOps and DevOps?

DevOps is a broad culture and set of practices for bringing development and operations together. GitOps is one specific way to implement part of DevOps, where deployments and infrastructure changes are driven entirely by commits to Git.

Is GitOps only for Kubernetes?

No, the idea works for any system whose state can be described declaratively and reconciled automatically. In practice, it is most common with Kubernetes because the platform is built around declarative configuration and reconciliation loops.

What is configuration drift?

Configuration drift happens when the live system slowly stops matching its intended configuration, often because of manual fixes. A GitOps agent detects drift by comparing the cluster with Git and can undo those changes automatically.