GitOps Comparison: Argo CD vs Flux

2023-02-2129 minute read

GitOps is the practice of using Git as a single source of truth for declaratively specifying the desired state of infrastructure and applications. GitOps provides increased reliability and velocity, reduced downtime, and other advantages such as self-healing. Argo CD and Flux are the most popular options for GitOps continuous deployment.

Argo CD and Flux have been instrumental in the rise of GitOps and are a part of CNCF’s OpenGitOps initiative. In 2022, both tools reached the CNCF graduated status. In this blog, we will explore the difference between these tools and give you pointers on going about choosing between the two. We will also explore the community around these tools, some recent announcements, and their future roadmaps.

Fleet is a relatively new offering from Rancher with capabilities to manage fleets of Kubernetes clusters using GitOps practices.

Argo CD vs Flux

ArgoCD presents itself as an all-inclusive GitOps solution delivering a well-rounded GitOps experience with its diverse features, whereas Flux excels in offering adaptability and customization through its wide array of integrations and extensions.

Let’s look at each tool through these specific feature comparisons around these three themes.

  1. Ease of setup
  2. Ease of maintenance
  3. Capability

And we have also put a Pros and Cons table at the very end for quick reference.

If you’d like to skip the installation, click here.

For more tools, check out our popular GitOps Tools article. Find out about the fundamentals of GitOps here.


Argo CD

Argo CD can be set up using both CLI and UI. There is also an Argo CD core installation option that installs only the essential components and skips UI, SSO, etc. We will be using helm charts and argocd CLI to make the installation on a kubernetes cluster. For other installation methods, visit Argo CD docs.

If you prefer to set it up using Argo CD’s UI, follow this tutorial.

