Weaveworks Died. Flux Didn't: The Community-Run GitOps Comeback vs Argo CD's Hub-and-Spoke

In February 2024, Weaveworks — the company that created Flux — shut down, and the obituaries for Flux practically wrote themselves. A GitOps project losing its commercial sponsor looks, from the outside, like the beginning of a slow archival.

It wasn't. Here is the verdict up front, with receipts below: Flux is a CNCF graduated project that kept shipping through the transition and is shipping faster now than before it. The current release is v2.9.5, cut in late September 2026; the repository was pushed to within the last day; and Morgan Stanley runs more than 500 Kubernetes clusters on Flux. The interesting question in late 2026 is no longer whether Flux survived. It is whether your platform wants Flux's decentralized toolkit model or Argo CD's centralized hub-and-spoke — an architecture decision, not a viability gamble.

The rescue, with names and dates​

CNCF graduation is what made the rescue possible. Flux graduated in November 2022, which meant its trademarks, governance, and infrastructure already lived under neutral stewardship when Weaveworks closed. No single company had to be replaced as owner — only as employer of maintainers and provider of commercial support. That is a much easier gap to fill, and it got filled within weeks.

ControlPlane moved first, hiring Flux maintainer and architect Stefan Prodan (also the creator of Flagger) and core maintainer Soulé Ba to keep working on the project full-time, backed by a hardened, FIPS-compliant enterprise distribution. Then, on March 19, 2024, the CNCF announced a wave of new corporate support. The list is worth reading in full because it is the actual answer to "who keeps this alive now":

Two rows in that table matter more than the rest. Microsoft's Lachie Evenson put it bluntly: "Flux is the engine that powers several GitOps experiences on Azure as well as in our customer's environments," with a commitment to keep investing upstream. And GitLab had already made Flux its recommended GitOps path via the GitLab agent a year before the shutdown. These are not sponsorship logos — they are product dependencies. Companies whose own managed offerings embed Flux cannot let it rot.

There is one licensing wrinkle worth knowing before you adopt the ecosystem around the core. The Flux controllers themselves remain Apache-2.0 CNCF code, but ControlPlane's newer distribution layer — the Flux Operator and its distribution channel — is licensed AGPL-3.0. That is a deliberate commercial-open-source split, not a trap, but if your platform redistributes or builds a managed service on the operator rather than upstream Flux, read the license the way you would any AGPL dependency.

The shipping record​

Backing announcements are cheap; releases are the audit trail. Here is Flux's minor-release cadence across the post-Weaveworks period:

Two to three minors a year plus steady patches, with no gap at the moment of maximum danger — v2.3 shipped three months after the shutdown. The community signals kept pace: the first FluxCon NA ran in 2025, Morgan Stanley's platform team presented there, and Flux turned 10 in July 2026. A project that throws itself a tenth-birthday party with a bank's platform team on stage is not a project winding down.

Note the v2.6-era item that matters most to agent builders: an MCP server for AI-assisted GitOps, letting agents inspect and operate Flux state through a standard tool interface. The project whose community had to rebuild itself is also the one currently experimenting hardest at the agent-operations boundary.

Scale proof from a bank​

The single best "is it safe" datum is a regulated enterprise running Flux past the scale most platforms will ever reach. At FluxCon NA 2025, Morgan Stanley's Tiffany Wang and Simon Bourassa described a five-year migration from push-based CI/CD to a self-service GitOps platform on Flux, written up on the Flux blog in March 2026:

• 500+ clusters, 2,000+ nodes, 100,000+ containers, and tens of thousands of Flux custom resources under management.
• Secure multi-tenancy with least-privilege enforcement, built on Flux's Kubernetes-native RBAC rather than a parallel permission system.
• Performance tuning to keep reconciliation load from overwhelming the Kubernetes control plane at that fleet size — documented, not hand-waved.
• A move from Git to S3 buckets as the source of truth, using Flux's source-controller abstraction for what it was designed for: sources that are not always Git.

A bank does not migrate 500 clusters onto a project it expects to be unmaintained. Neither do telcos: Orange's Sylva project runs Flux as the GitOps framework for containerized network functions across telecom infrastructure. These are the adopters that do vendor-viability diligence for a living.

Toolkit vs hub-and-spoke​

