Back to Devoured - July 01, 2026
DEVOURED
Exposing ApplicationSets Beyond YAML: Argo CD's ApplicationSet UI

Exposing ApplicationSets Beyond YAML: Argo CD's ApplicationSet UI

DevOps Argo Project
Argo CD 3.5 debuts a first-class ApplicationSet UI, finally replacing the cumbersome 'App-of-Apps' workaround with native resource tree visualization.
What: The new read-only interface, managed by Peter Jiang and the Argo team, introduces list views, health monitoring, and a 'Preview' feature that lets users visualize generated application diffs before committing to Git.
Why it matters: It addresses a long-standing usability bottleneck by bringing Argo CD’s intuitive visual paradigm to the factory-like nature of ApplicationSets.
Takeaway: Upgrade to Argo CD 3.5+ after the August 4, 2026, release date to manage complex cluster deployments directly via the browser interface.
Deep dive
  • Introduces /applicationsets route with search, filters, and health dashboards.
  • Adds 'Preview' functionality to simulate generator output (Live vs. Desired state).
  • Enables synthetic root node visualization to track parent-child relationships in the resource tree.
  • Maintains Git as the single source of truth (read-only UI).
Decoder
  • ApplicationSet: A controller that automates the generation of multiple Argo CD Applications based on cluster labels, git paths, or other discovery sources.
Original article

Exposing ApplicationSets Beyond YAML: Argo CD’s ApplicationSet UI

We have a long-awaited feature request for ApplicationSet support in the Argo CD UI that has accumulated 189 👍 reactions. With v3.5, that’s changing — Argo CD now has a first-class ApplicationSet UI.

This post is about what’s actually in the UI and how it goes beyond adding a simple list page.

A quick AppSet refresher:

If you’ve used Argo CD’s Application UI, you know it’s the reason a lot of teams pick the project. Resource trees, real-time sync status, a clean diff view, and more. Argo CD made GitOps approachable for people who don’t live in YAML.

ApplicationSets fit awkwardly into all of that. Conceptually, they’re a factory for Applications: you write one resource that says “for every cluster matching this label, generate an Application from this template,” and the controller produces N child Applications. A single ApplicationSet can fan out across dozens of clusters and hundreds of repos.

The problem: Argo CD’s UI didn’t surface this.

Until v3.5, you had two options:

  1. Use kubectl or argocd appset on the CLI.
  2. Wrap the ApplicationSet inside an App-of-Apps and look through the parent Application’s tree.

What’s actually shipping in 3.5

We have a new /applicationsets route that's accessible with the new navigation bar item, along with a revamped Application icon.

A familiar list page

You get the same features you already use on the Applications list: substring match search, filters, a health-summary pie chart, and toggleable layouts. RBAC is enforced exactly as on the CLI — if you can argocd appset get, you can see it here.

A resource tree showing the family

Click into any ApplicationSet, and you get the visualization that we’ve all been waiting for: the ApplicationSet at the root, every generated child Application as a downstream node. Click a child, and you jump straight into its existing details page.

Health, a first-class field

Under the hood, the controller now writes a status.health field on the ApplicationSet itself, derived deterministically from its status conditions. Similar to Applications, the ApplicationSet health can be Healthy/Degraded/Progressing. The AppSet conditions will also be visible through the UI.

Slide-out panel

Clicking the ApplicationSet node or clicking the AppSet Details opens a slide-out panel from the right edge of the screen which includes Summary, Manifest, Events, Preview.

AppSet Preview

If the list page is what people asked for, the Preview feature is the ”wait, you can do that?” moment.

It mirrors argocd appset generate in the browser. Open an ApplicationSet, click Preview, and you’ll see an editable YAML of your AppSet spec.

Now click Edit on the manifest, change a generator (add a label selector, narrow a Git path, swap a cluster), and click Preview again. The diff regenerates against your edits. You’ll see three views:

  1. LIVE APPS — What apps would be generated with no edits
  2. DIFF — Unified diff of every Application that would change once we apply the change
  3. DESIRED APPS — What apps would be generated if the spec were applied.

The App-of-AppSet preview

If your ApplicationSet is managed by a parent App-of-Apps, you can preview from the parent too. The Preview panel on the parent shows exactly what child Applications would change when you sync.

This bridges what was previously a confusing two-step: ”I have a pending sync on a parent App — what does that actually do to my child Apps?”

Owner badges and root node on child Applications

Every Application generated by an ApplicationSet now carries an owner badge with the parent’s name on its resource tree. Click it, and you jump to the parent.

There is also a toggle-able icon where you can show the parent AppSet as a synthetic root node managing the Application itself.

Limitations to know about

This UI is meant to be read-only in the alpha phase. We are not using this UI to create/update/delete AppSets from the cluster itself. Argo CD is still a GitOps tool and git will always be the core write interface.

It will be an alpha feature in 3.5. The look and behavior may change as more features and improvements get added. Feel free to point out any issues or enhancements on the Argo CD repo or slack channel.

How to try it

Upgrade to Argo CD 3.5+ (Release Candidate Date: Tuesday, Jun. 16, 2026, GA date: Tuesday, Aug. 4, 2026.

Visit https://<your-argocd>/applicationsets, or use the new entry in the top-level navigation. The full feature reference lives in the ApplicationSet Web UI documentation.

Thank you

This is one of the longest-running enhancement requests in the project. It went through many design cycles, two milestone slips and 10+ PRs. Special thanks to @reggie-k, @keithchong, and @alexymantha for the initial design and implementation and @jwinters01 for helping review PRs.

Thanks to everyone else who helped with this feature whether that was reviewing PRs, helping with UI or API design, or implementation!

Explore all 57 articles in today's digest

Fresh dev news, AI-digested daily. Never miss a trend at devoured.fyi