GitOps chaos: did ArgoCD or Flux sink your deploy?

GitOps 2026 ArgoCD vs Flux comparison trade-offs - Meu Universo Nerd

It was 11am on a Friday when the platform team realized ArgoCD was reconciling an incorrect state. Nobody knew where the change came from. Nobody could trace who approved the PR. The production cluster was in a different state than what Git said it should be, and the "single source of truth" had become a source of confusion.

If you use GitOps without understanding the philosophy behind the tool you chose, you are managing chaos with a pretty interface. In this article you will understand the real difference between ArgoCD 3.3 and Flux 2.8 in 2026, when to use each one, and how to avoid the main mistake platform teams make when adopting GitOps.

GitOps is not just "put everything in Git"

Before comparing the tools, it is important to clarify what GitOps actually is. The official OpenGitOps Working Group definition has 4 principles: Declarative state, Versioned and immutable, Pulled automatically by software agents, and Continuously reconciled.

The point most teams skip is the third one: pulled automatically. GitOps is not you running kubectl apply from a CI pipeline. That is classic CI/CD with manifests in Git. Real GitOps means the cluster itself pulls the changes and applies them autonomously.

The philosophical difference nobody explains properly

ArgoCD is centralized. You have one ArgoCD instance managing multiple clusters. One dashboard. One API. One control point. Think hub-and-spoke: ArgoCD at the center, clusters at the edge.

Flux is decentralized. You install Flux inside each cluster. Each cluster is autonomous: it pulls state from Git and reconciles itself. No central instance. No native rich dashboard. Each cluster takes care of itself.

This difference changes everything: governance, blast radius on failure, visibility, and scalability. It is not about which tool is "better" in absolute terms. It is about which operational model fits your team.

ArgoCD 3.3 vs Flux 2.8: when to use each

# ArgoCD Application example
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-api-production
  namespace: argocd
spec:
  source:
    repoURL: https://github.com/myorg/k8s-manifests.git
    targetRevision: main
    path: apps/my-api/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: my-api
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

# Flux Kustomization example
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: my-api-production
  namespace: flux-system
spec:
  interval: 5m
  sourceRef:
    kind: GitRepository
    name: k8s-manifests
  path: ./apps/my-api/overlays/production
  prune: true

The mistake that caused the Friday incident

# Dangerous: ApplicationSet with glob auto-discovery
generators:
  - git:
      directories:
        - path: apps/*  # ANY new folder becomes an Application

# Safe: explicit list
generators:
  - list:
      elements:
        - app: my-api
        - app: other-service

Takeaways

GitOps is not just CI/CD with Git: the cluster pulls and reconciles state automatically
ArgoCD is hub-and-spoke: great for centralized visibility, but creates a platform single point of failure
Flux is per-cluster: more resilient by design, but requires investment in your own observability stack
ApplicationSet glob: beware of auto-discovery by folder pattern in production

Are you already using GitOps in your stack? ArgoCD or Flux? What problem did you solve (or create) with it? Share in the comments.

Next week I will go deep into Flux Image Automation: how to configure Flux to automatically detect when a new container image is available in the registry and open a PR in Git with the update.

Home