Pre-requisites: Helm, Kubectl installed

  1. Create a new namespace

    1kubectl create ns argocd

    This will create a new namespace, argocd, where Argo CD services and application resources will live. Here you can modify any custom values in values.yaml.

  2. Install Argo CD

    Add repository

    1helm repo add argo

    Install chart

    1helm install argocd argo/argo-cd --version 5.21.0 -n argocd

    An example of overrides to values.yaml look something like this:

    1    applicationSet:
    2        args:
    3            dryRun: false
    4            metricsAddr: ':8080'
    5            policy: sync
    6            probeBindAddr: ':8081'
    7    configs:
    8        cm:
    9            account.argonaut-admin: 'apiKey, login'
    10            account.argonaut-admin.enabled: true
    11            cluster.inClusterEnabled: true
    12    knownHosts:
    13            data:
    14            ssh_known_hosts: >
    15       ssh-rsa
    16                AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==
    18       ecdsa-sha2-nistp256
    19                AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBEmKSENjQEezOmxkZMy7opKgwFB9nkt5YRrYMjNuG5N87uRgg6CLrbo5wAdT/y6v0mKV0U2w0WZ2YB/++Tpockg=
    21       ssh-ed25519
    22                AAAAC3NzaC1lZDI1NTE5AAAAIOMqqnkVzrm0SdG6UOoqKLsabgH5C9okWi0dh2l9GKJl
    23    knownHostsAnnotations: {}
    24     policy.csv: |
    25        p, role:argonaut-readonly, applications, get, */*, allow
    26        p, role:argonaut-readonly, certificates, get, *, allow
    27        p, role:argonaut-readonly, clusters, get, *, allow
    28        p, role:argonaut-readonly, repositories, get, *, allow
    29        p, role:argonaut-readonly, projects, get, *, allow
    30        p, role:argonaut-readonly, accounts, get, *, allow
    31        p, role:argonaut-readonly, gpgkeys, get, *, allow
    32        p, role:argonaut-readonly, logs, get, */*, allow
    34        p, role:argonaut-admin, applications, create, */*, allow
    35        p, role:argonaut-admin, applications, update, */*, allow
    36        p, role:argonaut-admin, applications, delete, */*, allow
    37        p, role:argonaut-admin, applications, sync, */*, allow
    38        p, role:argonaut-admin, applications, override, */*, allow
    39        p, role:argonaut-admin, applications, action/*, */*, allow
    40        p, role:argonaut-admin, applicationsets, get, */*, allow
    41        p, role:argonaut-admin, applicationsets, create, */*, allow
    42        p, role:argonaut-admin, applicationsets, update, */*, allow
    43        p, role:argonaut-admin, applicationsets, delete, */*, allow
    44        p, role:argonaut-admin, certificates, create, *, allow
    45        p, role:argonaut-admin, certificates, update, *, allow
    46        p, role:argonaut-admin, certificates, delete, *, allow
    47        p, role:argonaut-admin, clusters, create, *, allow
    48        p, role:argonaut-admin, clusters, update, *, allow
    49        p, role:argonaut-admin, clusters, delete, *, allow
    50        p, role:argonaut-admin, repositories, create, *, allow
    51        p, role:argonaut-admin, repositories, update, *, allow
    52        p, role:argonaut-admin, repositories, delete, *, allow
    53        p, role:argonaut-admin, projects, create, *, allow
    54        p, role:argonaut-admin, projects, update, *, allow
    55        p, role:argonaut-admin, projects, delete, *, allow
    56        p, role:argonaut-admin, accounts, update, *, allow
    57        p, role:argonaut-admin, gpgkeys, create, *, allow
    58        p, role:argonaut-admin, gpgkeys, delete, *, allow
    59        p, role:argonaut-admin, exec, create, */*, allow
    61        g, role:argonaut-admin, role:argonaut-readonly
    62        g, argonaut-admin, role:argonaut-admin
    63    controller:
    64        clusterAdminAccess:
    65            enabled: true
    66        containerPort: 8082
    67    dex:
    68        containerPortGrpc: 5557
    69        containerPortHttp: 5556
    70        containerPortMetrics: 5558
    71    global:
    72        additionalLabels:
    73   acd-akwtupm4z47ag7r8
    74   ar2nsbcq25kwi63r
    75    redis:
    76        containerPort: 6379
    77    metrics:
    78        containerPort: 9121
    79        containerSecurityContext:
    80            allowPrivilegeEscalation: false
    81            capabilities:
    82                drop:
    83                    - ALL
    84            readOnlyRootFilesystem: true
    85            runAsNonRoot: true
    86            seccompProfile:
    87                type: RuntimeDefault
    88        image:
    89            imagePullPolicy: IfNotPresent
    90            repository:
    91            tag: 1.26.0-debian-10-r2
    92        resources: {}
    93    repoServer:
    94        clusterAdminAccess:
    95            enabled: false
    96        containerPort: 8081
    97    server:
    98        clusterAdminAccess:
    99            enabled: true
    100        containerPort: 8080
  3. Download the latest CLI version or use the following brew install command. Instructions for Windows users can be found here. (Optional - only needed if you’re interacting using CLI)

    1brew install argocd
  4. You can now access the Argo CD API server using load balancer, Ingress, or port forwarding. Shown below is the port-forwarding method.

    1kubectl port-forward svc/argocd-server -n argocd 8080:443

    The API server can then be accessed using https://localhost:8080

  5. Login using the Argo CD CLI

    The initial password is stored in the password field. Retrieve it by:

    argocd admin initial-password

    Alternatively, it can also be accessed by accessing the kubernetes secrets”

    1kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath='{.data.password}' | base64 -d

    Using the username admin and password from above, log in to Argo CD’s IP or hostname

    argocd login <ARGOCD_SERVER>

    Change the password using the following command:

    argocd account update-password

  6. We’ll deploy an app to the same cluster that Argo CD is running in. We’ll deploy using the CLI. To deploy to an external cluster, follow these commands. We’ll use the example repository containing a guestbook application.

    1. We need to set the current namespace to Argo CD by running the following command: kubectl config set-context --current --namespace=argocd
    2. Create the example guestbook application, set the destination, and with the following command:
      1argocd app create guestbook --repo --path guestbook --dest-server https://kubernetes.default.svc --dest-namespace default

    Created EKS cluster using Argonaut? Here is how you can access your EKS clusters from CLI.

  7. Deploy (Sync) the App

    You will get the following output once the app is created.

    1$ argocd app get guestbook
    2Name:               guestbook
    3Server:             https://kubernetes.default.svc
    4Namespace:          default
    8Path:               guestbook
    9Sync Policy:        <none>
    10Sync Status:        OutOfSync from  (1ff8a67)
    11Health Status:      Missing
    14apps   Deployment  default    guestbook-ui  OutOfSync  Missing
    15       Service     default    guestbook-ui  OutOfSync  Missing

    As you can see, the deployment status is OutOfSync since the app is yet to be deployed, and no k8s resources have been created. Run the following command to deploy.

    1argocd app sync guestbook

    This command retrieves the manifests from the repository and performs a kubectl apply of the manifests. The guestbook app is now running, and you can now view its resource components, logs, events, and assessed health status.


The installation in Flux terms is called as Flux Bootstrap. The Flux CLI binaries are available on all major platforms and can be downloaded from here. Below are the basic installation steps.

Requirements: Kubernetes v1.21 or higher

  1. Start with: brew install fluxcd/tap/flux

    This installs the Flux CLI on to your system.

  2. The flux bootstrap command creates a flux namespace on your Kubernetes cluster and configures it to manage itself from a Git repository. Connecting to other Git repositories like AWS CodeCommit, Azure DevOps, Bitbucket Server, GitHub, or GitLab. requires an Access Token. Find those instructions here. These Flux components are installed to your cluster in this step: helm-controller, kustomize-controller, notification-controller, and source-controller.

  3. The bootstrap git command takes an existing Git repository, clones it, and commits the Flux components manifests to the specified branch. Then it configures the target cluster to synchronize with that repository.

    Authenticating with your SSH agent. This command generates an SSH key and will prompt you to add the SSH public key as a deploy key to your repository.

    1flux bootstrap git \
    2  --url=ssh://git@<host>/<org>/<repository> \
    3  --branch=<my-branch> \
    4  --path=clusters/my-cluster
  4. If your Git server uses a self-signed TLS certificate, you can specify the CA file with --ca-file=<path/to/ca.crt>.

    With --path you can configure the directory, which will be used to reconcile the target cluster. To control multiple clusters from the same Git repository, you have to set a unique path per cluster e.g. clusters/staging and clusters/production:

    2├── staging *# <- path=clusters/staging*
    3│   └── flux-system *# <- namespace dir generated by bootstrap*
    4│       ├── gotk-components.yaml
    5│       ├── gotk-sync.yaml
    6│       └── kustomization.yaml
    7└── production *# <- path=clusters/production*
    8    └── flux-system
  5. After running bootstrap, you can place Kubernetes YAMLs inside a dir under path e.g. clusters/staging/my-app, and Flux will reconcile them on your cluster.

    For examples of how you can structure your Git repository, see:


Both tools have been instrumental in the rise of GitOps and can manage both application and infrastructure deployments.

Argo CD is a full-featured product for GitOps, while Flux is a GitOps toolkit. This makes the Argo project more capable and a well-rounded solution as a whole. Argo Project includes Argo CD, Argo Workflows, Argo Events, and Argo Rollouts.

Flux's mature system of integrations and extensions makes it a well-rounded solution. Along with its other benefits, it can be much more than a GitOps toolkit and might be the right solution for your GitOps workflows.

Source Tracking

Source tracking controls how changes are detected in the GitOps resource. Both Argo CD and Flux can be configured to track a branch, a tag pattern, or a fixed commit hash in git.

Application delivery

Argo CD supports both push and pull-based deployments. It supports several different Kubernetes manifest formats — helm charts, jsonnet, YAML, and customized applications.

Ability to add custom resource hooks that can trigger custom scripts or interact with external services at various stages of the Argo CD sync operation. Such as PreSync, Sync, PostSync, or when synchronization fails.

Flux’s pull-based model uses webhook receivers to make it as fast and responsive as push-based pipelines. Flux is designed to work with existing tools in mind. It’s GitOps Toolkit components include specialized tools and Flux Controllers, composable APIs, and reusable Go packages for GitOps under the fluxcd GitHub organisation.

Custom Resource Definitions (CRDs)

Argo CD offers mainly two major CRDs - Application and AppProject.

The Application CRD is a Kubernetes object representing an app instance. It has two parts: source (Git repo, revision, path, env) and destination (cluster or name, not both).

The AppProject CRD is a Kubernetes resource object that defines sourceRepos, destination clusters and namespaces, and roles for entities with access to the project, allowing for the logical grouping of applications.

Flux, on the other hand, offers separate CRDs for each concept like Kustomization (kustomize-controller), HelmRelease, HelmChart (helm-controller), HelmRepository, GitRepository (source-controller), Alert, Event (notification-controller), etc.

Flux’s implementation here offers a way cleaner and more flexible approach. Some differences can be seen in the way they handle secrets and ConfigMaps.

Reconciliation Configurability

Reconciliation or synchronization (sync) is the act of modifying the cluster state to match the description stored in git. Both tools support automatic reconciliation.

Argo CD

Argo CD offers global reconciliation settings that can be modified via a ConfigMap, with a default setting of three minutes. Reconciliation can be disabled globally or per application, but the reconciliation time can only be set globally.


Flux, built on the GitOps Toolkit, is a reconciliation loop that can be configured at a component level, which allows for staggered reconciliation, e.g: you check a git repository every five minutes and sync every 10 minutes.

Cluster drift reconciliation (self-heal)

Using GitOps and source tracking, the cluster configuration and its resources are automatically matched to the Git source. But what if someone makes a manual edit to a resource? Such as through kubectl. In such cases, cluster drift reconciliation can ensure that the cluster adheres to the declared state (eventually). Both Argo CD and Flux support this feature with caveats.

In Argo CD, it is available as an optional feature, which requires automatic sync to be enabled, and it disables rollbacks.

In Flux, it depends on the GitOps resource kind. For Kustomizations, cluster drift reconciliation is enabled by default. Whereas Flux does not support this feature for Helm releases at all.

Manual Sync

Argo CD - possible by specifying manual syncPolicy: {} on the Application GitOps resource.

Flux - Declaratively set suspend: true

1kubectl annotate --field-manager=flux-client-side-apply --overwrite \
2kustomization/podinfo"$(date +%s)"

Web UI

The Argo Project tools, including Argo CD, come with a web UI for ease of use and provide a visual understanding of the pipelines and workflows. Argo CD’s UI components can be found in this repo and can be extended using javascript extension files.

Flux has an API-led approach that enables multiple GUIs and relies on other open-source projects for its web UI. The two popular ones are Weaveworks GitOps and VS Code GitOps tools.

Garbage collection (Pruning)

The garbage collection is a process by which the Kubernetes objects previously applied on the cluster are missing from the current source revision and automatically removed from the cluster.

Both Argo CD and Flux have similar approaches to garbage collection.

In Argo CD,

Pruning can be set to happen automatically by running the argocd app set <APPNAME> --auto-prune command or by setting the prune option to true in the automated sync policy.

2  syncPolicy:
3    automated:
4      prune: true

In Flux,

To enable garbage collection, set spec.prune to true.

To disable the pruning of certain resources, annotate them with: disabled

💡 Kustomize is a CLI tool offering template-free, structured customization of declarative configuration targeted to k8s-style objects.

Secret Management

Argo CD allows plenty of flexibility when it comes to secret management. It works well with external secrets operators, sealed secrets, helm secrets, KSOPS, plugins, and more.

For those secret management solutions that use plugins to inject secrets into application manifests, check out these steps to mitigate the security risks of secret-injector plugins.

Flux also has several options for secret management. It has specific guides for sealed secrets, SOPS, secret decryption, and externally mounted CSI drivers.

It also has a list of considerations when it comes to secret management while using Flux.

💡 Want to learn more about these secret management approaches and tools? Check out our Kubernetes secret management blog.

Permissions and Access Control

Organizing your applications based on ownership can help simplify the permission setup. VCS-based permission management can be implemented, e.g. the code owners can be used to control write permissions based on globs within a mono repo. Assigning a different repo for each team can help them achieve greater confidentiality. The GitOps platform can offer additional features for access control.

In Argo CD, the AppProject is used to specify that an application belongs to a  project, which makes use of Argo CD’s own user management and permission system, enabling us to allow/deny

  • Access to sources
  • Deploying resource kinds
  • Access for users
  • Deploying to target clusters

Flux doesn’t offer its own user management as Argo CD does. Instead, platform administrators should use Kubernetes RBAC and policy-driven validation to establish security. Flux has a multi-component design and integrates with many other systems. Having different components and CRDs, such as git repositories, charts, notifications, etc, helps separate concerns and thus facilitates the setting up of fine-grained policies. Platform admins can enforce service account impersonation to minimize privileges. (source)

Multi-Cluster Deployment

Both platforms support syncing remote cluster targets.

Argo CD offers a dedicated ApplicationSet resource for templating Applications targeting multiple clusters. With Flux, you can use conventional tooling (such as kustomize overlays) to generate GitOps manifests for the separate targets.

Enterprise options

Both Argo CD and Flux have enterprise version offerings. These are by using tools built on top of the open-source versions. They offer improved support, guaranteed SLAs, provide disaster recovery, and more.

Akuity is an on-prem enterprise-ready solution built by Argo CD’s creators.

Weave GitOps Enterprise is the enterprise solution built on top of Flux and Flagger.

Other solutions like Azure Arc, D2iQ Kommander, and Giant Swarm GitOps are built on top of Flux.


Journey of Argo CD

Argo was accepted to CNCF on March 26, 2020.

Argo project graduated from CNCF on December 6, 2022. Argo achieved and maintains an OpenSSF Best Practices Badge and went through a third-party security audit in July 2022.

Over 250 organizations officially use Argo CD, and over 400 use at least one of the 4 Argo projects. There is also the annual ArgoCon event that takes place in collaboration with CNCF.

The recent 2022 Argo Project user survey shows the types of organizations and users using Argo CD and for how long they’ve been using it. It also shows us that Prometheus is the preferred metrics provider, and Istio and NGINX dominate the service mesh.

Top contributions to the project are from companies like Intuit, RedHat Inc., and Akuity, Inc.

If you’re interested in contributing to the Argo project, here’s how.

Journey of Flux

Flux was accepted into CNCF on July 15, 2019, and it joined the CNCF incubator in March 2021.

Flux graduated from CNCF on the 30th of November, 2022. The project also received a Core Infrastructure Initiative Best Practices Badge and went through a third-party security review last year. Flux has seen a 400% increase in growth activity during its incubator phase.

Flux has over 70 organizations that have officially adopted it. Though flux doesn’t have its own event, it will be a part of cdCon 2023.

Flux v1 was archived in November 2022, and Flux v2 CLI is production ready.

Top contributions to the project are from Weaveworks Inc., Cybercom Group AB, and D2iQ Inc.

If you’re interested in contributing to Flux, here’s how.

2023 Roadmaps

Argo CD

New versions of Argo CD are released approximately every 3 months. The upcoming release cadence can be found here. Find the full Argo CD roadmap here. Other minor updates are added more frequently.

Here are a few of the key features that are coming to Argo CD in 2023.

  • ApplicationSets in the user interface
  • Config Management Plugins parameters in UI
  • Merge Argo CD Image Updater into Argo CD
  • Allow specifying parent/child relationship in configs
  • Support for secrets in application parameters


New flux version releases happen every 2 weeks or so. These include version changes for the individual controllers, API version upgrades, etc. Flux’s roadmap for 2023 can be found here. The roadmap is broken down into milestones.

Here are some key updates coming this year:

  • Adopt Kubernetes serverside apply (Flux GitOps GA)
  • Alert and providers API to GA (Flux notifications GA)
  • Flux Helm APIs and the Flux Helm functionalities GA
  • Image policies and image update automation to GA
  • S3 compatible APIs and OCI artifacts to GA

Pros and Cons

Argo CD

True pull-based GitOps solutionTakes time to set up and get used to
Additional permission and user management featuresLimited to one UI
Supports Kustomize and Helm
Self-healing ability
Supportive and active community
App of apps, multiple clusters deploys
More mature product with better errors messages
Can work without kubectl access


GitOps toolkit provides flexibilityDesigned to support only one repository
Supports Kustomize and HelmLack of self-healing for Helm
API-led approach enables multiple UIsNeeds kubectl access to resolve issues
Supportive and active communityHarder for first-time users
Built with security in mind
Better support for advanced Helm functionality


Argo and Flux are both established and well-tested technologies that are able to bring together and further extend the concept of GitOps within the broader Kubernetes framework. With two reliable projects available, teams have the opportunity to select the most suitable GitOps platform for their specific needs or even combine the two to create a unique and advantageous solution. This gives developers greater freedom to create and manage their own systems, taking advantage of the power and flexibility of both Argo and Flux.

In our next article in the GitOps series, we will discuss how Argonaut builds on top of the Argo Project - with additional capabilities and automation for your cloud deployments.

Get started

Last post

Release Notes: February 2023

28 February 2023
Next post

GitOps Tools: Popular CD and IaC Tools That Enable GitOps Processes

17 February 2023