<div id="readability-page-1" class="page"><div><img src="https://devstarsj.github.io/assets/https://images.unsplash.com/photo-1618401471353-b98afee0b2eb?w=1200">GitOps has crossed the chasm. What started as a blog post from Weaveworks in 2017 is now the default CD model for Kubernetes-native organizations. The Git repository is the source of truth. The cluster reconciles itself to match. Humans don’t <code>kubectl apply</code> in production.In this world, the two dominant tools are Flux (v2) and ArgoCD. They solve the same fundamental problem with very different philosophies. Choosing between them — or knowing when to use both — is a meaningful architectural decision.<img src="https://images.unsplash.com/photo-1556075798-4825dfaaf498?w=800" alt="Git branching visualization — network of commits and branches"> Photo by Yancy Min on Unsplash<hr><h2 id="what-gitops-actually-means">What GitOps Actually Means</h2>Before the tools: a quick grounding. GitOps has four principles (per OpenGitOps):<ol><li>Declarative — the desired state of the system is described declaratively</li><li>Versioned and immutable — the desired state is stored in a system that enforces immutability and retains complete version history</li><li>Pulled automatically — software agents automatically pull the desired state declarations from the source</li><li>Continuously reconciled — software agents continuously observe actual system state and attempt to apply the desired state</li></ol>Both Flux and ArgoCD implement all four. The differences are in UX, operational model, and architectural assumptions.<hr><h2 id="flux-v2--the-kubernetes-native-approach">Flux v2 — The Kubernetes Native Approach</h2>Flux v2 (the Flux project under CNCF) was a complete rewrite of the original Flux. It’s built around a toolkit of composable controllers:<ul><li>source-controller — watches Git/Helm/OCI repositories</li><li>kustomize-controller — applies kustomize overlays</li><li>helm-controller — manages Helm releases</li><li>notification-controller — sends alerts, receives webhooks</li><li>image-automation-controller — updates image tags in Git</li></ul>Each controller is a standalone Kubernetes CRD + controller. You compose them.<h3 id="flux-architecture">Flux Architecture</h3><div><pre><code>Git Repository
 ↓ (poll/webhook)
source-controller (GitRepository CRD)
 ↓
kustomize-controller (Kustomization CRD)
 ↓
Kubernetes API
</code></pre></div>Flux runs entirely in your cluster. There’s no separate UI service or central control plane. Everything is Kubernetes-native: <code>kubectl get gitrepositories</code>, <code>flux get all</code>.<h3 id="flux-sample-configuration">Flux Sample Configuration</h3><div><pre><code># GitRepository - where Flux watches
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
 name: my-app
 namespace: flux-system
spec:
 interval: 1m
 url: https://github.com/myorg/my-app
 ref:
 branch: main
---
# Kustomization - what to apply
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
 name: my-app
 namespace: flux-system
spec:
 interval: 10m
 path: ./deploy/production
 prune: true
 sourceRef:
 kind: GitRepository
 name: my-app
 healthChecks:
 - apiVersion: apps/v1
 kind: Deployment
 name: my-app
 namespace: default
</code></pre></div><h3 id="flux-strengths">Flux Strengths</h3><ul><li>Fully Kubernetes-native — no external services, CRD-everything</li><li>Multi-tenancy — designed for platform teams managing many teams/clusters</li><li>GitOps toolkit composability — use only what you need</li><li>Flux image automation — automatically opens PRs when new image tags appear</li><li>Excellent Helm support — HelmRelease CRD is first-class</li><li>CNCF Graduated — proven production maturity</li><li>OCI support — pull Helm charts and manifests from OCI registries</li></ul><h3 id="flux-weaknesses">Flux Weaknesses</h3><ul><li>No built-in UI — you need to add Weave GitOps or build your own</li><li>CLI learning curve — the <code>flux</code> CLI is powerful but non-trivial</li><li>Less visible for developers — harder for app teams to see deployment state without tooling investment</li></ul><hr><h2 id="argocd--the-visibility-first-approach">ArgoCD — The Visibility-First Approach</h2>ArgoCD was built with a strong emphasis on visibility and developer self-service. The UI is not an afterthought — it’s a core product. Developers can see exactly what’s deployed, what’s drifted, and why a sync failed.<h3 id="argocd-architecture">ArgoCD Architecture</h3><div><pre><code>Git Repository
 ↓ (poll/webhook)
