Built-in Argo CD capabilities that change how teams roll out and watch applications across many clusters: ApplicationSets and Notifications.
How the bundled ApplicationSet controller and its List, Cluster, Git and Matrix generators template Applications across many clusters and repositories, and what a partner sets up: generator design, cluster registration, RBAC and rollout guardrails.
Setting up Argo CD Notifications: triggers and templates in argocd-notifications-cm, secrets for each service, subscription annotations on applications and projects, and alerting on failed or degraded syncs.
Ordering a rollout with sync phases, waves and hooks: PreSync database migrations, PostSync smoke tests, SyncFail cleanup, the default wave and delay between waves, and the hook deletion policies that keep jobs from piling up.
Blocking or allowing syncs by schedule: allow and deny windows in cron format with time zones, matching by application, cluster or namespace, the manual sync override, and how overlapping windows resolve during a release freeze.
Committing rendered Helm or Kustomize output to Git before Argo CD syncs it: enabling the commit server, separate push and pull credentials, staging branches for pull request promotion, commit tracing, and the current limitations.
Using an OCI registry instead of Git as the application source: oci and Helm-over-OCI repository credentials, accepted layer media types, the single-layer rule, pushing manifests with ORAS, and path rules for OCI Helm charts.
Keeping an upstream Helm chart and your environment values in different repositories with the sources field and the $values reference: how sources combine, the last-source-wins rule, and when ApplicationSets are the better fit.
Rolling a change across environments or clusters step by step with the RollingSync strategy: enabling the feature, label-based steps, maxUpdate limits, deletion order, and why generated Applications lose automated sync.
Creating a short-lived environment for every open pull request with the ApplicationSet Pull Request generator: supported Git providers, label filters, polling versus webhooks, and cleanup when the pull request closes.
Letting teams create Application resources in their own namespaces instead of the argocd namespace: enabling application.namespaces, sourceNamespaces on projects, RBAC naming, annotation tracking, and the security mistakes to avoid.
Running syncs as a less privileged service account per destination instead of the control plane account: enabling impersonation, destinationServiceAccounts matching order, strict enforcement, and what 3.5 extended beyond sync.
Rendering manifests with tools Argo CD does not ship, such as a templating wrapper or an internal generator, through sidecar Config Management Plugins: plugin.yaml discovery and generate commands, parameters, and the trust you hand the plugin.
Choosing how far Argo CD acts on its own: automated sync, prune and allowEmpty, self-heal against manual cluster changes, retry with backoff, the reconciliation interval, and why rollback is unavailable once automation is on.
Bootstrapping a new cluster with one parent Application or a cluster-generator ApplicationSet: when each fits, the admin-only security rule for the parent repository, cascading deletion finalizers, and ignoring drift on child apps.
What changes when Argo CD deploys a Helm chart instead of helm install: rendering with helm template, how Helm hooks map to sync phases, value file precedence, release names and passing repository credentials.
Teaching Argo CD when a custom resource is really healthy: built-in checks, Lua scripts under resource.customizations.health, restoring Application health for app of apps, and excluding a noisy child from application health.
Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.