# Argo CD and FluxCD comparison

**By GitOps Working Group members**
_See below for full list of contributors._

## Plan: Short + Longer version

1. The New Stack blog post, a "light" version to highlight some of the differences between Argo CD & FluxCD, that we've brought up here so far.
- We **think** timeline for blog should be marked as done about Dec 6, and go out about Dec 13 or sometime early in new year
- This is not meant to be comprehensive, but we do want it to be accurate and neutral in perspective, and drum up enthusiasm for the expanded comparison
- this should be shorter and higher level
- really should be more like an announcement to the comprehensive comparison we're working on in OpenGitOps
- call to action: point to effort: follow and/or participate!
3. Expanded OpenGitOps tool comparison between Argo CD and FluxCD
- written and maintained by the GitOps Working Group
- as comprehensive as possible
- a living document
- go super in-depth
- even doing code spelunking, and engave maintainers, to find answers
- If this leads to more innovation or interoperability in either or both projects, all the better

## Intro

This document is a comparison between Flux CD & ArgoCD, within the context of GitOps Principles.

There are a growing number of tools in the gitops ecosystem, and the GitOps WG or OpenGitOps do not endorse one tool over another. This post is in response to the most common question we hear today, asking for a neutral but informed and current comparison of two of the most popular GitOps tools: Argo CD and Flux CD.

We are very excited for other tools in the ecosystem and anticipate similar comparisons and other related content (like blueprints etc) in the near future.

This comparison document was started by Red Hat, then opened up to the rest of the GitOps WG for transparent and open source collaboration.

Our goal with this document is to show both projects in the best light, to represent them in a fair and balanced way, and above all give ACCURATE info about the technical and philosophical differences to end users. Help end users understand factual strengths/weaknesses pros/cons and important considerations around topics that matter to them, and why.

Therefore we want to be both philisophically and technically accurate.

We will do our best to remove biased opinions, while not hiding anything important folks may want to know about each tool.

## Following GitOps Principles

You can use both Flux and Argo in accordance with [GitOps Principles][principles-v1.0.0].

There are some considerations to keep in mind, ways to configure the tools, which users may not realize do should be considered anti-patterns according to GitOps Principles.

Philosophical difference:
<!-- may want to re-word, but the gist here is important -->
- ArgoCD UI prominently features k8s resource options. When you use this feature as it stands now, you are not following GitOps principles because this directly edits k8s resource API objects outside of any source control loop. That said, this features is not a requirement to use ArgoCD. To conform to GitOps, you can avoid using this feature, and instead modify the manifests in source control, and have that ArgoCD pull them into your cluster.
- FluxCD does not have this issue, to be fair, in part because there is no equivalent editing option in it's experimental UI. However, this has been stated by maaintainers that Flux will never this way – any UI for Flux that allows manifest editing will only ever write back to the Git Source, and stay within the control loop.

[principles-v1.0.0]: https://github.com/open-gitops/documents/blob/release-v1.0.0/PRINCIPLES.md

## Multi-tenancy

k8s "soft" and "hard" multi-tenancy.

### Soft multi-tenancy (RBAC/namespace limits)

**philosophically:**

Flux and Argo handle this differently. You can accomplish essentially the same thing in different ways, but the devil is in the details here.

- Argo has cluster-admin, and relies on it's own access control independent of k8s RBAC.
- For example, Red Hat's implementation tries to mitigate this aspect, with their own opinionated deployment of Argo permissions
- Flux was designed to adhere to core k8s RBAC, so various tools that leverage RBAC work together without additional custom coding.
- Flux has no need for additional ACLs for this reason.

**technically:**
- Out of the box, both Flux and Argo "just work" on a hard multi-tenancy setup, using cluster-admin role to do ALL THE THINGS.
- Users also can optionally segment access by namespace.
- Argo implements this using custom ACL-based access control. This may not cause any problems, but if you're heavily using core k8s RBAC with other tools in your cluster, this is something to be aware of.
- Flux implements this using core k8s RBAC to adhere to k8s concept of "soft multi-tenancy". This is accomplished by directing users to specify service accounts in their manifests, so that, and uses the core k8s Impersonation API under cluster-admin to impersonate that service account. In this way, policy restrictions for this service account are applied to the manifests being reconciled. If the binding is not defined for the correct service account and namespace, it will fail. The roles and permissions for this multi-tenancy approach are described in detail here: <https://github.com/fluxcd/flux2-multi-tenancy>

