What it is
GitOps is an operating model where a Git repository holds the desired state of your systems, and software running inside the environment keeps reality in line with that repository. You do not run a deploy command and hope it worked. You change a file, open a pull request, get it reviewed, merge it, and an agent applies the change.
The defining trait is the reconciliation loop. An agent such as Argo CD or Flux runs inside the cluster, watches the repo, compares the declared state against the live state, and corrects the difference. If someone edits a Deployment by hand at two in the morning, the agent sees the drift and either flags it or reverts it, depending on your sync policy.
GitOps is not the same as keeping YAML in Git. Many teams commit manifests and still deploy by running kubectl apply from a laptop. The loop is what makes it GitOps: the environment is continuously pulled toward the declared state instead of being pushed once and forgotten.
The pattern is most common with Kubernetes, but the idea travels. Any place where an agent can read a repository and act on a system can be run this way, including some network and cloud account configuration.
How it works
Most teams keep two repositories. The application repo holds source code and the pipeline that builds a container image. The config repo holds what should run where: base manifests plus an overlay for development, staging and production. Splitting them means your build pipeline never needs write access to production.
The agent is installed in each cluster and pointed at a path in the config repo. On a schedule, or when the repo changes, it fetches the desired state, diffs it against the cluster, and syncs. Good agents also report health, which means they check whether pods actually became ready, not just whether the apply call returned without an error.
A typical change walks through these steps. A developer merges code to the application repo. CI builds the image and tags it with the commit SHA. A pull request updates that tag in the config repo. A reviewer approves. The agent syncs. Every change that reaches production is a reviewed commit with a name and a timestamp attached.
Sync behavior comes in separate switches, and the order matters. Automated sync applies changes. Self heal reverts manual edits. Prune deletes resources that are no longer in Git. Rollback is usually a revert commit followed by a sync, or a return to a previous synced revision in Argo CD. Secrets stay out of the repo: store them in a vault or a cloud secret manager and commit only a reference through something like the External Secrets Operator or Sealed Secrets.
Why it matters for a business
The audit trail is the biggest practical win. Git history answers who changed what, when, and who approved it. That is exactly the evidence a security reviewer asks for during a SOC 2 audit or a customer questionnaire, and you can produce it without reconstructing anything by hand.
Recovery gets simpler. If a cluster is lost or a region fails, you point a new cluster at the repository and it converges on its own. Nobody has to remember the six manual steps someone did last year.
It also lowers key person risk. When the release process lives in files, review rules and pipelines rather than one engineer's memory, new hires can read the repo and understand how production is shaped. The team stops scheduling around one person's calendar.
The trade-off is real. GitOps adds structure: repo layout, review discipline, secret handling, and someone who owns the repository. It also moves risk rather than removing it. A bad merge with automated sync on every cluster can go everywhere at once, so gate production separately.
Common mistakes
Putting secrets in Git. A base64 encoded Secret manifest is encoding, not encryption, and it stays in history after you delete it. Use a sealed secret or an external secret store and commit only the pointer.
Ignoring drift. If self heal is off and nobody reads the out of sync list, the repo slowly becomes fiction. The usual pattern is a hotfix applied straight to a cluster during an incident and never written back. The next sync then undoes a fix people depend on, or worse, leaves two versions of the truth.
Turning on automated sync with prune on day one. Prune removes anything in the cluster that is not in Git, including resources created by an operator, a backup tool, or another team. Learn what lives in the namespace first, then enable it deliberately.
One repository, one environment, and floating tags. Teams that point development, staging and production at the same folder lose the ability to promote changes in steps. Tags like latest make rollback guesswork because you cannot tell which image was running. Pin an immutable tag per environment and keep each environment in its own overlay.
How to get started
Start with one stateless service in staging. Install Argo CD or Flux in that cluster, create a config repo, and add the manifests for that single service. Resist adding everything at once; you want a loop you can watch and reason about.
Structure the repo before you scale it. A common shape is a base directory with shared manifests and one overlay per environment that patches image tags, replica counts and resource limits. Keep the production path separate so a change to staging cannot reach production by accident.
Turn the switches on in order. Begin with manual sync and read the diffs until they stop surprising you. Then allow automated sync. Then self heal. Then prune, after you have listed what is in the namespace. Add branch protection, required approvals and a CODEOWNERS file on the production path, and run one rollback drill so the team has done it before it matters.
Once that service is boring, widen the scope and decide how platform add-ons and secrets are handled. Cloudverg's Delivery platform setup package is one option among others for teams that want pipelines, separate environments, secret management, monitoring and a tested rollback put in place together.
Frequently asked questions
Is GitOps only for Kubernetes?
No, but Kubernetes is where it is most mature because tools like Argo CD and Flux already run in the cluster and understand its resources. The same pull and reconcile pattern can be applied to cloud account configuration and some network devices. Start where your tooling already supports the loop.
What is the difference between GitOps and CI/CD?
CI/CD builds and tests code and produces an artifact such as a container image. GitOps handles what happens after that: it records which artifact should run where and makes the environment match. They fit together, with CI writing a tag into a config repo and the GitOps agent deploying it.
Do secrets go into the Git repository in GitOps?
They should not. Commit only a reference, such as an ExternalSecret pointing at a cloud secret manager, or an encrypted sealed secret. The plaintext value stays in the secret store, and access to it is granted through roles rather than through repository permissions.