ArgoCD Application Controller
 ↓
ArgoCD API Server → UI + CLI
 ↓
Kubernetes API
</code></pre></div>ArgoCD has more components: an application controller, an API server, a repository server, and the web UI. This is a larger operational surface but provides much richer out-of-the-box experience.<h3 id="argocd-sample-configuration">ArgoCD Sample Configuration</h3><div><pre><code>apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
 name: my-app
 namespace: argocd
spec:
 project: default
 source:
 repoURL: https://github.com/myorg/my-app
 targetRevision: main
 path: deploy/production
 destination:
 server: https://kubernetes.default.svc
 namespace: default
 syncPolicy:
 automated:
 prune: true
 selfHeal: true
 syncOptions:
 - CreateNamespace=true
 ignoreDifferences:
 - group: apps
 kind: Deployment
 jsonPointers:
 - /spec/replicas # Managed by HPA, ignore
</code></pre></div><h3 id="argocd-strengths">ArgoCD Strengths</h3><ul><li>Best-in-class UI — visual diff, sync status, health, logs — all in one place</li><li>App of Apps pattern — manage hundreds of apps with a single parent app</li><li>ApplicationSets — templated multi-cluster, multi-tenant deployments</li><li>Strong RBAC — fine-grained access control for teams</li><li>Rollback in the UI — non-technical users can trigger rollbacks</li><li>Sync waves and hooks — sophisticated ordering of multi-resource deployments</li><li>Large ecosystem — Notifications, ApplicationSets, Image Updater plugins</li></ul><h3 id="argocd-weaknesses">ArgoCD Weaknesses</h3><ul><li>Not purely pull-based — ArgoCD server is stateful and needs to be managed</li><li>Multi-cluster complexity — managing many clusters requires careful argocd server placement</li><li>Heavier footprint — more components to run and upgrade</li><li>Git repo credentials — managing secrets for private repos is more involved</li></ul><hr><h2 id="side-by-side-comparison">Side-by-Side Comparison</h2><table><thead><tr><th>Dimension</th><th>Flux v2</th><th>ArgoCD</th></tr></thead><tbody><tr><td>UI</td><td>Optional (Weave GitOps)</td><td>Built-in, excellent</td></tr><tr><td>Architecture</td><td>Pure Kubernetes CRDs</td><td>API server + controllers</td></tr><tr><td>Multi-tenancy</td><td>First-class, built-in</td><td>Via Projects + RBAC</td></tr><tr><td>Multi-cluster</td><td>Hub-spoke via cluster secrets</td><td>Central Argo server manages all</td></tr><tr><td>Helm support</td><td>HelmRelease CRD (excellent)</td><td>Native (excellent)</td></tr><tr><td>Kustomize support</td><td>Native (kustomize-controller)</td><td>Native</td></tr><tr><td>OCI registry support</td><td>Yes (source-controller)</td><td>Yes (with plugins)</td></tr><tr><td>Image auto-update</td><td>image-automation-controller</td><td>ArgoCD Image Updater (separate install)</td></tr><tr><td>Developer self-service</td><td>Requires investment</td><td>High out of the box</td></tr><tr><td>Operational complexity</td><td>Lower</td><td>Higher</td></tr><tr><td>CNCF status</td><td>Graduated</td><td>Incubating</td></tr></tbody></table><hr><h2 id="when-to-choose-flux">When to Choose Flux</h2><ul><li>Platform engineering teams managing many clusters/tenants</li><li>Security-first environments — Flux’s simpler architecture has smaller attack surface</li><li>“Kubernetes all the way down” shops that want everything as CRDs</li><li>Progressive delivery with Flagger integration</li><li>Limited UI requirement — your team is comfortable in CLI + kubectl</li></ul><h2 id="when-to-choose-argocd">When to Choose ArgoCD</h2><ul><li>Developer-facing deployments where app teams need visibility and self-service</li><li>Organizations with mixed technical levels — the UI makes state accessible to non-SREs</li><li>Complex deployment workflows — sync waves, resource hooks, pre/post jobs</li><li>ApplicationSet-heavy architectures — templated fleet deployments</li><li>Existing ArgoCD investment — the ecosystem and expertise are deep</li></ul><hr><h2 id="using-both">Using Both</h2>It’s not unusual to run Flux and ArgoCD together:<ul><li>Flux for platform-layer resources (operators, CRDs, infra components)</li><li>ArgoCD for application-layer deployments (where devs need visibility)</li></ul>This is actually the model some mature platform teams have converged on. Flux’s composability makes it excellent for “infrastructure GitOps”; ArgoCD’s UX makes it excellent for “application GitOps.”<hr><h2 id="progressive-delivery-the-next-layer">Progressive Delivery: The Next Layer</h2>Both tools integrate with progressive delivery controllers:<img src="https://images.unsplash.com/photo-1513506003901-1e6a35f5ece5?w=800" alt="Pipeline and deployment flow visualization"> Photo by imgix on UnsplashFlagger (Flux ecosystem): automated canary deployments, blue/green, A/B testing via traffic shifting (works with Istio, Linkerd, NGINX, Traefik)Argo Rollouts (ArgoCD ecosystem): canary + blue/green with analysis-based promotion, deep UI integrationBoth are excellent. Choose based on which ecosystem you’re already in.<hr><h2 id="practical-getting-started">Practical Getting Started</h2>Flux:<div><pre><code># Install Flux CLI
brew install fluxcd/tap/flux

