GitOps
Before GitOps, keeping an environment in a known state usually meant someone SSHing into a server or clicking through a cloud console, and the record of what was actually running lived partly in a script, partly in someone's memory, and partly in whatever the server happened to be doing at the time. Over enough changes, what was documented and what was actually deployed would quietly drift apart. GitOps closes that gap with one rule: the desired state of a system is described declaratively in files, committed to a Git repository, and nothing is considered real until it's in Git.
An operator or controller running inside the target environment does the rest of the work. It watches the repository, and when a change lands, whether that's a new Kubernetes manifest or an updated Terraform file, it applies that change automatically. It doesn't stop there: the controller keeps comparing the live environment against what Git says it should look like, and if the two ever drift apart, say someone manually edited something directly in production, it reconciles the live state back to match Git rather than the other way around.
That's a meaningfully different shape from a typical CI/CD pipeline, which usually pushes a deployment out to an environment as one of its final steps. GitOps instead has an agent inside the environment pull the desired state toward itself, which means deployment credentials never have to leave that environment and get handed to an external system. In practice, the two are often used together, a pipeline built with something like GitHub Actions handles build and test, and a GitOps controller handles the actual deployment step.
How it works
- Desired state is described declaratively, as YAML manifests, Terraform, or similar configuration, and stored in a Git repository.
- A change to that desired state goes through a pull request, with the same review and approval process as an application code change.
- A controller running inside the target environment continuously compares the live state against what's in Git.
- When the two differ, whether from a merged change or manual drift, the controller reconciles the live system to match Git automatically.
- Every change is versioned and auditable, since Git's history already records who changed what and when.
Where it shows up
- Managing Kubernetes clusters, where tools like Argo CD or Flux continuously sync manifests from a repository into the cluster.
- Provisioning cloud infrastructure with Terraform, where a merged change to a configuration file triggers an apply instead of someone running it locally.
- Recovering from an incident by reverting a Git commit, letting the reconciliation loop restore the previous known-good state automatically.
- Preventing untracked manual changes to production, since the controller reverts a manual edit back to match Git anyway.
Benefits and challenges
| Benefit | Challenge |
|---|---|
| Git becomes the single, auditable source of truth, so what's actually running and what's documented stop drifting apart. | Everything has to be expressed declaratively in files, which doesn't fit every kind of operational task equally well. |
| A bad deploy becomes a revert, rolling back to a previous state means reverting a commit rather than reconstructing a manual fix. | Setting up the reconciliation tooling and getting a team to work this way is real upfront investment, not a quick switch to flip. |
| Reduces how many people or systems need direct write access to production, since the controller applies changes, not a person. | Secrets management gets trickier, since the repository holding desired state can't just contain plaintext credentials. |
Frequently asked questions
Is GitOps the same thing as CI/CD?
Related, but not the same. A CI/CD pipeline typically builds and tests code, then pushes a deployment out to an environment as one of its steps. GitOps instead has a controller inside the target environment pull the desired state from Git and reconcile it there. Many teams use both together, a pipeline handles build and test, and GitOps handles the deployment step.
Does GitOps only work with Kubernetes?
It's most associated with Kubernetes, where tools like Argo CD and Flux originated, but the underlying idea, declarative desired state in Git plus automated reconciliation, applies to any infrastructure that can be described declaratively, including cloud resources managed through Terraform.
What happens if someone manually changes a production environment outside of Git?
The reconciliation controller detects that the live state no longer matches what's in Git and reverts it back automatically, on whatever interval it's configured to check. That's a deliberate part of the model, Git is treated as the only place a change is allowed to originate from.
How Klarent helps
Klarent's tests run as a step inside the same pipelines that trigger a GitOps deployment, checking a change before or after it's synced to an environment, and self-healing execution keeps that check reliable even as the environment it's testing changes underneath it.