Skip to content

CI/CD

Domain summary

Continuous delivery for Kubernetes with GitOps: a controller keeps clusters converged on the desired state stored in Git (or OCI artifacts), while a separate CI system builds and publishes artifacts. The domain covers the two CNCF-graduated GitOps engines. Argo CD 3.5.3 (2026-09-14) is a centralized hub with a rich web UI, sync waves and ApplicationSets, plus the pre-GA pull-based Argo CD Agent. Flux v2.9.5 (2026-08-31) is a set of per-cluster, pull-based controllers with built-in image automation. Both are Apache-2.0 and both render Helm 4 charts (Argo CD since 3.5, Flux since 2.8).

← Knowledge Base

Topics

Topic What it is Current version (checked 2026-09-25) License
Argo CD Declarative GitOps CD for Kubernetes: hub-and-spoke controller with web UI, SSO/RBAC via AppProjects, sync phases/waves/hooks, ApplicationSets, Source Hydrator (beta). CNCF Graduated (Argo project, 2022-12-06) 3.5.3 (2026-09-14); 3.6 in RC, GA planned 2026-11-03 Apache-2.0
FluxCD Decentralized GitOps Toolkit: independent source, kustomize, helm, notification and image-automation controllers running in each cluster. CNCF Graduated (2022-11-30) v2.9.5 (2026-08-31) Apache-2.0 (Flux Operator: AGPL-3.0)

How the Domain Fits Together

The map shows the usual split: CI builds and publishes artifacts, then either Argo CD (from a hub, or through the Agent) or Flux (inside each cluster) pulls the desired state and reconciles it. Progressive delivery sits on top.

flowchart LR
    CI["CI system<br/>(GitHub Actions, GitLab CI, Tekton)"] -->|"push image / chart / OCI artifact"| REG[("Container and OCI registry")]
    CI -->|"bump tag in manifests"| GIT[("Git repository")]
    subgraph ARGO["Argo CD (management cluster)"]
        AHUB["application-controller<br/>+ repo-server"]
        APS["ApplicationSet controller"]
    end
    subgraph SPOKE["Workload cluster"]
        AGENT["argocd-agent<br/>(pull-based, pre-GA)"]
        FLUX["Flux controllers<br/>(source, kustomize, helm)"]
        IMG["Flux image-reflector +<br/>image-automation"]
        PD["Argo Rollouts / Flagger<br/>(progressive delivery)"]
    end
    GIT --> AHUB
    REG --> AHUB
    APS --> AHUB
    AHUB -->|"classic: watch + apply"| SPOKE
    AGENT -->|"outbound gRPC + mTLS"| AHUB
    GIT --> FLUX
    REG --> FLUX
    IMG -->|"commit new tags"| GIT

Comparisons

Comparison Scope
GitOps Comparison: Argo CD vs Flux Architecture (hub vs per-cluster, Argo CD Agent), UI, rendering, sync ordering, fleet templating, multi-tenancy, footprint, and a decision flowchart

All comparison notes are listed in the comparisons index.

When to Use Which

These rules match the decision flowchart in the GitOps comparison.

Need Reach for
Central platform team, many clusters, one UI with SSO-scoped RBAC Argo CD
Ordered syncs with hooks (DB migrations, smoke tests, pre-delete jobs) Argo CD (sync phases, waves, hooks)
No inbound access from a hub to cluster APIs, edge or air-gapped sites Flux, or Argo CD with the Agent if pre-GA status is acceptable
Automatic image tag updates written back to Git Flux (built-in image automation); Argo CD needs Argo CD Image Updater or CI
Smallest per-cluster footprint, Kubernetes RBAC as the only authorization model Flux
Jsonnet or Config Management Plugins Argo CD
Rendered manifests committed to Git before deploy Argo CD Source Hydrator (beta in 3.5)

Landscape

CD for Kubernetes has moved from imperative push pipelines (CI runs kubectl apply or helm upgrade) to declarative pull-based GitOps, where the desired state is versioned and a reconciliation agent converges the cluster on it. The OpenGitOps project of the CNCF GitOps Working Group published vendor-neutral principles (v1.0.0, November 2021) that both Argo CD and Flux implement.

The two engines have been converging on each other's strengths. Argo CD, traditionally a push-from-hub design, is adding the pull-based Argo CD Agent (argoproj-labs, working toward GA). Flux, traditionally UI-less, now has the Flux Operator Web UI (ControlPlane, AGPL-3.0), and the Operator's ResourceSets cover fleet and preview-environment templating similar to ApplicationSets. Flux continued under CNCF governance after its original sponsor Weaveworks shut down in February 2024.

