GitOps in Practice: ArgoCD vs Flux — What to Choose in 2026
GitOps is not just a buzzword. It's an operational model where Git is the single source of truth for infrastructure and application state. ArgoCD and Flux are the two main tools for implementing this approach. We use both in production and will explain when to choose which.
What is GitOps and Why It Matters
The traditional deployment approach: a developer runs kubectl apply or helm upgrade manually, or through a CI pipeline with direct cluster access. The problem — cluster state diverges from what's in the repository. Someone applied a hotfix manually, someone changed a ConfigMap directly. After a month, nobody knows what's actually running.
GitOps solves this through a pull model: a dedicated operator inside the cluster continuously compares desired state (Git) with actual state (cluster) and automatically synchronizes them. No direct cluster access from CI is needed — this improves security and reproducibility.
ArgoCD: Powerful UI and Rich Ecosystem
ArgoCD is a declarative GitOps tool for Kubernetes with a rich web UI. It shows a real-time resource graph of the application: which pods are running, which deployments are synced, where there are drifts. This makes it especially convenient for teams just starting with GitOps.
- ·Visual UI with resource graph
- ·Multi-tenancy out of the box
- ·Application-level RBAC
- ·Helm, Kustomize, Jsonnet support
- ·ApplicationSet for fleet management
- ·Rich REST API and CLI
- ·Requires more resources (~500MB RAM)
- ·Harder to configure without UI
- ·No built-in secrets management
- ·Less flexibility in automation
# ArgoCD Application manifest
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: infoscale-api
namespace: argocd
spec:
source:
repoURL: https://github.com/infoscale/k8s-manifests
targetRevision: HEAD
path: apps/api
destination:
server: https://kubernetes.default.svc
namespace: production
syncPolicy:
automated:
prune: true
selfHeal: true
Flux: Kubernetes-native and Maximum Automation
Flux v2 is a set of Kubernetes controllers (GitRepository, Kustomization, HelmRelease) that work as regular CRDs. There's no separate server — only operators in the cluster. This makes Flux more 'native' to Kubernetes and easier to automate through a GitOps approach to Flux itself.
- ·Minimal footprint (~150MB RAM)
- ·Built-in SOPS/Sealed Secrets integration
- ·Image automation (auto-tag updates)
- ·CLI bootstrapping (flux bootstrap)
- ·Ideal for multi-cluster fleet
- ·Native Helm OCI integration
- ·No built-in UI (need Weave GitOps)
- ·Harder for beginners without UI
- ·Fewer multi-tenancy capabilities
- ·Debugging via kubectl, not browser
# Flux HelmRelease manifest
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
name: infoscale-api
namespace: production
spec:
interval: 5m
chart:
spec:
chart: ./charts/api
sourceRef:
kind: GitRepository
name: infoscale-k8s
values:
image.tag: "1.4.2"
ArgoCD vs Flux Comparison
| Parameter | ArgoCD | Flux v2 |
|---|---|---|
| Web UI | ✅ Built-in, feature-rich | ❌ None (need Weave GitOps) |
| Resource usage | ~500MB RAM | ~150MB RAM |
| Secrets management | ❌ External solutions | ✅ SOPS, Sealed Secrets |
| Image automation | ⚠️ Via ArgoCD Image Updater | ✅ Built-in |
| Multi-tenancy | ✅ Excellent | ⚠️ Limited |
| Kubernetes-native | ⚠️ Partial | ✅ Fully CRD-based |
| Learning curve | Low (has UI) | Medium (CLI only) |
| CNCF status | Graduated | Graduated |
| License | Apache 2.0 | Apache 2.0 |
When to Choose What
ArgoCD
- Team is just starting with GitOps
- Need cluster state visualization
- Many teams in one cluster (multi-tenancy)
- Detailed per-application RBAC needed
- Integration with external CD systems matters
Flux v2
- Maximum update automation needed
- Secrets security matters (SOPS)
- Managing a fleet of 10+ clusters
- Team is comfortable with kubectl and CLI
- Minimal cluster overhead needed
What We Use at InfoScale
We use both tools — depending on the project context. For clients who are just adopting GitOps and want to see what's happening in the cluster, we deploy ArgoCD. The visual resource graph lowers the barrier to entry and speeds up team onboarding.
For mature teams with multiple clusters and secrets security requirements, we choose Flux. The built-in SOPS support is especially valuable: secrets are encrypted directly in Git, no external vault systems needed for basic scenarios.
Real case: fintech startup, 3 clusters
The client came with ArgoCD on a single cluster. When expanding to staging and production in two regions, we migrated to Flux with an ApplicationSets-like structure via Kustomize overlays. Change synchronization time dropped from 3 minutes to 45 seconds, and SOPS-based secrets management eliminated the need for a separate Vault cluster.
Common GitOps Implementation Mistakes
⚠️ Storing secrets in Git in plaintext
The most common beginner mistake. Use SOPS with age keys (Flux) or External Secrets Operator (ArgoCD + Vault/AWS SSM).
⚠️ Mixing application code and infrastructure manifests in one repo
Separate app-repo (code) and config-repo (manifests). This allows independent versioning of deployments and simplifies change auditing.
⚠️ Disabling selfHeal in production
selfHeal is the essence of GitOps. Without it, manual cluster changes aren't reverted, and state diverges from Git. Always enable it, except during active debugging.
⚠️ Not configuring notifications
Both ArgoCD and Flux support Slack/Telegram notifications about sync status. Without this, you only learn about problems when something breaks.
Conclusion
ArgoCD and Flux are both excellent tools, both CNCF Graduated. ArgoCD wins on UX and multi-tenancy, Flux wins on automation, secrets security, and minimal footprint. For most new projects, we recommend starting with ArgoCD, and when the fleet grows or automation requirements increase — consider Flux or a hybrid approach.
Need Help with GitOps?
We'll set up ArgoCD or Flux for your cluster, train your team, and hand over the runbook.
Contact Us