From “Works on My Machine” to Declarative Truth
The central problem GitOps solves isn’t deployment speed — it’s drift. Without GitOps, your production environment is a snowflake: a product of every kubectl apply, every ad hoc Helm upgrade, every emergency patch applied directly to a running cluster. Over time, nobody can tell you with confidence exactly what is deployed and why.
GitOps replaces this with a simple contract: Git is the single source of truth for the desired state of your infrastructure. The cluster continuously reconciles itself toward whatever is declared in your repository. Any deviation — whether from a manual change, a node replacement, or a misconfigured controller — is automatically corrected.
By 2026, GitOps has moved from early adopter to standard practice. The CNCF’s annual survey consistently shows ArgoCD and Flux as the two dominant implementations, both now stable CNCF graduated projects. If you’re running Kubernetes and not using GitOps, you’re swimming against the current.
ArgoCD vs. Flux: The Honest Comparison
Both tools implement the GitOps pattern. The choice is mostly about architecture philosophy and team workflow preference.
ArgoCD
ArgoCD is UI-first. It ships with a rich web dashboard that shows every application’s sync status, resource tree, and deployment history. For teams that want visual observability into what’s deployed where, ArgoCD is the clear winner.
Key characteristics:
-
Application abstraction — ArgoCD introduces an
ApplicationCRD that maps a Git source to a cluster destination. One Application per microservice is the natural pattern. - App of Apps pattern — an ArgoCD Application can deploy other Applications, enabling hierarchical management of many services from a single root.
- SSO and RBAC out of the box — ArgoCD includes multi-tenant RBAC with SSO integration, making it easier to manage access for larger teams.
- Push model feel — while ArgoCD is technically pull-based (the controller runs in-cluster), it behaves like a push system with its app-centric model.
Best for: Teams that want a UI, multi-tenant setups, and application-level granularity.
Flux
Flux is API-first. There’s no built-in dashboard — Flux exposes its state via Kubernetes custom resources, and you bring your own observability (Grafana dashboards, the Flux CLI). This makes it more opinionated toward infrastructure-as-code purists and platform teams managing clusters programmatically.
Key characteristics:
- Multi-source reconciliation — Flux can pull from Git, Helm repositories, and OCI registries simultaneously, making it flexible for complex dependency graphs.
- Image automation — Flux’s image automation controller can automatically update Kubernetes manifests when new container images are pushed, closing the loop on CI → GitOps.
-
Bootstrap-first —
flux bootstrapconfigures a cluster to reconcile itself from a Git repository in a single command, with Flux’s own manifests stored in the same repo. - CRD-native — everything Flux does is expressed as Kubernetes custom resources (GitRepository, HelmRelease, Kustomization), making it fully scriptable and auditable.
Best for: Platform engineering teams, multi-cluster setups, and environments where GitOps config is managed programmatically.
See the IAN team run on your cloud. We connect to your AWS account via a scoped read-only role, run the Observe-tier agents, and leave you with a concrete audit report — cost waste, security exposure, compliance gaps, and a labor-offset estimate. You keep the findings regardless of next steps. Get a free infrastructure audit →
Structuring Your GitOps Repository
How you structure the Git repository is as important as which tool you pick. The most common patterns:
Monorepo (All Clusters, All Apps)
gitops/
├── clusters/
│ ├── production/
│ │ ├── apps/ # App-specific manifests
│ │ └── infrastructure/ # Cluster-level config (ingress, cert-manager)
│ └── staging/
│ ├── apps/
│ └── infrastructure/
└── base/ # Shared base manifests (Kustomize bases)
Pros: Atomic changes across environments. Easy to see what’s different between staging and production. One PR can promote a change through all environments.
Cons: Repository grows large. Teams can accidentally see (or modify) each other’s config without proper branch protection.
Per-Environment Repositories
Separate repositories for production, staging, and development. CI writes to the target environment’s repository when promoting changes.
Pros: Strict access control — production repo requires elevated permissions. Clean separation of concerns.
Cons: Cross-environment changes require coordinating multiple PRs. Harder to track the promotion path of a change.
Most teams land on monorepo with branch protection for simplicity, using Kustomize overlays to manage per-environment differences.
Implementing Environment Promotion
The GitOps promotion pattern: developers merge code to the app repository, CI builds and pushes a new image, then updates the GitOps repository with the new image digest. The GitOps controller detects the change and deploys.
# GitHub Actions: promote to staging after successful build
- name: Update staging image digest
run: |
cd gitops
# Update the image tag in the staging overlay
sed -i "s|image: myapp:.*|image: myapp:${{ github.sha }}|" clusters/staging/apps/myapp/deployment.yaml
git config user.name "github-actions[bot]"
git config user.email "github-actions[bot]@users.noreply.github.com"
git add .
git commit -m "chore: promote myapp to staging @ ${{ github.sha }}"
git push
For production promotion, require a PR review before merging the image update. This gives you a human gate on production changes without blocking staging.
GitOps Security Pitfalls
Overpermissioned Cluster Access
ArgoCD and Flux need read/write access to the cluster. By default, both tools install with cluster-admin permissions — which is more than they need. Scope their permissions to the namespaces they manage.
# Flux: restrict to specific namespaces with namespace-scoped ServiceAccount
apiVersion: v1
kind: ServiceAccount
metadata:
name: flux-reconciler
namespace: flux-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: flux-reconciler
namespace: production
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin # Scope to production namespace only
subjects:
- kind: ServiceAccount
name: flux-reconciler
namespace: flux-system
Secrets in Git
Never commit raw secrets to the GitOps repository. Use sealed secrets (Bitnami Sealed Secrets), External Secrets Operator (pulling from Vault/AWS Secrets Manager), or SOPS-encrypted secrets. All of these integrate natively with both ArgoCD and Flux.
Unsigned Commits
Anyone with write access to the GitOps repository can trigger a production deployment. Require signed commits on the GitOps repository and configure your GitOps controller to verify signatures before applying changes.
Drift Detection and Compliance
One of the underappreciated benefits of GitOps: automatic drift detection is a compliance feature. When your GitOps controller reports “out of sync,” you have evidence that the actual cluster state doesn’t match declared intent — and the tooling to remediate it.
For audit purposes:
- Every production change has a corresponding Git commit, with author, timestamp, and PR reference
- Drift is automatically detected and optionally auto-remediated
- The full deployment history is queryable from Git log — no more “who deployed what when?”
How IAN Integrates With Your GitOps Pipeline
IAN connects to the repositories driving your GitOps deployments to provide continuous security and cost analysis:
- IaC scanning on every PR — every change to the GitOps repository is scanned for misconfigurations, exposed secrets, and overpermissioned resources before it merges
- Drift alerting — IAN monitors for ArgoCD/Flux out-of-sync states and correlates them with security findings
- Deployment cost attribution — manifest changes are correlated with cloud cost changes to identify which GitOps deployments introduced cost anomalies
- Auto-remediation PRs — security findings generate fix PRs directly to the GitOps repository, so remediation flows through the same review process as any other change
GitOps makes your deployment process auditable. IAN makes it secure.
Start Your GitOps Migration
The most pragmatic starting point: pick one non-critical service, create a GitOps repository, and deploy ArgoCD or Flux. Get one application reconciling from Git before expanding to the rest of the cluster.
Next step: talk to the team
30 minutes. We'll look at your cloud together and scope what we'd take off your plate — see pricing.