Understanding GitOps with Flux CD and GitLab: The Core Concept and Flow Explained

Hey! If you've been hearing a lot about GitOps lately but want a clear, no-commands explanation of what it actually is and how the whole thing flows – especially with tools like Flux CD and GitLab – you're in the right place.

I’ll keep this straightforward, conversational, and focused purely on the concepts and flow. No installation steps, no terminal commands – just the big picture so it finally clicks.

What Exactly Is GitOps?

At its heart, GitOps is a way of managing your applications and infrastructure (especially Kubernetes clusters) where Git becomes the single source of truth.

Think about how developers already work:

• Code lives in Git.
• Changes go through pull requests → review → merge.
• Everyone can see the history, who changed what, and why.
• You can roll back instantly by reverting a commit.

GitOps says: Let’s do the exact same thing for infrastructure and deployments.

Instead of someone SSH-ing into servers or manually running kubectl apply, everything that describes your running system – deployments, services, configs, even secrets – lives as YAML files in a Git repository.

The cluster is automatically kept in sync with whatever is in Git. That’s it. That’s the core idea.

Why This Matters in 2025

• No more configuration drift (when prod behaves differently from staging).
• Full audit trail – every change is a Git commit.
• Easier collaboration between teams.
• Faster and safer rollbacks.
• Security wins (more on that below).

The Two Big Ideas Behind GitOps

1. Declarative
   You don’t tell the system how to deploy (step-by-step scripts).
   You declare what you want the end state to be (in YAML).
   The tools figure out how to get there.

2. Pull-Based (not Push-Based)
   This is the game-changer.
   Traditional CI/CD is push-based: your pipeline builds something → SSH or API call → pushes it to the cluster.
   That gives the CI server a lot of power (and a big attack surface).

   GitOps is pull-based:
   An agent inside the cluster continuously watches the Git repo and pulls changes in.
   The cluster asks: “Has Git changed?” → If yes, apply the new desired state.

   This is more secure because nothing outside needs permission to touch your cluster directly.

How the Flow Works: The GitOps Cycle

Let’s walk through the natural flow when using Flux CD with GitLab. Imagine a real team deploying a web app.

1. The Desired State Lives in Git
   Your GitLab repository contains folders with Kubernetes YAML files (or Helm charts, Kustomize, etc.).
   These files describe exactly how your app should look when running: number of replicas, container image, config maps, ingress rules – everything.

2. A Developer Wants to Make a Change
   Say you want to update the app to a new version or add a feature flag.
   You edit the YAML files in a branch → open a pull request.

3. Team Reviews and Approves
   Just like code review. Teammates check the changes, discuss, maybe request tweaks.
   Once approved → merge to the main branch.

4. Flux Notices the Change
   Inside your Kubernetes cluster, Flux CD (a set of small controllers) is quietly running.
   One part of Flux (the "source controller") keeps an eye on your GitLab repo.
   It either polls every few minutes or gets a webhook notification from GitLab saying “something merged!”

5. Flux Pulls and Applies
   Flux downloads the latest version of your YAML files.
   Another part (like the "kustomize controller" or "helm controller") compares what’s currently running in the cluster with what’s now in Git.
   If they don’t match → Flux applies the differences to make the cluster match Git.

6. The Cluster Now Matches Git
   Your new app version is live, configs updated – all automatically.

7. Drift Detection and Self-Healing
   What if someone manually tweaks something in the cluster (bad idea, but it happens)?
   Flux sees the mismatch on its next check → automatically reverts it back to what Git says.
   The system heals itself.

8. Feedback and Visibility
   Flux can send notifications (Slack, Teams, email) saying “Sync successful” or “Something went wrong – here’s why.”
   Everything is logged, and you always know the true state by looking at Git.

That’s the full loop. It’s simple, repeatable, and reliable.

Why Flux CD Fits This Flow So Well

Flux was literally built for this pull-based, declarative model:

• It’s lightweight and runs entirely inside your cluster.
• It’s modular – different controllers handle Git syncing, applying changes, notifications, etc.
• It supports GitLab natively and securely.
• It respects Git as the boss – the cluster never wins if it drifts.

The Big Benefits You Feel in Real Life

• Peace of mind: You can look at Git and know exactly what’s running in production.
• Faster recovery: Problem? Just git revert and Flux fixes it.
• Better security: No CI runner needs cluster admin rights.
• Multi-environment harmony: Same repo, different folders/branches for dev, staging, prod.

Final Thought

GitOps isn’t a tool – it’s a way of working.
Flux CD is one of the best tools to make that way of working feel natural and effortless, especially when paired with GitLab’s great review and collaboration features.

Once you experience this flow – change → review → merge → cluster auto-updates → done – it’s hard to go back to manual deploys or fragile scripts.

It just makes sense.

If something still feels fuzzy about the concept or flow, drop a comment – happy to clarify further!

What part of GitOps clicked for you the most – the pull-based model, the single source of truth, or something else?