Argo CD RollingSync progressive syncs

When ApplicationSet progressive syncs with RollingSync fit your rollout

RollingSync fits when one ApplicationSet fans a change out to many clusters or environments and you want that change to land in stages rather than everywhere at once. It groups the generated Applications into ordered steps using label matchExpressions, waits for every Application in a step to reach Healthy before moving on, and limits how many Applications in each step can update at the same time through maxUpdate, which defaults to 100 percent. According to the progressive syncs guide, syncs still respect sync windows, so a staged rollout can be paused by a freeze you already run. The feature is Beta since v3.3.0 and must be switched on with --enable-progressive-syncs, the matching environment variable, or applicationsetcontroller.enable.progressive.syncs in argocd-cmd-params-cm. Treat it as a Beta capability that your team has tested, not as a settled production pattern, and confirm the current status against the guide for the exact release you run.

Simpler patterns often cover the need. If every cluster can take the change at the same time, or if your generator already produces separate ApplicationSets per environment that you promote by hand or through Git, a plain ApplicationSet with automated sync may be easier to reason about. Progressive syncs add real operational weight: generated Applications lose automated sync, Applications not matched by any step must be synced manually, and each step depends on health checks that you have to define well. Ask whether your change window and promotion process actually need the step-by-step gate, whether your health checks would reliably report a bad cluster as Degraded, and whether your operators can handle manual syncs for unmatched Applications. If the answers are yes, RollingSync is worth a controlled trial in a non-production ApplicationSet before you depend on it.

Which RollingSync settings to choose for each rollout pattern

This table compares the RollingSync settings you will decide on, from enabling the feature to deletion order and sync windows. Read each row as a choice: when it fits a rollout pattern and what it costs you in speed, control or safety. The main takeaway is that narrower steps lower blast radius but lengthen the total rollout.

Setting	Choose it when	Trade-off
Enable progressive syncs (flag, environment variable or argocd-cmd-params-cm)	You want RollingSync steps at all. Pick one method and keep it consistent across the control plane.	The feature is Beta since v3.3.0, so confirm it is acceptable for your change policy before depending on it.
Step matchExpressions on labels (for example, stage per environment)	Your Applications already carry clear labels such as environment, region or tier, and you want predictable grouping.	Labels must be set correctly on every generated Application, or applications drift into the wrong step or go unmatched.
Few broad steps (for example, dev then production)	You want a simple promotion path and accept a larger blast radius per step.	Fewer steps mean a faulty change can reach many clusters before a health check stops the rollout.
Many narrow steps (for example, one region or cluster group per step)	You need small, observable increments across many clusters or regions.	Each step waits for Healthy, so total rollout time grows with the number of steps.
maxUpdate at the default of 100 percent	A step can safely update all matched Applications at once, such as a small group of clusters.	The step gives little protection inside itself, since every matched Application changes together.
maxUpdate below 100 percent (for example, a fixed count or percentage per step)	A step holds many Applications and you want to limit how many change before health is checked.	Lower limits extend the rollout and require you to confirm how partial updates behave for your workloads.
deletionOrder Reverse	Deletions should unwind in the opposite order of the rollout so dependent Applications go first.	Reverse ordering adds sequencing to teardown, which can slow removals and must be tested against your dependencies.
Default deletion order	Removals do not depend on step order, and you want no extra sequencing.	Dependent workloads may be removed in an order that breaks services if steps are coupled.
Rely on sync windows to gate steps	Releases must land only in approved time slots, such as during change freezes.	Steps can stall outside windows, so confirm how waiting steps affect release timing with your change calendar.
Manual sync for Applications outside any step	Some Applications should never change automatically, such as those under separate approval.	Unmatched Applications need an operator to sync them, which adds work and can leave environments out of step.

Why generated Applications lose automated sync under RollingSync

Progressive syncs turn automated sync off on the generated Applications, so the RollingSync controller, not auto-sync, decides when each step runs. Without this, every Application produced by the ApplicationSet would reconcile the moment Git changed, and all environments would move at once, which defeats the purpose of stepping a change through clusters or environments. The Argo CD progressive syncs guide, linked below, describes this behavior. Confirm the exact behavior in the Argo CD version you run before you design your release process around it, because the guide is the reference for how the controller handles generated Applications.

