GitOps

The term was coined in 2017 by Alexis Richardson of Weaveworks, whose Flux tool first implemented it for Kubernetes. The CNCF OpenGitOps project later distilled it into four principles (v1.0.0): the system's desired state is expressed declaratively; it is stored in a way that is versioned and immutable, with a complete history; software agents pull the desired state automatically from that source; and those agents continuously reconcile the actual state towards it. Git is the usual store but not strictly required - OCI artefacts in a registry satisfy the same principles and are increasingly used as the transport.

The reference implementations are Argo CD and Flux, both graduated CNCF projects. An in-cluster controller clones or polls the repository (or receives a webhook), renders the manifests - plain YAML, Kustomize overlays or Helm charts - computes a diff against live objects using server-side apply or three-way merge, and applies the difference. With automated sync and self-heal enabled, a manual kubectl edit is reverted on the next reconciliation; pruning deletes objects that have disappeared from the repository. Ordering is handled with sync waves and hooks (Argo CD) or dependsOn and health checks (Flux). A typical layout separates application source repositories from an environment or "config" repository; CI builds and signs an image, then opens a pull request that bumps the image digest in the config repo, and promotion between environments is itself a reviewed merge.

The pull model is the security argument: CI no longer needs cluster-admin credentials, because only the in-cluster agent writes to the API server, and the audit trail of production changes is the repository's commit and review history. The trade-off is that the repository, and whoever can merge to its protected branches, now effectively controls production. Controls include branch protection with required reviews, verification of signed commits (both Argo CD and Flux can refuse unsigned or untrusted revisions), least-privilege service accounts per application rather than one cluster-admin controller, and restricting which repositories and namespaces each application may target. Secrets cannot be committed in plaintext, so teams use Sealed Secrets or SOPS-encrypted files, or reference external stores through the External Secrets Operator.

GitOps differs from infrastructure as code in scope and mechanism: IaC describes resources declaratively but is often applied in a push model by a pipeline running terraform apply, with drift detected only at the next plan, whereas GitOps adds continuous, agent-driven reconciliation. Failure modes include reconciliation loops fighting other controllers such as autoscalers over the same fields, drift hidden by ignore rules, and outages when the Git host is unavailable - running workloads continue, but nobody can change them through the normal path.