# 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.[1](#ref-1) 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. ## 01 Git 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.[5](#ref-5) ## 02 The 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:[2](#ref-2) 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.[3](#ref-3) ## 03 Push 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.[2](#ref-2) 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. ## 04 Argo CD vs Flux Two mature, CNCF-graduated tools dominate GitOps on Kubernetes, and either is a sound choice:[4](#ref-4)[6](#ref-6) - **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.[4](#ref-4) - **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.[6](#ref-6) 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. ## 05 A 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. ## 06 Rollbacks, 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.[2](#ref-2) **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. ## 07 Where 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.[2](#ref-2) 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. **About this piece.** This is part five of a five-part OcxlyDev field guide on running Kubernetes honestly — the reality check, the control plane, supply-chain security, disposable nodes, and GitOps. Every load-bearing claim links to a primary or reputable source below; prices and figures are attributed to their source and can move, so check the live page before quoting them. ## References 1. [GitLab — "What is GitOps?": background on the term coined at Weaveworks in 2017](https://about.gitlab.com/topics/gitops/) 2. [OpenGitOps (CNCF) — the four principles of GitOps: declarative, versioned and immutable, pulled automatically, continuously reconciled](https://opengitops.dev/) 3. [OpenGitOps — "OpenGitOps 1.0": a vendor-neutral definition of GitOps](https://opengitops.dev/blog/1.0-announcement/) 4. [Argo CD — official documentation: declarative, application-centric GitOps continuous delivery for Kubernetes](https://argo-cd.readthedocs.io/) 5. [Kubernetes Documentation — "Declarative Management of Kubernetes Objects": the model GitOps builds on](https://kubernetes.io/docs/concepts/overview/working-with-objects/object-management/) 6. [Flux — official documentation: a composable GitOps toolkit for keeping Kubernetes in sync with sources](https://fluxcd.io/)