With viability settled, here is the comparison that actually matters. Both projects are pull-based — controllers inside the cluster reconcile toward desired state declared in Git — but they distribute the work oppositely. Flux is a toolkit of small, stateless, single-purpose controllers (source, kustomize, helm, notification, image) composed per cluster through Kubernetes APIs. Argo CD is a centralized application: a control plane with a server, a repo server, and a Redis-backed application controller, managing registered clusters hub-and-spoke behind a first-class web UI.

† User lists via Spacelift's Flux vs Argo CD comparison; Morgan Stanley and Orange added from the 2025–2026 case studies cited above.

The honest Argo advantages take no brilliance to enumerate: the UI is genuinely the reason many teams pick it — visual sync state, one-click rollback, and a resource tree that new hires understand on day one. Adoption is roughly triple Flux's by stars, which compounds into more tutorials, more Stack Overflow answers, a bigger hiring pool, and more consultants. And for fleets managed as app-of-apps or ApplicationSets from a central team, the hub model is the thing being bought, not a wart.

But the hub has a cost the table makes structural. Argo CD's central controller with its Redis cache is a stateful pet in the deploy path — its HA install adds a StatefulSet and extra containers for Redis, while Flux ships no StatefulSet and keeps no cache to lose (manifest-level comparison). It needs HA planning, cache sizing, and backup thinking that Flux's stateless per-cluster controllers never require. For a platform running tenant workloads across many clusters — or across customer-owned infrastructure where a central hub is a liability rather than an asset — "nothing to back up" is a feature with a dollar value.

Both sides are also shipping fast right now, which is the healthiest possible sign for the comparison. Flux's 2026 brought Helm v4 with server-side apply, a CLI plugin system with Mirror (cross-registry artifact sync) and Schema (offline manifest validation) plugins, selective drift correction via ignore rules, and an OpenBao integration for secrets and signatures. Argo CD's v3.5, generally available in August 2026, answered with internal mTLS, source integrity verification, commit signing, and a new ApplicationSet UI, with v3.6 already in release-candidate. Neither project is coasting. Pick on architecture, because release velocity will not decide for you.

The decision for a self-hosted PaaS​

For a platform deciding what reconciles tenant deploys, the choice reduces to where you want the state and the clicks to live:

And then there is the second question, the one that outlives this particular comparison: "who backs the project if the original company disappears" deserves to be asked about every CNCF dependency on your list, not just Flux. Flux is the worked example of the right answers. Ask four questions and demand specifics, not vibes:

1. Neutral home? Graduated or incubating CNCF (or equivalent foundation) projects survive their creators; single-vendor open source with an "open roadmap" does not promise that. Flux graduated in 2022, two years before it needed the shelter.
2. Maintainer-employer diversity? One company employing every core maintainer is a single point of failure with extra steps. Flux's full-time maintainers sit at ControlPlane, Microsoft is committed to upstream contributions, and AWS and GitLab build products on the project — no single employer can quietly walk away with the roadmap.
3. Whose product breaks if it rots? Sponsorships lapse; embedded dependencies do not. Azure Arc, EKS-Anywhere, and the GitLab agent all ship Flux inside the product — that is maintenance insurance no pledge can match.
4. Commercial exit ramp? If you ever need a throat to choke, is there a vendor selling support or a hardened distribution? ControlPlane's enterprise Flux, plus a dozen smaller supporters from the 2024 announcement, say yes — with the AGPL note above for the operator layer.

Run any other dependency through the same four. The ones that fail question 3 are the ones that should worry you: a project nobody ships inside a product is a project maintained on enthusiasm, and enthusiasm is the least durable backing of all.

The comeback is the feature​

Flux losing Weaveworks and accelerating anyway is not just a survival story — it is the strongest possible evidence for the governance model. The project was tested the way almost no popular CNCF project gets tested: its creator died, suddenly, and within weeks new maintainers were hired, within months a first post-shutdown minor shipped, and within two years a bank was presenting 500-cluster production numbers on its conference stage. That is what "community-run" is supposed to mean, demonstrated rather than asserted.

So the obituaries were wrong, and usefully wrong: they told you exactly which question to ask next. Not "is Flux alive" — the release log answers that — but "toolkit or hub," answered by your architecture, your operators, and where you want state to live. Either answer is defensible in late 2026. "Nobody maintains Flux" is the only answer that is not.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.