What does GitOps actually look like when a team puts it into practice? The term gets thrown around a lot in cloud-native circles, but the concrete patterns are what make it click. Once you see a few real examples, the abstract idea of “Git as the source of truth” turns into something you can copy on Monday morning.
This article walks through the most common GitOps examples, from a single application deployed to a cluster to fleets of clusters managed from one repository. Along the way, it covers the tools that do the work, the patterns that scale, and the mistakes that trip people up.
A Quick Refresher on What GitOps Means
Before diving into examples, it helps to be precise about the definition. The OpenGitOps project, a set of working groups under the CNCF, describes four core principles: the desired state is declared, that state is versioned and immutable in Git, changes are pulled automatically rather than pushed, and software agents continuously reconcile the actual state with the desired one. You can read the full OpenGitOps principles and definitions if you want the canonical wording.
The key insight is the word “pull.” In a traditional CI/CD pipeline, the build server pushes changes to the cluster. That means the pipeline holds credentials with permission to change production. In GitOps, an agent inside the cluster watches Git and pulls what it finds. The cluster reaches out; nothing from outside reaches in.
That single design choice explains most of the benefits people talk about: better security, a full audit trail in Git history, and the ability to roll back by reverting a commit.
Example 1: A Single Application Synced from a Repository
The simplest GitOps example is one application, one repository, one cluster. A developer changes a container image tag in a Kubernetes manifest, opens a pull request, and merges it after review. Within a minute or two, the GitOps agent notices the new commit and applies the change. (GitOps)
With Argo CD, this is an Application resource that points at a Git repository path and a target cluster. With Flux, it is a Kustomization or HelmRelease object that references a Git source. Either way, the flow is the same.
A practical tip from teams running this pattern: keep the application manifests in a dedicated repository separate from the application source code. Mixing them creates noise, because every code commit triggers a manifest change and clutters the Git history you rely on for auditing. Separate repos mean the deployment repo’s log reads like a clean list of what actually shipped.
Example 2: The App-of-Apps Pattern for Bootstrapping a Cluster
Here is where GitOps works differently. Instead of applying dozens of manifests by hand to a new cluster, you point one root application at a directory of child application definitions. Each child is itself a GitOps application manifest. Add a new file to the directory, commit it, and the new service appears in the cluster.
The Argo CD documentation calls this the app-of-apps pattern for cluster bootstrapping, and it is one of the most copied GitOps examples in the wild. The root application is the only thing a human applies manually, and even that can be automated with a small bootstrap script.
The common mistake here is nesting too deeply. A root app pointing at child apps that point at more child apps becomes hard to debug when something fails to sync. Most teams do well with two levels: one root, many children. If you find yourself needing a third, that is usually a signal to split into separate repositories by team or environment.
Example 3: Environment Promotion Through Branches or Directories
A classic question is how to move a change from staging to production. GitOps offers a few clean answers, and the choice matters.
| Approach | How it works | Best for |
|---|---|---|
| Branch per environment | Staging and production live on separate branches; promotion is a merge | Small teams that like pull requests as the approval gate |
| Directory per environment | One branch, folders like overlays/staging and overlays/prod | Teams using Kustomize overlays |
| Repository per environment | Fully isolated repos with separate access controls | Regulated environments needing strict separation |
The directory approach tends to win for most teams because it keeps everything visible in one place and avoids the merge conflicts that plague long-lived environment branches. The branch approach is easier to reason about for people new to Git, but cherry-picking fixes between branches gets old fast.
Whichever you pick, the promotion step should be a pull request. That is the whole point: a human reviews the diff, approves it, and the agent does the rest. No one runs kubectl apply against production at 11 p.m.
Example 4: Automated Image Updates That Commit Back to Git
This example surprises people who assume GitOps is read-only. It is not. Some of the most useful GitOps workflows write to Git as well as read from it.
Flux includes an image automation feature that watches a container registry for new tags, then commits the updated image reference back to the Git repository. The official Flux guide to automating image updates walks through the setup. The result is a fully automated loop: a CI system builds and pushes an image, Flux notices it, commits the new tag, and then reconciles it into the cluster. Every step leaves a Git commit behind. (Pro Git book (official Git documentation))
Argo CD has a comparable capability through Argo CD Image Updater, a separate project. The trade-off is worth understanding. Fully automated image updates reduce toil but remove the human approval step, so most teams restrict automation to staging and keep a manual pull request for production. That hybrid gives you speed where it is safe and control where it counts.
Example 5: Managing a Fleet of Clusters from One Repository
Once a team runs more than a handful of clusters, per-cluster configuration becomes a maintenance burden. GitOps scales here through generators and templating.
Argo CD’s ApplicationSets can generate one application per cluster from a list, a cluster label selector, or a Git directory structure. Flux achieves similar results with its multi-cluster patterns, where a Kustomization can target clusters by label. The practical effect is that onboarding a new cluster means adding an entry to a list or applying a label, not writing new manifests.
A pattern that works well in practice: keep cluster-specific settings in small overlay directories and shared configuration in a common base. When a platform team needs to roll out a policy change across forty clusters, they edit one base file and open one pull request. The agents in each cluster pick it up on their next reconciliation.
Example 6: Infrastructure and Platform Components Under GitOps
GitOps is not limited to application workloads. Platform teams use the same pattern for cluster add-ons: ingress controllers, certificate managers, monitoring stacks, and policy engines. These are installed once per cluster and rarely change, which makes them ideal candidates for declarative management.
The benefit shows up during incidents. When a cluster is rebuilt from scratch after a failure, the add-ons come back automatically because they were never applied by hand in the first place. Teams that manage platform components this way often describe disaster recovery as “point a new cluster at the repo and wait.”
The pattern extends beyond Kubernetes too. Controllers exist that reconcile cloud infrastructure and other external resources from Git, though the projects around them change quickly, so check current project status before committing to one.
Example 7: Progressive Delivery Gated by Git
A more advanced example combines GitOps with progressive delivery. A controller such as Argo Rollouts or Flagger manages a canary release, shifting traffic gradually and checking metrics. The rollout definition, including the analysis thresholds, lives in Git alongside everything else.
This pattern works because the promotion criteria become reviewable. If someone loosens the error-rate threshold that allows a canary to proceed, that change shows up as a diff in a pull request. Reviewers can question it before it reaches production. The same applies to feature flags and any other configuration that affects how software behaves.
Pull Versus Push: Why the Examples All Look This Way
Every example above relies on a pull-based agent. It is worth naming the contrast explicitly, because teams migrating from older pipelines often try to keep the push model and wonder why GitOps feels like extra work.
In a push model, the CI system connects to the cluster and applies changes. In a pull model, the agent connects to Git. The security difference is significant: the CI system never needs cluster credentials, and the cluster’s Git access can be read-only. The operational difference matters too. If someone manually changes a resource in a live cluster, a pull-based agent will notice the drift and correct it on the next reconciliation cycle. A push pipeline has no idea the drift happened.
That drift correction is the feature people underestimate most. It quietly enforces the rule that Git is the only way to change production, which is the whole promise of the approach.
Common Mistakes That Break GitOps Examples in Practice
Copying an example is easy. Keeping it healthy is the harder part. A few failure modes come up again and again.
Storing secrets in plain Git. This is the number one mistake. Encrypt them with a tool like Sealed Secrets or SOPS, or pull them from an external secret manager at runtime. A GitOps repository is often readable by a wide group of people, and a leaked credential in Git history is painful to scrub.
Letting the repository drift from reality. If people still have kubectl access to production and use it, the repo stops being the source of truth. Lock down direct access and make the pull request path the only route to change.
Ignoring reconciliation health. A sync that silently fails is worse than no sync, because everyone assumes the cluster matches Git when it does not. Alert on out-of-sync and degraded states, and treat them as real incidents.
Over-abstracting too early. Helm charts wrapped in Kustomize wrapped in generators wrapped in ApplicationSets is a debugging nightmare. Start simple. Add layers when a specific problem demands them.
Skipping the review culture. GitOps gives you a review gate, but it only helps if people actually review. A repository where pull requests get rubber-stamped is just a slower push pipeline.
For teams tracking how these practices evolve, industry news coverage is a useful complement to documentation, and resources like the news section at 9481.org follow developments across cloud-native tooling. Deeper technical write-ups often appear in blog archives on the same site, and infrastructure topics are collected under the cloud category.
How to Choose Your First GitOps Example to Copy
If the goal is to learn by doing, start with Example 1 and resist the urge to jump ahead. Get one application syncing reliably, watch what happens when you change a manifest, and deliberately introduce drift to see the agent correct it. That hands-on loop teaches more than any diagram.
Then move to Example 2 for bootstrapping, because it changes how you think about new clusters. Environment promotion and image automation can follow once the basics feel boring, which is the right time to add complexity.
The tool choice between Argo CD and Flux matters less than people expect. Both are mature, both are CNCF projects, and both implement the same principles. Pick the one whose user interface and configuration style fits your team, and spend your energy on the repository structure and review process instead. Those are the parts that determine whether GitOps works for you.
Conclusion
GitOps examples range from a single manifest synced to one cluster to fleets of clusters managed through generated applications. What connects them all is a simple contract: Git holds the desired state, an agent pulls it, and any difference gets reconciled automatically. The patterns in this article are proven, widely documented, and copyable. Start small, keep secrets out of plain text, protect the review gate, and let the reconciliation loop do the boring work. That is where the real value shows up, week after week, without anyone running a deploy command.
Frequently Asked Questions
What is the simplest GitOps example to start with?
One application in one Git repository, synced to one cluster by a GitOps agent. A developer merges a manifest change, the agent detects the commit and applies it, and the cluster matches Git within minutes. It requires no templating, no generators, and no multi-cluster logic, which makes it the ideal first step.
Do GitOps tools only work with Kubernetes?
No, though Kubernetes is where the pattern is most mature. Controllers exist that reconcile cloud infrastructure and other external resources from Git. The set of projects around non-Kubernetes controllers changes quickly, so verify a project’s current maintenance status before adopting it for production use.
How do secrets fit into a GitOps workflow?
They should never sit in Git as plain text. Common approaches include encrypting them before committing, using a sealed-secret controller, or referencing an external secret manager that injects values at runtime. The goal is to keep the repository safe to share widely while still letting the agent reconcile everything it needs.
What happens if someone manually changes a live cluster?
A pull-based agent detects the difference on its next reconciliation cycle and reverts the resource to match Git. This drift correction is a core benefit, but it only works if direct cluster access is restricted. If people routinely bypass Git, the repository stops being the source of truth.
Is GitOps the same as CI/CD?
They overlap but are not identical. CI builds and tests code; CD delivers it. GitOps specifically describes pull-based delivery where an in-cluster agent reconciles state from Git. Many teams run CI as usual and use GitOps for the delivery half, keeping cluster credentials out of the build system entirely.
Which is better, Argo CD or Flux?
Both are mature CNCF projects that implement the same principles, so neither is objectively better. Argo CD offers a strong web interface and the app-of-apps pattern; Flux offers a composable toolkit and built-in image automation. The better choice depends on your team’s preferences and existing tooling, not on a feature checklist.