The operational consequence is that an Application outside any step has no automatic path to deployment. Applications not matched by a step's matchExpressions must be synced manually, so a change to one of them can sit in Git until someone triggers it. The same applies to a step's Applications when the controller is waiting on a health check or a sync window. Decide before rollout who owns that manual step, whether a platform on-call rota, the application team, or a release manager, and confirm that person has the sync permission in the relevant AppProject. Write down how a missed manual sync is detected, for example through Argo CD Notifications or a dashboard review, so a stalled change does not go unnoticed for days.

Plan the manual path as part of the design, not as an exception. Run a test change through a labeled cluster you control and confirm that generated Applications show auto-sync disabled, that the unmatched Applications wait for a manual sync, and that the step ordering behaves as expected. Record the result with the Argo CD version used, since the guide's behavior is the basis for your runbook. Your team should also ask whether the manual sync steps will be audited in the same way as other changes, because a sync triggered by hand is still a production change.

How to enable and configure RollingSync step by step

This sequence takes a team from confirming Argo CD version and Beta status through enabling progressive syncs, labeling generated Applications, defining ordered RollingSync steps and testing the rollout on a non-production set before relying on it.

Confirm version and Beta status
Check that the Argo CD installation runs v3.3.0 or later, because ApplicationSet progressive syncs became available in that release. Confirm with your platform owner that a Beta feature is acceptable for the target environment, since the behavior may change before it is marked stable. Record the decision and the exact version in your change record. Done means you can show the running version (for example from the Argo CD UI or the argocd version command) and a documented go or no-go decision from the owner of the environment.
Enable the progressive syncs flag
Turn on the feature through one of the three supported methods: the --enable-progressive-syncs argument on the ApplicationSet controller, the matching environment variable, or the applicationsetcontroller.enable.progressive.syncs key in argocd-cmd-params-cm. Pick one method and keep it in the same Git-managed configuration that holds the rest of your Argo CD settings so the change is reviewed and reproducible. Restart or roll the ApplicationSet controller so the setting takes effect. Done means the controller logs or deployment show the flag active and a test ApplicationSet with a RollingSync strategy is accepted rather than ignored.
Label generated Applications for step matching
Add labels to every Application the ApplicationSet generates, using the generator template so each child receives them. Use consistent keys such as an environment or wave label with values that describe the rollout order, for example a label that marks development applications separately from production ones. The labels are what RollingSync steps match with matchExpressions, so agree the naming with the people who own the generators before writing steps. Done means you can list the generated Applications with kubectl or the Argo CD UI and see the expected label values on each one.
Write RollingSync steps with matchExpressions
In the ApplicationSet spec, set the strategy to RollingSync and define an ordered list of steps. Each step uses matchExpressions against the labels from the previous step, so every Application lands in exactly one step. Keep the first step to the least critical group, such as a non-production cluster, and add later steps for wider groups. Done means a dry review of the manifest shows each step's selector and that no label combination is ambiguous between steps.
Set maxUpdate limits per step
Add maxUpdate to each step to cap how many Applications in that step update at once. The default is 100 percent, which means every matched Application in the step can update together, so set a lower value wherever the step contains more than one application you want to watch closely. Confirm that the value matches your tolerance for simultaneous change and your capacity to investigate failures. Done means each step has an explicit maxUpdate value that the change reviewer has accepted, and the value is written in a form the team can read without consulting the documentation.
Set deletion order and confirm unmatched Applications
Decide whether deletions should follow the reverse step order by setting deletionOrder to Reverse, which removes Applications in the opposite sequence to how they were rolled out. Then list every generated Application that no step matches. Argo CD does not sync unmatched Applications automatically, so each one needs an owner and a manual sync process, or a label change that brings it into a step. Done means you have a written list of unmatched Applications, a decision on deletion order, and an owner for each unmatched item.
Test on a non-production set and verify halting
Run a planned change through the steps against a non-production set of Applications first. Watch that updates move in the defined order, that each step waits until its Applications report Healthy, and that a deliberately failing or unhealthy Application stops the next step from starting. Confirm sync windows also gate the rollout as expected. Remember that generated Applications have automated sync turned off, so each sync is driven by the rollout. Done means you have a recorded test run showing ordered progress, a halt on an unhealthy step, and a sign-off before the configuration reaches production.

Which step design decisions change rollout risk

Every RollingSync rollout depends on a handful of design choices made before the first sync: how Applications are grouped, how many can change at once, what counts as healthy, and how timing and deletions behave. Each card below names one of these decisions and the trade-off it carries, so the team can review them together before enabling progressive syncs.

