As part of our day to day work, we’re implementing GitOps processes for different customers. One recurring question is: Which tool to choose: ArgoCD or Flux?
So, my colleagues @nicole.sienkamp , @vanessa.werth, @lukas.maikowski, @philipp.markiewka and @philipp.dziosa sat down and tried to find the right answer™️ to this question.
TL;DR it’s a tough choice! Both tools are a mature and can recommended to be used in production. So it’s pretty much a gut decision. At the moment most of us have a tendency to favour ArgoCD mainly because of the better developer experience provided by the UI and the preview environments feature provided by the ApplicationSet controller.
Here are the generic differences between ArgoCD and Flux that we found. On top of those, specific requirements might tip the scale towards one or the other tool.
Arguments for using Flux
- Lightweight tool, less components and CVEs
- Simpler to use from user perspective (ArgoCD’s concepts of
Applications,AppProjects, app of apps pattern andApplicationSetshave quite a learning curve) - Helm implementation
- Writing an explicit
HelmReleaseCustomRessourcecomes more natural than implicitly adding a Helm repo instead of your application’s Git repo in your ArgoCD application CR. - Argo’s usage of
helm templatehas some disadvantages:lookupdoes not work;helmCLI does not work. - In ArgoCD using a helm
values.yamlfrom a git repo and a helm chart from another repo is only possible with a workaround (see our GitOps Playground for example).
- Writing an explicit
- Bootstrapping can be done via CLI and all changes on Flux itself are stored in Git. ArgoCD has this hidden in the docs (not directly in the getting started section) and they have a separate CLI to automate it (autopilot). For Flux, there is also a separate tool, though it does not belong to the core flux project, but is provided by Weaveworks as a separate open-core product: Weave GitOps. It has a feature called GitOps Run, which makes it easy to bootstrap Flux, creates an opinionated repo structure to help overcome the GitOps chasm and has an auto-reloading feature which improves the feedback cycle for local development. You can learn it’s basics hands-on in this short video.
- The Flux team is very innovative. They came up with a terraform oprator, vs code extension, argocd subsystem, they implemented GitOps using OCI registires and AWS Buckets.
- The Terraform operator for Flux finally might provide us with an opportunity to GitOps our Terraform legacy.
Arguments for using ArgoCD
- The out of the Box UI improves the developer experience so much! Two birds one stone:
- The UI is helpful throughout the GitOps process. It displays the status, can be used to trigger things and easy the pain of writing YAML via code generation.
- On top of that the UI might provides enough features so most developers no longer need to use
kubectl. Better DX and security. - On the other hand Flux can be used with weave-gitops as UI, which looks much more promising than the deprecated fluxcd/webui. However, there are the facts that weave-gitops is not part of the Flux project and needs to be maintained separately as well as our gut feeling that the ArgoCD UI offers more features for your GitOps process and also things like authentication via OIDC.
- The ArgoCD team is also very innovative.
- It feels like the Flux team produces more innovations but ArgoCD has one with huge potential: The ApplicationSet controller provides killer features such as preview environments, that only live in the context of a pull request. For Flux, this feature seems not to be within reach.
- For bootstrapping, ArgoCD offers the auto-pilot CLI that helps bootstraping ArgoCD and creates an opinionated repo structure to help overcome the GitOps chasm. You can see it in action in this video.
- Another interesting concept is the argocd-operator. Meta Meta: An operator to operate operators! Still, if you’re planning to operate multiple instances of ArgoCD, this will help and it will also allow for describing the whole ArgoCD config declaratively.
- Flux uses Kustomize under the hood, for example to change the config. Some people might not like kustomize or need to learn it first. ArgoCD’s autopilot also relies on Kustomize as well, though.
- For Jenkins users: The gitops-build-lib supports ArgoCD and Flux v1, but not Flux v2, yet.
Conlusion
During the discussion we could feel our sympathy switching between ArgoCD and Flux like a metronome. However, in the end, for most of us the crucial arguments were the UI with better overall DX as well as the preview environment features which was explicitly requested by some of our customers.
We had a final vote that ended 4:1 in favour of ArgoCD. Still, this result shows that there’s not the right answer to the question of ArgoCD or Flux.
Update 01/23
Very interesting discussion with GitLab: They seem to have decided to switch their own GitOps operator to Flux:
Where this issue has some great insight about ArgoCD vs. Flux. They might have decided to go with Flux but…
ArgoCD likely has wider adoption. Today, I expect ArgoCD to win the market of ready-to-use GitOps tools. We don’t want to build a ready-to-use GitOps tool.