# Bootstrap to GitHub
flux bootstrap github \
 --owner=myorg \
 --repository=fleet-infra \
 --branch=main \
 --path=./clusters/production
</code></pre></div>ArgoCD:<div><pre><code># Install ArgoCD
kubectl create namespace argocd
kubectl apply -n argocd \
 -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# Access the UI
kubectl port-forward svc/argocd-server -n argocd 8080:443
</code></pre></div>Both are approachable. Flux has more initial CLI surface to learn; ArgoCD gets you to a working UI faster.<hr><h2 id="the-bottom-line">The Bottom Line</h2>If you’re starting a GitOps journey today, ArgoCD is the faster path to team adoption — the UI makes the value proposition immediately visible.If you’re building a multi-tenant platform and want the most operationally clean, Kubernetes-native approach, Flux is the better long-term foundation.Either way: get off imperative kubectl. The benefits of GitOps — audit trail, rollback, drift detection, environment parity — are real and worth the initial investment.<hr><h2 id="resources">Resources</h2><ul><li><a href="https://fluxcd.io/flux/">Flux Documentation</a></li><li><a href="https://argo-cd.readthedocs.io/">ArgoCD Documentation</a></li><li><a href="https://opengitops.dev/">OpenGitOps Principles</a></li><li><a href="https://flagger.app/">Flagger Progressive Delivery</a></li><li><a href="https://argoproj.github.io/rollouts/">Argo Rollouts</a></li><li><a href="https://kargo.io/">Kargo — Multi-stage promotion</a></li></ul> <div>이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :) </div></div></div>

Dev Note