Number of steps and their labels

Steps are defined with label matchExpressions, so the labels on each generated Application decide which step it lands in. Grouping by environment, region or cluster tier gives a clear promotion order, but more steps mean longer rollouts and more labels to keep correct. Check that every Application carries exactly the labels your steps expect, because an Application that matches no step must be synced by hand.

Size of maxUpdate per step

maxUpdate caps how many Applications in a step update at once, and its default is 100 percent, which means a whole step can change together. A small cap in the first step limits the blast radius of a bad change, but it also stretches the time to reach later steps. Start with a conservative value in the earliest environment and raise it only after several clean rollouts.

What Healthy means for each workload

RollingSync waits for every Application in a step to report Healthy before moving on, so the health definition controls when promotion happens. A Deployment that reports Healthy while its pods crash-loop can let a bad release reach the next step. Confirm that readiness probes, custom resource health checks and any ignored resources reflect real service health for each workload type in the step.

Sync windows and step timing

Syncs respect sync windows, so a deny window that opens mid-rollout can hold an Application in a step while the rest of the plan continues to wait. This can stretch the rollout across a change freeze or leave the promotion half finished. Check the windows on each project before scheduling a rollout, and decide in advance who will complete a stalled step.

Deletion order against dependencies

With deletionOrder set to Reverse, removed Applications are deleted in reverse step order, which suits stacks where later steps depend on earlier ones. The order only protects you if the dependencies follow the same environment chain, so a shared service in the first step may be deleted last. Map the dependency graph before choosing the order, and test a deletion in a non-production step first.

Ownership of manual syncs

Progressive syncs turn off autosync on generated Applications, and any Application not matched by a step must be synced by hand. Someone must own that queue, or changes will silently stop reaching those clusters. Name the team that reviews unmatched Applications, define how they are notified, and include them in change records so auditors can see who approved each sync.

How step design differs for environments and for clusters

Within one cluster, the steps usually map to deployment stages such as dev, staging and production. Each generated Application carries a label that names its environment, and the RollingSync steps select on that label in order. The main risk is that a stage looks healthy while the next stage depends on something it has not yet proven, so the step boundaries should follow the promotion gates your release process already uses.

Label design: Use one label key, such as env, with a small, fixed set of values. Avoid putting version numbers or team names in the same label, because a new value silently drops Applications out of every step.
A bad step: A single step that matches dev and production together, which removes any gate between them. Another bad step is one that matches nothing, so the rollout appears complete without touching anything.
Health before advance: Confirm that every Application in the current step is Healthy and that its previous sync completed, not only that the sync was started.
Production controls: Keep production in its own final step and check that sync windows cover the schedule you intend. Confirm that approval for production is enforced outside Argo CD if your change process requires it.
Unmatched Applications: Check for Applications that no step matches, since they will not roll and must be synced by hand.

Before each step advances, confirm the health of the last Application in the step and the state of any dependent services outside Argo CD.

When the steps are clusters rather than environments, the label usually identifies a cluster group, such as a canary cluster followed by the remaining clusters in the region. Each cluster may run its own ingress, storage and node pool, so a change can look fine on the Argo CD side while one cluster shows a problem that only its own workloads reveal. Step size and order should reflect how much traffic each cluster serves.

Label design: Label each generated Application with a cluster role, such as ring with values for canary and general, or a stable cluster name. Keep the label assignment in the cluster registration so that new clusters join a step without editing the ApplicationSet.
A bad step: A canary step that contains most of the traffic, which defeats the purpose of staging. Another is a step that depends on a cluster add-on not yet present on the next cluster.
maxUpdate for the step: Use maxUpdate to limit how many clusters in a step change at once, so one failure does not reach every cluster in that group together.
Shared dependencies: Verify that databases, queues and certificates used by the next cluster are compatible with the change before its step starts.
Operator visibility: Confirm that the on-call team can see the Argo CD state for each cluster, since a stalled step is reported per Application.

Before the next step starts, check the health of each cluster in the current step and the traffic and error metrics your team uses for that cluster.

Limits to confirm before relying on RollingSync in production

RollingSync is a useful way to stage a change, but its behavior depends on the Argo CD version, release line, and how your generators and dependencies are wired. The cards below list the checks to run in your own environment before a progressive sync touches production applications.

