We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningIntermediate · DevOps & CI/CD
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.
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.
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.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers GitOps across a run of lessons, not one page. These 4 alone are about 62 minutes of step-by-step reading, every one with a quiz.
Using Git as the single source of truth for infrastructure and application deployment, pull-based, declarative, and auditable.
Managing application and infrastructure configuration in version-controlled files instead of manual settings.
Detecting and preventing configuration drift, when reality slowly diverges from your declared infrastructure.
Defining what your infrastructure should look like and letting systems converge toward it automatically.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with GitOpspay once,
yours for life
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Configuration as Code
Managing application and infrastructure configuration in version-controlled files instead of manual settings
Config Drift Prevention
Detecting and preventing configuration drift, when reality slowly diverges from your declared infrastructure
Desired State Configuration
Defining what your infrastructure should look like and letting systems converge toward it automatically
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.
This page explains the idea. The "GitOps" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the GitOps lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about GitOps in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
