🏗️ What is GitOps? (And What Isn’t It?)

“GitOps” has been a popular term in the DevOps community since Weaveworks coined it in 2017. However, much like “DevOps” itself, it’s become an overloaded term, with various vendors offering their own definitions.

Atlassian describes GitOps as this:

At its core, GitOps is code-based infrastructure and operational procedures that rely on Git as a source control system. It’s an evolution of Infrastructure as Code (IaC) and a DevOps best practice that leverages Git as the single source of truth, and control mechanism for creating, updating, and deleting system architecture. More simply, it is the practice of using Git pull requests to verify and automatically deploy system infrastructure modifications.

🔼 Is GitOps the next big thing in DevOps?

GitLab makes it simpler:

GitOps is an operational framework that takes DevOps best practices used for application development such as version control, collaboration, compliance, and CI/CD, and applies them to infrastructure automation.

🔼 What is GitOps?

And Red Hat offers a similar high-level abstraction:

GitOps is a set of practices for managing infrastructure and application configurations to expand upon existing processes and improve the application lifecycle.

🔼 What is GitOps?

While these definitions are all correct, they are also very high-level. When a single term carries so many abstractions, it can become confusing and lose its practical, opinionated meaning. A more pragmatic site, GitOps.tech, offers a clearer perspective from a historical point of view.

Essentially, GitOps manifests in two primary modes: push-based and pull-based. In both models, Git serves as the central source of truth, but they differ significantly in how that truth is applied to the environment.

The “Push-Based” Model (aka. CI-driven IaC)

Based on my experience, the push-based model was common long before the “GitOps” term was coined. It’s a natural and powerful evolution of Infrastructure as Code (IaC).

In this pattern, you store your infrastructure code (like Terraform or Ansible configurations) in a Git repository. A CI/CD pipeline (like GitHub Actions, GitLab CI, or Jenkins) is then triggered by a Git event—such as a merge to the main branch. This pipeline “pushes” the changes to your target environment. This is a robust, widely-used, and highly effective pattern in the developer ecosystem.

The “Pull-Based” Model (The Real GitOps)

From my perspective, the term “GitOps” was truly coined to describe the pull-based model, specifically in the context of Kubernetes. This pattern solves a problem that is particularly difficult in declarative, API-driven systems like K8s: configuration drift.

As the number of engineers with access to a Kubernetes cluster grows, so does the risk of manual, ad-hoc changes. The platform’s convenience, with its powerful CLI and variety of tools, makes it easy for a well-intentioned operator to run a kubectl edit or kubectl scale command, opening the “can of worms” of configuration drift. Suddenly, the actual state in the cluster no longer matches the intended state defined in Git.

This is the exact problem the pull-based model solves. It works by placing an agent (this is where tools like ArgoCD and Flux compete) inside the cluster. This agent is configured to continuously monitor a Git repository. When it detects a change in Git, or more importantly, a drift in the cluster, it “pulls” the correct configuration from Git and automatically reconciles the cluster’s state to match it.

This model enforces Git as the only source of truth and automatically corrects any manual, out-of-band changes.

My Conclusion: Let’s Be Clear

You don’t find it popular implementing this pull-based pattern for managing public cloud resources (like AWS or GCP) because that problem space is already well-served by the push-based IaC model.

In conclusion, I believe that while both models are valid, the term “GitOps” provides the most value when it refers to the Kubernetes-centric, pull-based reconciliation model. This is the pattern that solves the unique challenge of configuration drift in modern, declarative systems.

To avoid confusion, we should call push-based, continuous deployment pipelines what they are: CI-driven IaC.

AI Usage Disclaim

LLM model	Version	Source
Gemini	2.5 Pro	Gemini Web App