### Hard multi-tenancy (multi-cluster)

**philosophically:**
- the same. they both also integrate with CAPI, crossplane, and other tools in the k8s ecosystem to handle creating new clusters and their dependent cloud resources.

**technically:**
- Argo has a visualization of this in the UI (because it has a UI)
- Flux does not currently provide a UI, but other UIs (including Argo!) can be used to visualize this

## Additional security considerations

Multi-tenancy is covered above, which does overlap with security.

But if you're looking for a detailed security-focused information, this is important and related buyt out of scope of this feature comparison. Will likely be covered in a future post. In the meantime, there are some high-level considerations you mway want to look into. (ADD LINKS TO APPROPRIATE THINGS)

- Flagger
- Argo workflows
- Image scanning
- policy management (Falco sytem calls etc)
- Security audits status

## Application Delivery

Philosophical differences:
- ArgoCD only ever applies plan YAML manifests.
- Flux controllers use the Helm and Kustomize underlying Go libraries as close to the native tooling as possible. I.e., does not use a custom intermediary rendering step in the process.

Technical differences:
- ArgoCD's plain YAML appraoch means, for example, Helm and Kustomize tool support only work until the point where YAML is rendered – essentiallly `helm template` or `kustomize build` piped to `kubectl apply`.
- There are some workarounds built into the tool to mitigate this: Helm hooks are attempted to be converted to syncwave hooks, however not all Helm hooks have an equivalent in ArgoCD <LINK TO TABLE>.
- It's important for users to know that the hooks that can't be converted are silently ignored.
<!-- Check this with Argo Devs? -->
- Similarly, chart dependencies do not work natively due to this YAML-only design.
- There is a manual workaround for this: users are
- Flux's use of underlying Go libraries For example, makse full use of the Helm SDK rather than `helm template`.
- This matters if you want to track releases (`helm ls`) with the Helm client, or use other helm ecosystem tools like `helm diff` plugin. It also means you can

### Handling Application Ordering and Dependencies

- ArgoCD Syncwaves
- Not dependent on type (Helm/Kustomize, since to ArgoCD it's all plain YAML)
- Ordering is numeric. So if you need to move one object in between others 1,2,3,4 etc, you must re-assign numeric values to all that it affects.
- Syncwaves allows you to order individual objects, even if they don't make sense from a k8s point of view (for example, adding a secret before it's namespace). This problem can be mitigated by running multiple times, and it will fail until all the dependencies shuffle in the order requires by k8s. Essentially, a user must have enough domain knowledge about applications to know the correct order of all objects in order to fully leverage this feature.
- Flux CD DependsOn
- How does DependsOn work? ADD A QUICK SUMMARY HERE AND LINK TO DOC
- You can optionally specify endpoints, etc
- Is dependent on type (either all HelmReleases or all Kustoimzations, but not both). To work around this, use Kustomize DependsOn to also apply the Flux HelmRelease CRDs in the desired order with respect to other kustomizations.
- Important note: when used with Helm, DependsOn is much more memory efficient than umbrella chart workarounds.

<!-- this may be wrong. Brain dump that we need to check with Argo Devs -->
Rough note:
- FluxCD has DependsOn (see Christian's write up)
- ArgoCD does not haev an equivalent to this. As a workaround, users are encouraged to specify Helm chart dependencies by creating a tier of custom umbrella charts to order dependencies.

## Image updates automation

Philisophical differences:
- ArgoCD writes back changes as a kustomize patch
- Flux CD writes back to source manifests demarcated by annotations

## Pros & Cons (?) feature comparison matirx

### Argo:
pros:
- has a feature rich, and lovely UI!

### Flux:
Pros:
- feature rich API/architecture functionality
- security first
- highly composable

## Contributors

The following people have contributed to this comparison document:

-

## Stay tuned!

- This is only the beginning. Analysis by the GitOps WG will continue even after this post, and the document will be updated in Git. LINK
- To stay updated, star and watch THIS REPO (like and subscribe yo!)
- To contribute your experiences, findings, and ideas, the repo is an open source project. PRs are welcome! We are very thankful for your contributions and if you desire happy to give public thanks.
- LOTS OF EMOJI