GitOps is not a product and not a vendor. Strip away the branding and it is one rule: the desired state of your infrastructure lives in a Git repository, and software inside the cluster continuously makes reality match it.
That is the whole idea. Everything else — Argo CD, Flux, sync waves, drift detection — is implementation detail that got mistaken for the concept.
The one rule, explained
Traditional deployment means a pipeline runs against the cluster and the cluster ends up as whatever the last few runs left behind. Nobody can say with certainty what is deployed right now, because the answer is spread across shell history and a CI log that rotated out three weeks ago.
GitOps inverts that. The repository is the source of truth. A controller inside the cluster watches the repo, renders the manifests, and compares them to what is actually running. Where they differ, it reconciles. Git becomes the audit log, the rollback mechanism and the documentation at the same time.
Push versus pull
Push means CI holds cluster credentials and applies changes from outside. It is simple and familiar, and it means your build system has production access.
Pull means an agent inside the cluster reaches out to Git and collects changes. No external system holds cluster credentials, and every change leaves a trace. This is what people usually mean by GitOps, and it is the model that survives contact with many clusters and many teams.
- One repository per environment, or one repo with per-environment overlays via Kustomize or Helm values. Pick one and stay consistent.
- Branch strategy is deployment strategy. If a merge to main ships to production, treat main accordingly.
- Secrets never belong in plain Git. Use Sealed Secrets, SOPS, or an external secrets operator.
- Reconciliation intervals matter. Too slow and drift lingers; too fast and you spend your week arguing with the controller.
- Prune is a decision, not a default. Whether deleting a resource from Git deletes it from the cluster is a policy choice with sharp edges.
What it actually fixes
Drift, first. Someone runs a manual edit at 2 a.m., the fix works, nobody records it, and the next deploy silently reverts it. With a controller watching, that difference surfaces immediately instead of becoming a mystery six weeks later.
Rollback, second. Reverting a commit is a normal, reviewable, well-understood operation rather than a scramble through a release dashboard with a half-remembered password.
Onboarding, third. A new engineer reads the repository and understands the platform. No tribal knowledge required and no hunting for the person who wrote the Terraform in 2021.
GitOps does not make deployments safe. It makes them visible, repeatable, and impossible to hide.
What it does not fix
Bad manifests. A controller will faithfully and repeatedly apply a Deployment with no resource requests, a broken readiness probe, or an image tag that does not exist. GitOps guarantees consistency, not correctness. If the desired state is wrong, you get wrong state faster, on schedule, on every cluster at once.
It also does not remove the need for a delivery strategy. Rolling updates, canary releases and progressive delivery are separate concerns; tools such as Argo Rollouts or Flagger sit alongside the GitOps layer, not inside it.
A realistic starting point
Pick one non-critical namespace. Install Argo CD or Flux. Point it at a repository containing those manifests. Let it reconcile and watch what happens. Within a day you will learn which resources were being patched by hand, because the controller will quietly revert every one of them.
How we set it up at Weeltec
Most engagements begin with a repository structure that matches how the team actually deploys, not an idealised one, because a structure nobody follows is worse than a simple one that sticks. We separate application manifests from cluster add-ons, wire secrets management in from the start instead of bolting it on later, and keep the reconciliation path short enough for an incident responder to reason about under pressure.
The rule
If you cannot describe your production state as a commit, you do not have GitOps — you have scripts and a hopeful pipeline. Start with one namespace, one repository and one controller.
We design and operate Kubernetes platforms and the pipelines around them. If your deployments depend on whoever ran them last, get a quote and we will put the state back in Git.