Confirm the Beta status and your version

Progressive syncs have been Beta since v3.3.0, so behavior can still change between releases. Record the exact Argo CD version you run and read the progressive syncs guide for that version before you plan a production rollout. Confirm the feature flag is set the way your platform team expects, whether through the command-line flag, the environment variable, or the applicationsetcontroller.enable.progressive.syncs key in argocd-cmd-params-cm. Repeat this check after every upgrade.

Check the release line receives patches

Argo CD only patches its three most recent minor versions, and a minor release ships roughly every three months. Confirm that the minor line you plan to standardize on is still inside that window, and that your team has a dated plan to move to a newer minor before the line stops receiving patches. A RollingSync rollout that depends on a version past its patch window carries an unpatched control plane through every step.

Test generator changes against existing Applications

Progressive syncs act on Applications generated by an ApplicationSet, so a change to the generator, template, or labels can alter which Applications fall into which step. Before you merge a change, render the ApplicationSet in a non-production instance and compare the generated Application names, labels, and sources with what is running now. Pay attention to Applications that are already out of sync, since those can be the first to be picked up by a step.

Decide what happens when Healthy is never reached

RollingSync waits for each step to report Healthy before it moves on, so an application that never becomes Healthy can hold the entire rollout. Test a deliberately failing step in a lab and observe how long the rollout stays blocked, what status it shows, and how your team is alerted. Document who may override the stuck step, and how to roll back a partially applied change without leaving later steps half updated.

Plan for Applications that match no step

Applications that do not match any step's label selector are not synced by the progressive rollout, and automated sync is turned off for the generated Applications. Run a query across your clusters for each ApplicationSet to find Applications with no matching step label. Assign each one a deliberate owner and a manual sync procedure, so a change does not reach some environments while silently skipping others.

Test deletion order against real dependencies

With deletionOrder set to Reverse, Applications are deleted in the reverse order of their steps. That order is only safe if the steps mirror real dependencies, such as a database or shared service that must outlive the workloads that use it. Rehearse a deletion in a staging environment that mirrors production dependencies, and confirm that resources with finalizers and external data stores are removed in an order your data owners accept.

How access control and trust limit who can drive a staged rollout

A RollingSync rollout is only as trustworthy as the people and repositories that shape it, so the first decision is who can edit the ApplicationSet. The strategy block with its steps, matchExpressions and maxUpdate values decides which Applications move first, how many move at once and when the rollout pauses. Anyone who can change that resource can change the order of environments, remove a gate or raise maxUpdate to 100 percent, so write access to the ApplicationSet should sit with the same owners who approve production changes. Confirm how your Argo CD RBAC policies and Projects grant create and update rights on ApplicationSets, because the generated Applications inherit the rollout's intent but not the approval trail of the people who edited it.

Manual control matters just as much. Progressive syncs turn automated sync off on generated Applications, and any Application that no step matches must be synced by hand. That makes the manual sync permission a rollout control in its own right: whoever holds it can push a change into an environment that the steps were meant to hold back. Review which roles can sync Applications in each Project, and which roles can override a sync window, since windows still apply to RollingSync steps. Since the 2.14 to 3.0 change, update and delete RBAC applies only to the application itself, so a rule that once covered an ApplicationSet's children needs to be rewritten against each generated Application's name and Project. Test this with a non-administrative account before the first production rollout.

The Git source behind the ApplicationSet is the other trust boundary. The security documentation notes that the repo-server runs Helm and Kustomize on repository content, so a repository that the team does not control can change what gets rendered, and a step that looks correct in the ApplicationSet can still deploy unexpected manifests. Restrict who can merge to the repositories feeding both the ApplicationSet and the Applications it generates. On the access side, Argo CD authenticates API calls only with JSON Web Tokens and redacts cluster, Git and OAuth2 credentials from API responses and logs. Those protections do not stop a user with valid rights from misusing them, so keep audit logs of who approved and synced each step, and confirm with your own security team how JWT lifetimes and token revocation are set for rollout operators. The Argo CD security documentation lists the controls the project states.

What buyers ask about RollingSync setup, effort and support

What drives the cost of setting up RollingSync progressive syncs?