GitOps has crossed the chasm. What started as a blog post from Weaveworks in 2017 is now the default CD model for Kubernetes-native organizations. The Git repository is the source of truth. The cluster reconciles itself to match. Humans don’t kubectl apply in production.
In this world, the two dominant tools are Flux (v2) and ArgoCD. They solve the same fundamental problem with very different philosophies. Choosing between them — or knowing when to use both — is a meaningful architectural decision.
Photo by Yancy Min on Unsplash
What GitOps Actually Means
Before the tools: a quick grounding. GitOps has four principles (per OpenGitOps):
Declarative — the desired state of the system is described declaratively
Versioned and immutable — the desired state is stored in a system that enforces immutability and retains complete version history
Pulled automatically — software agents automatically pull the desired state declarations from the source
Continuously reconciled — software agents continuously observe actual system state and attempt to apply the desired state
Both Flux and ArgoCD implement all four. The differences are in UX, operational model, and architectural assumptions.
Flux v2 — The Kubernetes Native Approach
Flux v2 (the Flux project under CNCF) was a complete rewrite of the original Flux. It’s built around a toolkit of composable controllers:
source-controller — watches Git/Helm/OCI repositories
kustomize-controller — applies kustomize overlays
helm-controller — manages Helm releases
notification-controller — sends alerts, receives webhooks
image-automation-controller — updates image tags in Git
Each controller is a standalone Kubernetes CRD + controller. You compose them.
Flux Architecture
Git Repository
      ↓ (poll/webhook)
source-controller (GitRepository CRD)
      ↓
kustomize-controller (Kustomization CRD)
      ↓
Kubernetes API
Flux runs entirely in your cluster. There’s no separate UI service or central control plane. Everything is Kubernetes-native: kubectl get gitrepositories, flux get all.
Flux Sample Configuration
# GitRepository - where Flux watches
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: my-app
  namespace: flux-system
spec:
  interval: 1m
  url: https://github.com/myorg/my-app
  ref:
    branch: main
---
# Kustomization - what to apply
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: my-app
  namespace: flux-system
spec:
  interval: 10m
  path: ./deploy/production
  prune: true
  sourceRef:
    kind: GitRepository
    name: my-app
  healthChecks:
    - apiVersion: apps/v1
      kind: Deployment
      name: my-app
      namespace: default
Flux Strengths
Fully Kubernetes-native — no external services, CRD-everything
Multi-tenancy — designed for platform teams managing many teams/clusters
GitOps toolkit composability — use only what you need
Flux image automation — automatically opens PRs when new image tags appear
Excellent Helm support — HelmRelease CRD is first-class
CNCF Graduated — proven production maturity
OCI support — pull Helm charts and manifests from OCI registries
Flux Weaknesses
No built-in UI — you need to add Weave GitOps or build your own
CLI learning curve — the flux CLI is powerful but non-trivial
Less visible for developers — harder for app teams to see deployment state without tooling investment
ArgoCD — The Visibility-First Approach
ArgoCD was built with a strong emphasis on visibility and developer self-service. The UI is not an afterthought — it’s a core product. Developers can see exactly what’s deployed, what’s drifted, and why a sync failed.
ArgoCD Architecture
Git Repository
      ↓ (poll/webhook)
ArgoCD Application Controller
      ↓
ArgoCD API Server → UI + CLI
      ↓
Kubernetes API
ArgoCD has more components: an application controller, an API server, a repository server, and the web UI. This is a larger operational surface but provides much richer out-of-the-box experience.
ArgoCD Sample Configuration
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/myorg/my-app
    targetRevision: main
    path: deploy/production
  destination:
    server: https://kubernetes.default.svc
    namespace: default
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
  ignoreDifferences:
    - group: apps
      kind: Deployment
      jsonPointers:
        - /spec/replicas  # Managed by HPA, ignore
ArgoCD Strengths
Best-in-class UI — visual diff, sync status, health, logs — all in one place
App of Apps pattern — manage hundreds of apps with a single parent app
ApplicationSets — templated multi-cluster, multi-tenant deployments
Strong RBAC — fine-grained access control for teams
Rollback in the UI — non-technical users can trigger rollbacks
Sync waves and hooks — sophisticated ordering of multi-resource deployments
Large ecosystem — Notifications, ApplicationSets, Image Updater plugins
ArgoCD Weaknesses
Not purely pull-based — ArgoCD server is stateful and needs to be managed
Multi-cluster complexity — managing many clusters requires careful argocd server placement
Heavier footprint — more components to run and upgrade
Git repo credentials — managing secrets for private repos is more involved
Side-by-Side Comparison
Dimension
      Flux v2
      ArgoCD
    
