What is GitOps?
Git as the single source of truth for what runs in production: the desired state lives in the repository, a controller applies it to the real system.
GitOps is the practice of using a Git repository as the single source of truth for how a production system should be configured, typically a Kubernetes cluster or the cloud infrastructure around it. The desired state, which versions run, how many replicas, which configuration, lives in files inside the repository. A controller (Argo CD, Flux and similar) continuously watches the repository and compares it against the system's real state: if they diverge, it reconciles them automatically, instead of waiting for someone to run a deploy command. The term was coined in a 2017 Weaveworks post, and the underlying idea is simple: treat production as a pure function of the repository, not as the result of commands run by hand. This reconciliation sets GitOps apart from a plain "deploy from a pipeline": if someone manually changes an object in the cluster, the controller notices and reverts the system to the declared state, turning configuration drift into a visible event instead of a silent risk found during an incident.
See also: Infrastructure as Code (IaC) · Describing servers, networks and cloud services in versioned code files instead of configuring them by hand, so infrastructure is created and recreated reproducibly.
The difference from classic deployment
In traditional deployment, a CI/CD pipeline actively pushes changes toward the target system: the "push" model. In GitOps the controller inside the cluster pulls the state from the repository: the "pull" model, and the difference is not just technical. No one needs direct credentials to change production: changing the repository, after review, is enough. Every change to the system's state automatically has a Git history, an author, a reason, and rolling back means reverting a commit, not reconstructing from memory what used to run.
How it ties to IaC and CI/CD
GitOps is the natural evolution of Infrastructure as Code applied to the continuous release cycle: IaC describes infrastructure as code, CI/CD automates testing and build, GitOps closes the loop by deciding that the only thing authorized to change production is an approved commit in the right repository. For a data or platform team it means a full audit trail of every environment change and a way to recover from a configuration incident with the same discipline used to recover from a bug in application code.
Related terms
- Infrastructure as Code (IaC) · Describing servers, networks and cloud services in versioned code files instead of configuring them by hand, so infrastructure is created and recreated reproducibly.
- CI/CD · Continuous Integration and Continuous Delivery: every software change is tested and shipped to production automatically and frequently.
- Platform engineering · The discipline building self-service internal platforms for teams: golden path, shared tooling and infrastructure treated as a product.
- AI-Assisted Testing / Agentic QA · AI agents that generate tests, self-heal them, and run whole regression suites: they triage failures and suggest fixes.
- DevSecOps · The DevOps extension that builds security into the CI/CD pipeline as a shared responsibility, not a separate final gate.