The cost follows the number of applications, clusters and environments that the steps must cover, plus how much of the existing Argo CD setup has to change first. Scope is the main driver: a single ApplicationSet with two label-based steps is a very different job from a multi-environment rollout that touches generators, RBAC and notifications. You pay for discovery of how applications are labeled today, design of the step order, enabling the controller flag, testing against non-production clusters, and handover to your team. Recurring costs appear only if you buy a retainer for upgrades or ongoing testing. Ask for a written scope that lists the applications in each step, the environments included, and whether the work covers only configuration or also runbooks.

How long does a RollingSync setup take?

Duration depends on scope rather than on the feature alone, because enabling RollingSync is a small configuration change while labeling, testing and approval take most of the time. The main variables are how consistently applications already carry the labels you want to match, how many steps and environments the rollout has, and how quickly your change process approves non-production and production runs. Ask any partner for a timeline tied to specific deliverables in the written scope, and confirm which dates depend on your team, such as cluster access, pull request reviews and change windows. This page does not give a duration figure.

What does our team need to provide before a RollingSync engagement starts?

The client team usually provides access and decisions rather than hands-on build time. Plan for the following:

Read access to the Argo CD instance, the ApplicationSet definitions and the Git repositories that hold them
Admin or change-approved access to the argocd-cmd-params-cm ConfigMap or the controller flag, and a non-production cluster for testing
A written label standard that defines the step keys and values, and who owns it
Explicit approval to run a Beta feature, since progressive syncs are Beta from v3.3.0

Confirm these items in the scope so that delays are not billed as new work.

Can our in-house platform team set up RollingSync without outside help?

Yes, a team with working knowledge of Argo CD ApplicationSets can enable the feature and write a first RollingSync strategy, using the upstream progressive syncs guide. Outside help tends to add value where the rollout spans several clusters, where label standards are not yet consistent, or where the team needs a tested deletion order and a documented rollback path before production use. Ask whether your team has someone who has already written a RollingSync strategy, and whether they can own the step design after handover. A fixed-scope engagement can cover the first build and knowledge transfer, leaving your team to run it.

How do we manage the risk of using a Beta feature in production?

Progressive syncs are Beta since v3.3.0, so treat the feature as a controlled capability rather than a default. Keep it behind the explicit enablement setting, test each step order in a non-production environment, and keep a manual sync path documented for applications outside the steps. Confirm the Argo CD version you run, because the project supports only the three most recent minor versions with patch releases. Ask a partner how they track Beta behavior changes across upgrades and whether the scope includes a review before each minor version upgrade.

What does a fixed-scope RollingSync engagement cover compared with a retainer?

A fixed-scope engagement covers defined deliverables, such as enabling the controller setting, designing the steps, configuring maxUpdate and deletion order, testing, and a handover document, all agreed in writing before work starts. A retainer covers ongoing support, such as upgrade reviews, Beta changes, and continuous testing of rollout order as applications change. Most buyers begin with fixed scope and add a retainer only if their rollout pattern keeps changing. Ask for the list of deliverables, acceptance tests, what happens when scope changes, and how upgrade reviews are priced. DeployOpen does not publish a price list, so the quote follows from the written scope.

How DeployOpen scopes and delivers RollingSync rollouts

DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, including Argo CD. For ApplicationSet progressive syncs with RollingSync, we start from your release order, health signals and change controls, then build the step design and verify it in your own clusters before handover.

How we scope

We map which clusters, environments and Applications belong in each RollingSync step, using the labels your teams already maintain.
The written scope states the Argo CD version, the enablement method, and the maxUpdate limits agreed for each step.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts. Ongoing support is available as a retainer.

How we build

We enable progressive syncs in your Argo CD installation and confirm the feature flag is set in the way your platform team manages configuration.
We define label-based steps and test each step's health gating against Applications that behave like your production workloads.
We check sync window interaction, deletion order and the manual sync path for Applications that fall outside every step.

How we hand over

You receive the ApplicationSet definitions, step configuration and a written runbook for changing step membership and limits.
Documentation covers why generated Applications run with autosync off and how your team re-enables manual sync for each rollout.
We walk your engineers through a test rollout and a deliberate failed-health stop so they can read and act on the behavior.

How we support

Support can cover upgrades when Argo CD moves to a newer minor release, including re-testing progressive sync behavior.
Continuous checks can confirm that step labels still match new Applications as your cluster inventory changes.
Confirm with us during scoping which support level, response expectations and upgrade coverage your retainer includes.

Argo CD ApplicationSet progressive syncs with RollingSync