Progressive delivery (canary, blue-green, analysis-driven promotion) is handled by companion projects: Argo Rollouts for Argo CD users and Flagger in the Flux ecosystem. Both can route traffic through service meshes, ingress controllers, and the Kubernetes Gateway API.

Platform engineering

CD is often one capability inside an Internal Developer Platform (IDP) such as Backstage or Port. Developers use golden paths, while the platform team owns the Argo CD or Flux installation.

Push and pull are usually combined: CI (GitHub Actions, GitLab CI, Tekton) builds and signs artifacts and pushes them to a registry, then the GitOps controller pulls the updated manifests. Supply-chain controls are increasingly part of the delivery path: Flux verifies Cosign or Notation signatures on OCI artifacts, and Argo CD 3.5 added Source Integrity (Git commit signature verification per AppProject).

Key Concepts

GitOps

GitOps keeps the desired state of the system versioned in Git (or an OCI registry) and lets automated agents reconcile live infrastructure to match it. The four OpenGitOps principles are: declarative, versioned and immutable, pulled automatically, and continuously reconciled. Argo CD models deployments as Application objects managed by a central controller. Flux composes decoupled controllers through GitRepository/OCIRepository sources and Kustomization/HelmRelease appliers.

Reconciliation Loop

A continuous loop that fetches the source, renders manifests (Helm, Kustomize), diffs against live state, applies changes, and reports status. The defaults differ:

  • Argo CD refreshes every Application on timeout.reconciliation, 180s (3m) by default, and watches live cluster state continuously, so manual drift shows up as OutOfSync without waiting for the timer (Argo CD reference).
  • Flux has no default interval: spec.interval is required on every object. The docs recommend 1m for a GitRepository and 60m for a Kustomization, because a new source revision triggers the Kustomization immediately (Flux explanation).

Both accept Git or registry webhooks (Argo CD's webhook endpoint, Flux Receiver objects) to reconcile right after a push.

Drift Detection

Drift is any difference between live state and the declared state: kubectl edit, autoscalers changing replicas, webhooks injecting sidecars, other operators. Argo CD shows drift as OutOfSync and corrects it when auto-sync with self-heal is enabled. Flux's kustomize-controller re-applies with server-side apply on every interval; HelmRelease drift correction is opt-in (spec.driftDetection). Flux notification-controller and Argo CD notifications can alert on drift and failures (Slack, Microsoft Teams, Git commit status, webhooks).

Fields owned by other controllers

To avoid a tug-of-war with HPAs, service meshes and mutating webhooks, exclude those fields: ignoreDifferences (for example managedFieldsManagers) in Argo CD, and Kustomization.spec.ignore rules (Flux 2.9+) or HelmRelease.spec.driftDetection.ignore in Flux.

Sync Ordering

Argo CD orders a sync with phases (PreSync, Sync, PostSync, SyncFail, PreDelete, PostDelete) and numeric sync waves. Flux has no waves; it orders work with dependsOn between Kustomizations or HelmReleases, which waits for upstream objects to be Ready (custom CEL readyExpr since 2.7), plus health checks and SSA apply stages.

Progressive Delivery

Deployment strategies that shift traffic gradually while automated analysis checks health:

  • Argo Rollouts: traffic routing through service meshes and ingress controllers, and the Kubernetes Gateway API through the argoproj-labs Gateway API plugin; analysis via AnalysisTemplates (Prometheus, Datadog, webhooks).
  • Flagger: works with Istio, Linkerd, Contour, Gloo and the Gateway API; analysis via built-in and custom metric templates.

Multi-Tenancy

Argo CD isolates tenants with AppProjects (allowed sources, destinations and kinds) plus Argo CD RBAC over SSO groups, and since 3.5 can run syncs as per-destination service accounts (impersonation, beta). Flux relies on Kubernetes RBAC and service-account impersonation, hardened with --no-cross-namespace-refs and --default-service-account. In both, a mistake in tenant configuration can let one team deploy into another team's namespaces, so treat these settings as security controls.

Sources

Open Questions

  • When will the Argo CD Agent reach GA, and will it move from argoproj-labs into the core project? That determines whether "pull-based" still separates the two engines.
  • As fleets grow to hundreds of clusters, where is the practical limit of pull-based reconciliation latency, and when does a hybrid push+pull model pay off for time-sensitive deployments?
  • Will CI and CD keep converging (Flux OCI artifacts as the delivery format, Argo CD Source Hydrator committing rendered manifests), and does that shrink the role of general-purpose CI systems in deployment?