UI
      Optional (Weave GitOps)
      Built-in, excellent
    
Architecture
      Pure Kubernetes CRDs
      API server + controllers
    
Multi-tenancy
      First-class, built-in
      Via Projects + RBAC
    
Multi-cluster
      Hub-spoke via cluster secrets
      Central Argo server manages all
    
Helm support
      HelmRelease CRD (excellent)
      Native (excellent)
    
Kustomize support
      Native (kustomize-controller)
      Native
    
OCI registry support
      Yes (source-controller)
      Yes (with plugins)
    
Image auto-update
      image-automation-controller
      ArgoCD Image Updater (separate install)
    
Developer self-service
      Requires investment
      High out of the box
    
Operational complexity
      Lower
      Higher
    
CNCF status
      Graduated
      Incubating
    
When to Choose Flux
Platform engineering teams managing many clusters/tenants
Security-first environments — Flux’s simpler architecture has smaller attack surface
“Kubernetes all the way down” shops that want everything as CRDs
Progressive delivery with Flagger integration
Limited UI requirement — your team is comfortable in CLI + kubectl
When to Choose ArgoCD
Developer-facing deployments where app teams need visibility and self-service
Organizations with mixed technical levels — the UI makes state accessible to non-SREs
Complex deployment workflows — sync waves, resource hooks, pre/post jobs
ApplicationSet-heavy architectures — templated fleet deployments
Existing ArgoCD investment — the ecosystem and expertise are deep
Using Both
It’s not unusual to run Flux and ArgoCD together:
Flux for platform-layer resources (operators, CRDs, infra components)
ArgoCD for application-layer deployments (where devs need visibility)
This is actually the model some mature platform teams have converged on. Flux’s composability makes it excellent for “infrastructure GitOps”; ArgoCD’s UX makes it excellent for “application GitOps.”
Progressive Delivery: The Next Layer
Both tools integrate with progressive delivery controllers:
Photo by imgix on Unsplash
Flagger (Flux ecosystem): automated canary deployments, blue/green, A/B testing via traffic shifting (works with Istio, Linkerd, NGINX, Traefik)
Argo Rollouts (ArgoCD ecosystem): canary + blue/green with analysis-based promotion, deep UI integration
Both are excellent. Choose based on which ecosystem you’re already in.
Practical Getting Started
Flux:
# Install Flux CLI
brew install fluxcd/tap/flux
# Bootstrap to GitHub
flux bootstrap github \
  --owner=myorg \
  --repository=fleet-infra \
  --branch=main \
  --path=./clusters/production
ArgoCD:
# Install ArgoCD
kubectl create namespace argocd
kubectl apply -n argocd \
  -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
# Access the UI
kubectl port-forward svc/argocd-server -n argocd 8080:443
Both are approachable. Flux has more initial CLI surface to learn; ArgoCD gets you to a working UI faster.
The Bottom Line
If you’re starting a GitOps journey today, ArgoCD is the faster path to team adoption — the UI makes the value proposition immediately visible.
If you’re building a multi-tenant platform and want the most operationally clean, Kubernetes-native approach, Flux is the better long-term foundation.
Either way: get off imperative kubectl. The benefits of GitOps — audit trail, rollback, drift detection, environment parity — are real and worth the initial investment.
Resources
Flux Documentation
ArgoCD Documentation
OpenGitOps Principles
Flagger Progressive Delivery
Argo Rollouts
Kargo — Multi-stage promotion

GitOps in 2026: Flux vs ArgoCD — Choosing the Right Continuous Delivery Engine

댓글