GitOps

GitOps is an operating model in which Git holds the desired state of infrastructure and applications, and software agents make the running system match it. The term was popularised by Weaveworks around 2017 and is now maintained as a set of vendor-neutral principles by the OpenGitOps project.

How it works

The OpenGitOps principles describe a GitOps system as declarative, versioned and immutable, pulled automatically, and continuously reconciled. In practice this means:

1. The desired state is written as declarative manifests, such as Kubernetes YAML, Helm charts or Kustomize overlays.
2. Those files live in a Git repository, so every change has an author, a review and a history.
3. An agent running in the cluster, such as ArgoCD or Flux, pulls the repository and applies it.
4. The agent keeps comparing the cluster with Git and corrects differences, which is known as reconciliation.

Because the cluster pulls its configuration, a CI system does not need credentials to push into production.

A practical example

A team wants to raise the replica count of a service. They edit one field in the Deployment manifest, open a pull request, and a colleague reviews it. After the merge, the agent notices that Git and the cluster differ and applies the change. If the release causes problems, reverting the commit returns the repository to the previous state, and the agent then rolls the cluster back to match.

Common mistakes

• Mixing application source code, environment configuration and secrets in one repository, which makes access control and review awkward. Many teams keep deployment configuration separate.
• Committing plain Kubernetes Secrets. Use an approach such as Sealed Secrets or an external secrets manager.
• Allowing engineers to keep running kubectl edit in production. Manual changes are either reverted by the agent or, if automatic correction is switched off, become silent drift.
• Treating GitOps as only a deployment tool and ignoring how images are built and promoted between environments.

When to use it and when not to

GitOps fits Kubernetes platforms with several environments or clusters, teams that need an audit trail, and organisations that want repeatable rollbacks. It adds less value for a single small workload that changes rarely, or for resources that are not described declaratively. It complements rather than replaces CI/CD: CI builds and tests artefacts, and GitOps controls what is deployed. Our GitOps service covers implementation.

See also

• ArgoCD
• Flux GitOps
• Helm Chart
• Kubernetes