GitOps
Last updated 2026-06-04
GitOps is a way of operating infrastructure in which the desired state of a system is declared as version-controlled code in Git, changes are proposed and reviewed as pull requests, and an automated process continuously reconciles the live environment to match what is committed. Because Git is the single source of truth, every change is auditable through commit history, reversible by reverting a commit, and protected against configuration drift, since the reconciler corrects divergence from the committed state. The model is declarative rather than imperative: you describe the end state you want, and the reconciliation tooling figures out the steps to reach it, re-applying the desired state if anything diverges. Common targets include Kubernetes manifests and Terraform definitions, with rollbacks handled like any other code change. LevelFour applies cost optimizations the GitOps way: each change is written back to Git as a pull request rather than applied directly to live resources, so your cloud and clusters always match what is in code.
Frequently asked questions
- How is GitOps different from traditional infrastructure-as-code?
- Infrastructure-as-code defines infrastructure in version-controlled files, but GitOps adds a workflow around it: Git is the single source of truth, every change flows through pull requests, and an automated process continuously reconciles the live environment to match the committed state, correcting drift without manual deploys.
- How do you roll back a change in GitOps?
- You revert the commit or merge the pull request that undoes it, then let the reconciliation process apply the previous declared state. Because Git holds the full history, rollbacks are auditable and repeatable: there is no separate, manual undo step on the live environment, only another reviewable change in Git.
LevelFour automates this across AWS, GCP, Azure, and Kubernetes with automated infrastructure-as-code pull requests.