Whenever I hear a debate about the pros and cons of Argo CD and Flux as preferred GitOps solutions, invariably it’s Argo CD that wins out. Often, but not always, it’s Argo CD’s web user interface that is cited as the big differentiator between the two tools. Now, I could (but shouldn’t) wax lyrical about the clickops approach being a potential anti-pattern to the GitOps way of doing things. GitOps tools use abstractions represented as Kubernetes config to model the environment; an Application or ApplicationSet, a GitRepository, a HelmChart, a Kustomization, and so on. Just like the Kubernetes config that represents the application that is to be managed using GitOps, the Gitops abstractions need to be expressed declaratively in immutable, versioned storage (such as a version control system, like Git), too. Otherwise, they will suffer the ambiguity and lack of reliability associated with configuration drift. Clickops is fine if these abstractions are managed using GitOps principles, but not OK if they’re created in the cluster, in an imperative fashion through a web UI. Enough!
There is an obvious attraction to a web UI for would be adopters set free in an unfamiliar environment. For developers, whose only want is to get their application deployed, having to get your head around the complexities of Kubernetes and the machinations of a GitOps tool, is an unnecessary distraction. A web UI that enables you to operate these environments, and to gain appropriate, timely feedback on deployments from, is all too valuable. This is the great upside to the web UI that Argo CD provides out-of-the-box. But, what about Flux?
Flux, perhaps because of the clickops anti-pattern, doesn’t come bundled with a web UI like Argo CD1. However, it has a feature-rich command line interface instead (as does Argo CD, by the way), which enables the creation of the configuration for its abstractions, amongst other useful things. A comprehensive CLI is right up my Straße, but clearly it’s not for everyone, so what can you do to minimise your exposure to it, and still get an optimal experience with Flux? Well, all is not lost, because there are a few community-provided web UI solutions for Flux to try out!
Flux Plugin for Headlamp Link to heading
Headlmap is a general, open-source web UI for Kubernetes, and is a sandbox project of the Cloud Native Computing Foundation. It enables the management of Kubernetes clusters and the workloads deployed therein, and even has a map view (beta) of the objects and their relationships, much the same as can be found in Argo CD’s web UI. Headlamp is designed to be extensible through a plugin architecture, with individual plugins created as Javascript bundles. Currently, Headlamp has plugins for Prometheus, Backstage, cert-manager, OpenCost, and Flux, amongst others. It’s a growing list.
The plugin for Flux adds a sidebar entry for managing the objects that relate to Flux abstractions; things like a HelmRelease, a Kustomization, or an ImagePolicy. In tabular form, it provides the summary details of each object and its status, with the ability to drill down further to retrieve more granular information when needed. This allows for determining the state of the system without having to use the command line to interrogate the cluster directly.
It’s also possible to suspend reconciliation, or force an asynchronous sync with the ‘source’ if required. Headlamp’s UI adapts to the permissions available to the authenticated user, according to the privileges afforded to the user via RBAC. Hence, users get to see and do only what their role permits them to see and do.
Weave GitOps Link to heading
Flux originated from a company called Weaveworks, which sadly closed down in 2024. Amongst the numerous open-source tools initiated by Weaveworks, was Weave GitOps, which included a graphical ‘management overlay’ for Flux-based GitOps environments. After the demise of Weaveworks, the Weave GitOps open-source project lay abandoned for almost a year, before it was uncoupled from the defunct organisation and donated to a community-driven entity of the same name. The first commit in the resurrection was made in November 2024. After a couple of months of work, a 0.39.0 Release Candidate (RC.1) surfaced on GitHub.
Weave GitOps is very similar in look, feel and function to the Flux Plugin for Headlamp, with some minor differences. It won’t be a surprise to learn that the Headlamp plugin was inspired to some degree by Weave GitOps, as evidenced by this comment.
Whilst the web UI provided by Weave GitOps is functioning again as a viable front end to Flux, at present it feels as if there is still a fair bit of work to be done to get it to a stable and viable proposition. It will be interesting to see how these two similar user interfaces progress, and whether they start to diverge at some point.
Capacitor Link to heading
Another option for graphically viewing Flux environments, is Capacitor, an open-source web UI that originated from a company called Gimlet. It has a similar goal to the other user interfaces; to provide simple, graphical feedback on the state of the applications running in a cluster, being managed by Flux. And, to see the state of Flux itself, too.
Capacitor arrived in a fanfare in early 2024, before the Headlamp plugin was released, and before work commenced on the resurrection of Weave GitOps. For a while it was the only web UI available for Flux. In recent times, however, there appears to have been a hiatus in its maintenance, with the last commit to Capacitor’s GitHub repo having been made in October 2024. It’s unclear what the long term future holds for Capacitor.
Conclusion Link to heading
All of these user interfaces for Flux are designed in a similar vein; to provide a simple, utilitarian view on the state of deployed applications, and the Flux runtime environment that manages them. In the main, the interfaces are read-only, which removes the temptation to revert to clickops-style management. Unlike the web UI provided by Argo CD, none of them have the means to create any abstractions for managing applications.
Without the ability to create the abstractions, Flux adopters are left to craft YAML definitions for these abstractions by hand. Or, the Flux CLI can be used to create them according to the arguments that are provided to the sub-command in question (e.g. flux create source oci). Just be sure to export the definitions rather than have them created imperatively in the cluster, and then commit them to the source that the Flux runtime is watching.
It’s a little too early to know how this landscape will shift over time, but for those with a preference for a web UI over a CLI, Headlamp seems the best bet at present. It has a wider focus than just Flux, it’s well maintained, and is a registered sandbox project of the CNCF.