GitOps
Using Git as the single source of truth for infrastructure and application configuration. Changes are made via pull requests and automatically reconciled by tools like ArgoCD or Flux.
What is GitOps?
In short
GitOps is a way of operating infrastructure and applications where a Git repository holds the desired state of your whole system, and an automated agent continuously compares that repository against what is actually running and corrects any drift. You change the system by merging a pull request, never by running commands against the cluster by hand.
What GitOps actually is
GitOps takes the idea that your infrastructure should be described as code and adds one strict rule: the Git repository is the only place the desired state lives. If a Kubernetes Deployment should run 5 replicas of version 2.3.1, that fact is written in a YAML file in Git. Nothing else is allowed to be the authority. Not a console, not a kubectl command someone typed at 3 AM, not a manual edit in the cloud dashboard.
Because Git is the source of truth, every change has a commit author, a timestamp, a diff, and usually a pull request with a review. You get a full audit trail for free, and rolling back a bad change is a git revert instead of a frantic attempt to remember what the cluster used to look like.
The term was coined by Weaveworks in 2017, and the practice is now formalized by the OpenGITOps working group under the CNCF, which defines four principles: the desired state is declarative, versioned and immutable, pulled automatically, and continuously reconciled.
How it works under the hood
A GitOps agent runs inside the target environment, most often a Kubernetes cluster. The two dominant agents are Argo CD and Flux. The agent is given a Git repository and a path, and it watches for commits.
On a loop, usually every few minutes, the agent does three things. It reads the desired state from Git. It reads the actual state from the cluster API. It computes the difference. If the two match, it does nothing. If they differ, either because someone pushed a new commit or because something drifted in the cluster, it applies the changes to bring the cluster back in line with Git. This is the reconciliation loop, and it is the same control-loop pattern Kubernetes itself uses internally.
A key detail is pull versus push. In a traditional CI pipeline, the pipeline reaches into the cluster and pushes changes, which means the pipeline needs cluster credentials. In GitOps, the agent lives inside the cluster and pulls from Git, so the cluster credentials never leave the cluster and your CI system only needs write access to a Git repo. That separation is a big part of why GitOps is considered more secure.
Image updates are handled the same way. When CI builds a new container image and pushes it to a registry, a small automation commits the new image tag back into the Git repository. The agent then sees the commit and rolls it out. The deploy is just another reconciliation.
When to use it and the trade-offs
GitOps shines when you run many environments or many clusters and need them to stay consistent and auditable. A bank or a regulated company loves it because every production change is a reviewed, signed commit. Teams managing dozens of clusters love it because they can declare fleet-wide config once and let the agents converge every cluster to it.
The trade-offs are real. GitOps assumes a declarative target, which Kubernetes provides cleanly but classic VMs and one-off scripts do not. Reconciliation is eventually consistent, so a deploy is not instant, and debugging means understanding the agent's loop instead of reading a linear pipeline log. Secrets are awkward because you cannot put plaintext passwords in Git, so teams add tools like Sealed Secrets, SOPS, or an external secrets operator. There is also a learning curve and another moving part to operate.
A good rule of thumb: if your platform is Kubernetes and you have more than a couple of environments, GitOps usually pays for itself. For a single small app on a single server, a plain CI deploy script is simpler and fine.
A concrete example
Imagine a payments team running on Kubernetes with Argo CD installed. A developer wants to raise the API memory limit and bump the image to v4.2.0. They open a pull request that edits two lines of YAML in the platform repo. A teammate reviews the diff, approves, and merges to main.
Within about three minutes, Argo CD notices the new commit, sees that the live cluster no longer matches Git, and shows the application as OutOfSync in its dashboard. It then applies the change, the new pods roll out, and the status flips back to Synced and Healthy.
An hour later someone runs a manual kubectl edit to scale replicas down during an incident. Argo CD detects the drift on its next loop and scales it right back up to what Git says, because Git is the source of truth. If the operators actually wanted that change to stick, they would commit it. To undo the entire memory and image change, they revert the commit and the cluster follows.
Where it is used in production
Argo CD
The most widely used GitOps agent, a CNCF graduated project that runs in-cluster, shows sync status in a UI, and reconciles Kubernetes manifests against Git.
Flux
A CNCF graduated GitOps toolkit from Weaveworks that pulls from Git and includes image automation to commit new tags back to the repo.
Intuit
Created Argo CD internally to manage thousands of applications across many Kubernetes clusters, then open-sourced it.
Kubernetes
GitOps reuses the same continuous reconciliation control-loop pattern that Kubernetes controllers use, which is why it fits so naturally on top of it.
Frequently asked questions
- Is GitOps the same as Infrastructure as Code?
- No. Infrastructure as Code means you describe your system in files. GitOps adds the rules that Git is the single source of truth and that an automated agent continuously pulls and reconciles that state. All GitOps is IaC, but not all IaC is GitOps. Running terraform apply by hand is IaC without GitOps.
- How is GitOps different from a normal CI/CD pipeline?
- A normal pipeline pushes changes into your cluster and needs cluster credentials to do it. GitOps flips this: an agent inside the cluster pulls the desired state from Git, so credentials never leave the cluster. GitOps also continuously corrects drift, while a pipeline only acts when it runs.
- Do I need Kubernetes to do GitOps?
- Not strictly, but it is by far the best fit. GitOps needs a declarative system with an API the agent can read and write, which Kubernetes provides natively. There are tools applying GitOps ideas to Terraform and other targets, but the mature ecosystem, Argo CD and Flux, is Kubernetes-first.
- How do you handle secrets if everything is in Git?
- You never commit plaintext secrets. You commit encrypted secrets using tools like Sealed Secrets or SOPS, where only the cluster can decrypt them, or you store a reference in Git and let an external secrets operator fetch the real value from a vault like AWS Secrets Manager or HashiCorp Vault at runtime.
- What happens if someone changes the cluster manually?
- The GitOps agent detects the drift on its next reconciliation loop and reverts the cluster back to match Git, because Git is the source of truth. If you want a change to persist, you have to commit it. Some setups can also alert you instead of auto-reverting, depending on the sync policy.
Learn GitOps hands-on
This page explains the idea. The full lesson lets you step through the ring as servers join and leave, read the implementation, and check yourself with a quiz. It is one of 760+ lessons in the System Design Masterclass, from your first API call to distributed consensus. Eleven Foundation lessons are free, no signup. Lifetime access is ₹499 in India or $7.99 worldwide, one payment, no subscription.
Related lessons
Lessons that touch on GitOps as part of a larger topic.
Configuration as Code
Managing application and infrastructure configuration in version-controlled files instead of manual settings
intermediate · devops cicd
Config Drift Prevention
Detecting and preventing configuration drift, when reality slowly diverges from your declared infrastructure
intermediate · kubernetes containers
Desired State Configuration
Defining what your infrastructure should look like and letting systems converge toward it automatically
intermediate · kubernetes containers
See also
Related glossary terms you might want to look up next.
CI/CD
Continuous Integration and Continuous Deployment: automating the process of testing and deploying code. Push code, tests run, and it ships to production automatically.
Infrastructure as Code
Managing servers, networks, and cloud resources through declarative configuration files instead of manual setup. Terraform, Pulumi, and CloudFormation are IaC tools.
Kubernetes
An orchestration platform that automates deploying, scaling, and managing containerized applications. K8s is the operating system for your cloud.
Blue-Green Deployment
A deployment strategy using two identical environments. Traffic switches from blue (current) to green (new) instantly, with easy rollback.
Canary Deployment
Rolling out a new version to a small percentage of users first, then gradually increasing. Like sending a canary into a coal mine to test for danger.
Rolling Deployment
Gradually replacing old instances with new ones, a few at a time. No downtime, but both versions run simultaneously during the rollout.