GitOps in practice: the future of Kubernetes deployments

GitOps turns your Git repository into the control panel for your cluster: the repo declares what should be running, and an agent inside the cluster works continuously to make it so. Here is how it works, why it won, and how to stand up a minimal pipeline.

The term GitOps was coined in 2017 by Alexis Richardson, then CEO of Weaveworks, to name a pattern his team already lived by: describe your entire system declaratively, keep that description in Git, and let automation continuously reconcile the running system to match.¹ Nearly a decade later it is the default way serious teams operate Kubernetes — not because it is fashionable, but because it turns deployment from a series of imperative actions into a property of a versioned file.

01Git as the single source of truth

The core move of GitOps is simple and radical: the desired state of your entire system lives in Git, and Git is the only source of truth. No one runs kubectl apply by hand against production; no one clicks in a console. To change the cluster, you change a file in the repository and merge it. The cluster follows the repository — never the other way around.

This inverts where change originates, and the benefits fall out almost for free. Every change is a commit, so you have a complete, attributed, timestamped history of everything that ever ran. Every change is reviewed, because it is a pull request. Rolling back is git revert. Auditing is git log. The practices software engineers already trust for code now govern infrastructure, because infrastructure is code in a repository — which is exactly what Kubernetes' declarative object model was built to support.⁵

02The four principles of GitOps

GitOps is vendor-neutral, and the CNCF's OpenGitOps project distilled it to four principles that any real implementation should satisfy:²

1. Declarative — the entire desired state of the system is expressed declaratively, as what should be true, not a script of steps to get there.
2. Versioned and immutable — that desired state is stored so it is versioned and immutable, with a complete history. Git is the natural home, but the principle is the point.
3. Pulled automatically — software agents automatically pull the desired state from the source, rather than having changes pushed in from outside.
4. Continuously reconciled — agents continuously observe actual state and reconcile it toward the desired state, correcting any drift.

OpenGitOps reaching 1.0 in 2021 mattered because it gave the industry a shared, tool-independent definition — GitOps as a set of principles, not a particular product.³

03Push vs pull: why GitOps pulls

Traditional CI/CD pushes: a pipeline runs, authenticates into the cluster, and applies changes from outside. GitOps pulls: an agent running inside the cluster watches the Git repository and applies changes from within.² This inversion is not cosmetic. In the pull model, your CI system never needs cluster-admin credentials — it only needs to write to Git — which removes a large and frequently-breached class of secret from your pipeline. And because the in-cluster agent is always watching, it does not merely apply changes on deploy; it keeps the cluster matching Git, undoing any manual drift someone introduces by hand. The repository is not a deploy trigger. It is a living contract the cluster is held to.

04Argo CD vs Flux

Two mature, CNCF-graduated tools dominate GitOps on Kubernetes, and either is a sound choice:⁴⁶

• Argo CD presents GitOps as an application-centric system with a strong web UI that visualises each application's desired versus live state and its sync status. Teams that want a clear operator dashboard and an approachable on-ramp often start here.⁴
• Flux is a set of composable controllers (the GitOps Toolkit) that feels native to a Kubernetes-API and command-line workflow, and slots neatly into automation. Teams that prefer building blocks over a bundled UI often prefer it.⁶

The honest summary: they solve the same problem with different ergonomics. Argo CD leads with visualisation; Flux leads with composability. Pick for how your team likes to work, not for a feature-matrix winner — both are graduated projects with large communities behind them.

05A minimal GitOps pipeline

The smallest real GitOps loop has just a few moving parts. You keep your Kubernetes manifests in a Git repository; you install a GitOps agent (Argo CD or Flux) in the cluster and point it at that repository; and from then on, the flow of every change looks like this:

1. Edit a manifest in the repo (e.g. bump the image tag).
2. Open a pull request; a teammate reviews and merges it.
3. The in-cluster agent detects the new commit and pulls it.
4. The agent reconciles the cluster to match the repo.
5. The agent keeps watching -- and reverts any manual drift.

# You never run kubectl against production. You merge to Git,
# and the cluster converges on what Git says.

That is the entire mental model. Adding environments is adding directories or branches; promoting a release is a merge; the agent handles the rest. Because the reconciliation is continuous, a green deploy is not a moment in time — it is a state the agent maintains.

06Rollbacks, drift, and disaster recovery

Continuous reconciliation is what turns GitOps from a convenience into a resilience strategy. Rollback stops being a special procedure: because every state that ever ran is a commit, reverting to a known-good version is a git revert, and the agent rolls the cluster back to match.² Drift — someone hot-fixing production by hand at 3 a.m. — is detected and, depending on your policy, corrected automatically, so the cluster cannot silently diverge from what is reviewed and recorded. And disaster recovery becomes almost anticlimactic: if a cluster is lost entirely, you provision a new one, point the agent at the same repository, and it rebuilds the declared state from the single source of truth. Your recovery plan is your repository.

The deepest idea in GitOps is that a deployment is not an event you perform but a state you declare. Once the cluster's job is to match a reviewed, versioned file — forever — most of what used to be operational drama becomes a merge.

07Where OcxlyDev lands

We treat Git as the control panel for infrastructure and let an in-cluster agent do the reconciling, because it collapses deployment, audit, rollback, and disaster recovery into practices we already trust for code. Start small: one repository of manifests, one agent, one application reconciled from Git — then grow environments and workloads into the same loop. Whether you choose Argo CD or Flux matters far less than committing to the four principles.² Declare what should be true, keep it in version control, and let the cluster spend forever catching up to it. That is not just the future of Kubernetes deployments — for most serious teams, it is already the present.