GitOps is an operating model for cloud-native applications and infrastructure that uses Git as the single source of truth. Every aspect of the system — application manifests, infrastructure definitions, configuration — lives in a Git repository. Automated operators continuously reconcile the live environment to match what is declared in Git.
The Core Principles of GitOps
The OpenGitOps project defines GitOps through four principles:
- Declarative: The entire system is described declaratively. You define what you want, not how to get there.
- Versioned and Immutable: The desired state is stored in Git. History is immutable. Every change has an author, a timestamp, and a reason (commit message).
- Pulled Automatically: Software agents automatically pull and apply the approved state from Git. No human runs
kubectl applyin production. - Continuously Reconciled: Software agents continuously observe actual system state and reconcile any differences from the desired state in Git.
Push-Based vs Pull-Based Deployments
Traditional CI/CD pipelines use a push model: the pipeline runs, builds an artefact, and then pushes a deployment command (e.g., kubectl apply) to the cluster. This requires the pipeline to have direct network access and credentials for the cluster.
GitOps uses a pull model: a GitOps operator running inside the cluster watches a Git repository and pulls changes when they are detected. The cluster initiates the connection — it never exposes an inbound attack surface to the CI system.
| Factor | Push-Based | Pull-Based (GitOps) |
|---|---|---|
| Credentials stored in | CI system (secrets) | Cluster only (Git read access) |
| Drift detection | None — only applied at deploy time | Continuous — alerts on any drift |
| Rollback | Re-run old pipeline | git revert — automatic reconciliation |
| Audit trail | CI logs | Git history — immutable |
| Disaster recovery | Restore from backup + redeploy | Point new cluster at Git repo — self-healing |
GitOps Tools
ArgoCD
ArgoCD is a declarative GitOps operator for Kubernetes. It runs in the cluster and continuously syncs Kubernetes manifests from a Git repository. Features include:
- Visual UI showing sync status and resource health
- Automatic or manual sync modes
- Multi-cluster management from a single ArgoCD instance
- RBAC for controlling who can sync or override which applications
Flux
Flux is another CNCF GitOps operator for Kubernetes, part of the graduated CNCF project. It is more modular than ArgoCD — you compose controllers (source, kustomize, helm, image automation). Useful when you want fine-grained control or a CLI-first workflow.
Repository Structure for GitOps
A common pattern is to separate the application code repository from the deployment configuration repository:
- App repo: Source code. CI builds a Docker image and pushes it to a registry. CI then opens a PR on the config repo to update the image tag.
- Config repo: Kubernetes manifests or Helm values for all environments. ArgoCD/Flux watches this repo. Merging a PR to main triggers a production deployment.
This separation means the deployment pipeline is fully auditable in Git and any developer can see exactly what is running in every environment by reading the config repo.
GitOps and Infrastructure
GitOps is not limited to Kubernetes workloads. The same principles apply to:
- Terraform: Store HCL in Git, run
terraform plan/applyvia Atlantis or Terraform Cloud on pull request - AWS CloudFormation / CDK: Store stacks in Git, deploy via CDK Pipelines
- Crossplane: Manage cloud resources (S3, RDS, IAM) as Kubernetes objects, reconciled by Crossplane operators