GitOps

GitOps uses Git as the single source of truth for infrastructure and application state, with an automated agent continuously reconciling the cluster to match committed manifests.

delivery

Definition

GitOps is an operating model in which the desired state of infrastructure and workloads lives in Git, and an automated controller continuously reconciles the running system toward that committed state, making every change reviewable and reversible.

Context and scope

It is used by platform teams running Kubernetes and cloud infrastructure who want auditable changes, drift detection, and recovery without granting humans direct production access.

Common misconceptions

GitOps is just storing YAML in Git — without a reconciler that detects and corrects drift, it is only documentation.
GitOps forbids all manual access — break-glass procedures still exist, but their results must be reconciled back into Git.
GitOps replaces CI — CI still builds and tests artifacts; GitOps governs how state is deployed and maintained.

Anti-patterns

Running kubectl apply from a laptop while the agent reverts the change minutes later
Putting secrets in plain Git instead of sealed secrets or an external secret store
One repository and one pipeline with no environment promotion path

Related concepts

Authoritative source

https://opengitops.dev/

Git as the desired state

In a GitOps workflow, a repository declares the desired state of the system: deployments, services, policies, and infrastructure. A controller inside the cluster, such as Argo CD or Flux, watches that repository and compares it with live state. When they differ, the controller applies the difference. Merging a pull request becomes the deployment action, and the commit history becomes the audit log.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: api
          image: registry.example.com/api:1.8.2

When to use it

Use GitOps when multiple teams change shared clusters, when auditors ask who changed what and when, or when disaster recovery means re-applying a repository. It fits Kubernetes best because controllers can reconcile continuously. Compared with pipeline-driven deployment, where CI pushes changes, GitOps pulls from inside the cluster, so deployment credentials never leave the environment.

Trade-offs

Reconciliation loops can fight operators who make manual hotfixes, so define a break-glass process. Repository structure matters: environment-per-directory keeps promotion explicit, while complex branching strategies become merge-heavy. Secret management and manifest rendering tools add complexity.

Example and misconceptions

A platform team stores each environment in its own directory. Promoting a release is a pull request that copies an image tag from staging to production, reviewed by another engineer. The controller reports drift within a minute if anyone edits the cluster by hand. The common myth that GitOps equals YAML in Git misses the reconciler, which is what makes the model operational. Related concepts: infrastructure as code, CI/CD, and immutable infrastructure.