GitOps with ArgoCD and Flux has established itself as the standard approach to continuous delivery on Kubernetes. For example, here at NWS, we use ArgoCD to operate the NETWAYS Cloud. Both tools are CNCF Graduated projects, but they follow different philosophies. The choice between them will significantly shape how your platform team works in the future. In this article, we compare their similarities and differences and take a look at their adoption and popularity. We’ll also explore different use cases and highlight one of the most exciting current trends in the ecosystem: Gitless GitOps via OCI registries.
What exactly is GitOps?
GitOps describes an operational model in which the desired state of a system is stored declaratively in a repository (typically Git). A controller in the Kubernetes cluster continuously compares this target state with the actual state and automatically resolves any discrepancies. This process is also known as reconciliation. Instead of manual ` kubectl apply` commands or traditional push pipelines, software within the cluster operates on the “pull” principle. This can be a key security and audit advantage over traditional CI/CD approaches.
The two best-known implementations of this principle on Kubernetes are ArgoCD and Flux. Both are now CNCF Graduated – the highest maturity level recognized by the Cloud Native Computing Foundation.
Similarities and Differences Between ArgoCD and Flux
The similarities between the two projects lie primarily in their status within the CNCF and in their project organization. Both have been CNCF Graduated projects since 2022 and are used in production by a broad range of end users. Both projects are Kubernetes-native and work with CustomResourceDefinitions (CRDs) and controllers. And both projects are licensed under the Apache 2.0 license and are fully open source.
The differences lie in the philosophies of the two projects: ArgoCD is a centralized, UI-driven application with its own web interface, Role-Based Access Control (RBAC), and a central server through which so-called Applications are managed as separate CustomResources. This makes ArgoCD particularly accessible to development teams that value visual feedback and self-service.
Flux, on the other hand, is a modular collection of independent controllers (the so-called “GitOps Toolkit”). By default, it does not have a graphical user interface, but it offers tighter integration with the Kubernetes API and lower resource consumption. The Flux Operator project now provides, among other things, a comprehensive UI for viewing Flux deployments.
These architectural differences naturally have practical implications as well:
- Scaling: With many Application CRs, ArgoCD can reach its limits on its central repo server. However, this issue can be effectively addressed through sharding. Flux scales more linearly: Each controller from the GitOps Toolkit is responsible only for its own resource type.
- Usage: UI- and API-based (ArgoCD) versus CLI- and YAML-based (Flux). However, the lines between these approaches are becoming increasingly blurred: ArgoCD offers the CLI
argocd, and Flux now also has a usable web interface through the Flux Operator project. - Multi-tenancy: With AppProjects, ArgoCD offers an isolation concept using its own RBAC to implement tenant separation. Flux deliberately does not include its own authorization layer and instead relies on Kubernetes RBAC. Tenant separation is achieved through ServiceAccounts, Roles, and RoleBindings within the cluster itself.
Adoption and Popularity of ArgoCD and Flux
According to the CNCF’s own survey data, ArgoCD currently has the wider reach, while Flux excels particularly in industries and environments where resource conservation, modularity, and higher security requirements converge.
ArgoCD also leads in GitHub metrics: It has significantly more stars than Flux (roughly 24,000+ compared to around 8,000), though this primarily reflects community visibility rather than actual production usage.
Flux has a unique history: as one of Weaveworks’ original projects, it helped coin the term “GitOps” in the first place. After Weaveworks was shut down in early 2024, several large companies stepped in to support the maintainers, ensuring that the project remained active and CNCF-backed despite the breakup. According to CNCF statistics, both projects continue to see growing numbers of contributors and are being used in large, well-known production environments.
GitOps with ArgoCD and Flux: Which Tool Is Right for Which Situation?
Even though ArgoCD and Flux ultimately lead to the same result – an environment managed declaratively via GitOps – the right choice depends on the specific context. We therefore took a look at a few common scenarios.
Small Teams and Simple Setups
If you want to get started with GitOps quickly and get immediate visual feedback, ArgoCD is often the better choice. The web UI significantly lowers the barrier to entry, especially for teams without in-depth Kubernetes experience. The deployment model, based on a single CustomResource, allows for rapid implementation of proof-of-concept projects, and you’ll quickly see initial results, which are made directly visible through the web interface.
Platform Engineering and Multi-Cluster Environments
Flux really shines when dealing with a very large number of clusters (hundreds to thousands), such as in edge or IoT contexts. Low resource requirements, no incoming network requirements, and a model in which each cluster manages itself go hand in hand with a decentralized approach.
Companies with compliance and audit requirements
This is where ArgoCD shines, thanks to its centralized, proprietary RBAC, SSO integration, and a unified view across cluster boundaries. A “single pane of glass” that decision-makers appreciate and that can simplify audits.
At the same time, Flux appeals to security-conscious teams precisely because it does not introduce an additional endpoint intended for human operators and seamlessly embeds GitOps permissions into the existing Kubernetes RBAC.
Integration with the respective ecosystem
Ecosystems have emerged around the two leading GitOps platforms, often addressing additional requirements that arise over time: Argo Rollouts for progressive delivery, Argo Workflows for CI/CD pipelines, and Argo Events for event-driven automation are also part of the Argo project and complement ArgoCD in many ways.
Around Flux, Flagger (Progressive Delivery), various notification controllers, and Terraform integrations provide good extension points.
Both tools can also be combined – for example, to use Flux for bootstrapping cluster and infrastructure components, while applications deployed via ArgoCD can be viewed by development teams in the web UI, where issues are visualized. However, running both tools in parallel on the same resources remains the exception and should be carefully planned.
Gitless GitOps via OCI Artifacts: The Latest Trend in the Ecosystem
A particularly exciting trend in the GitOps landscape is what’s known as Gitless GitOps. The name is somewhat misleading – Git usually remains part of the development process, but disappears from the actual deployment path to the cluster.
What’s behind this?
Instead of using manifests directly from a Git repository, GitOps tools retrieve them from an OCI (Open Container Initiative) registry – the same type of registry used for container images. CI pipelines build and sign the manifests as OCI artifacts and push them to the registry. The GitOps tool in the cluster monitors only this registry and no longer needs any Git credentials or network access to Git hosting systems.
Flux has long provided full support for OCI registries as a source via the Source Controller, using a dedicated CustomResource (OCIRepository). This implementation also enables signature verification and reconciliation directly from the registry.
Starting with v3.1, ArgoCD began supporting OCI registries as a source for Application CRs, including for Helm charts and Kustomize artifacts. The feature set has been continuously expanded since then and is approaching the scenarios supported by Flux.
Advantages and Disadvantages of Gitless GitOps
Like any process, Gitless GitOps has some advantages and disadvantages: Artifacts are typically delivered faster, since OCI registries are optimized for handling binary artifacts. Support for signatures and provenance (e.g., via Cosign/Sigstore) is also better, which strengthens supply chain security and keeps auditors happy. Furthermore, by eliminating Git as the source of the artifacts to be deployed, access to the actual repository containing the underlying code is no longer required.
One potential drawback is the loss of granular Git history and traditional pull request processes in the deployment pipeline—OCI artifacts for the applications to be deployed must first be built, optionally signed, and uploaded to an OCI registry. This also requires additional tooling, though this is already standard in most development processes (e.g., Docker).
For teams with high security and scalability requirements—for example, in the field of edge computing—Gitless GitOps via OCI artifacts is already a key component of the architecture and is no longer merely a niche topic. In general, the entire ecosystem is moving toward broader use of OCI artifacts; see, for example, the introduction of OCI Volumes in Kubernetes v1.36.
Extensibility, Integrations, and Support Within the CNCF Landscape
Both projects are deeply embedded in the CNCF ecosystem but differ in terms of governance and extensibility:
- ArgoCD is being developed as part of the larger Argo project (which includes Argo Workflows, Argo Rollouts, and Argo Events) and enjoys strong commercial backing, including from Intuit, Red Hat, and Akuity, which was founded by the original creators of ArgoCD. This commercial depth is also reflected in a wide range of managed service and enterprise support options.
- Flux continues to be developed directly under CNCF governance. After Weaveworks ceased operations in 2024, other companies took over the funding of key maintainers – a testament to how resilient the open-source model can be even without a single sponsoring company.
Integration Options
Both tools can be integrated into a typical CNCF environment:
- Progressive Delivery via Argo Rollouts or Flagger
- Policy engines such as OPA or Kyverno for admission control
- Observability and notification integrations (Slack, Prometheus alerts, etc.)
- SSO/RBAC integrations with existing identity providers
- Combination with Helm, Kustomize, and, increasingly, Crossplane for Infrastructure-as-Code
If you need an additional layer of governance across both tools—for example, for centralized access management across multiple clusters – you can rely on complementary platforms that can be built on top of both ArgoCD and Flux.
ArgoCD or Flux—how do you make the right decision?
GitOps with ArgoCD and Flux offers a mature, production-ready foundation in both cases. The decision is rarely a matter of “better” or “worse,” but rather depends on the scenarios in which you want to use it:
- Choose ArgoCD if a consistent user interface, self-service for development teams, and a broad integration ecosystem are important to you.
- Choose Flux if you manage many clusters – some of which have limited resources, if you want to seamlessly integrate GitOps permissions into your existing Kubernetes RBAC, or if you prioritize a particularly streamlined setup.
No matter what you decide to do, Gitless GitOps via OCI registries is already showing where GitOps architectures are headed. Artifact signing, improved supply chain security, and less direct reliance on Git in the delivery pipeline are becoming increasingly important topics.
0 Comments