Argo CD 3.0 to 3.1 upgrade

Each OIDC client that uses PKCE needs its redirect URIs updated, so more clients means more change requests and more testing. In Argo CD 3.1 the server handles the authorization code flow whether or not PKCE is enabled, and when enablePKCEAuthentication is set, the /auth/callback endpoint must be added to the OIDC client's redirect URIs. Each identity provider team may own its own change ticket, so coordination adds time even when each edit is small. Ask which clients front Argo CD, who approves changes to them, and whether any run through Dex or a direct OIDC connection, since that determines how many owners you must reach.

Argo CD 3.1 deprecates the v1 resource actions API in favor of /api/v1/applications/{name}/resource/actions/v2, so every pipeline, bot or runbook that calls the old endpoint needs review and retesting. The more automation that depends on the old path, the more owners must confirm their jobs still work. Teams usually find these callers only after a cutover, so a full inventory of CI jobs, cron tasks and internal tools that call the API is the main effort driver. Ask for a list of every client that sends requests to the resource actions path before scheduling the move.

Argo CD 3.1 returns a 500 error for out-of-bounds symlinks in the --staticassets directory, so an instance with customized UI assets that link outside that directory will fail until the links are fixed. The effort depends on how many asset files exist, how they were added (by hand, by a Helm values file or by a custom image), and whether anyone still knows why each link was created. Teams with no custom assets face little work here. Check the asset directory for symlinks that point outside its tree before the rehearsal, and record which ones carry branding or other customizations.

Yes. Argo CD 3.1 removes project-scoped repository and cluster credentials from project API responses, as described in GHSA-786q-9hcg-v9ff. Any integration that reads those fields to find which credentials a project uses will stop receiving them, so more clusters, projects and applications mean more places to check. Consumers may include dashboards, inventory tools and deployment scripts. Ask which systems read project API output, and whether any of them depend on credential fields, before scheduling the change.

It usually does, because each extra component changes the rollout order and the number of checks. An HA installation runs several replicas across at least three nodes, and the controller can be sharded, so each replica needs confirmation after the change. A self-managed instance, where Argo CD deploys its own manifests from Git, adds steps to update the source of truth and to recover if the new controller fails to start. A single-replica, non-self-managed installation has the fewest moving parts. Confirm the replica count, whether Argo CD manages itself, and where its manifests live.

A rehearsal environment shortens the upgrade by letting you find failures on copies of your real SSO settings, API clients and asset files rather than in production. Without one, the same discovery happens during the change window, which extends the outage risk and the rollback effort. The rehearsal needs a copy of the configuration, representative applications and a current Argo CD version matching production. Ask whether a staging instance exists, whether its SSO client can use the new redirect URI, and how far it mirrors production clusters.

Approvals add lead time that is separate from technical work, and they multiply when the upgrade touches identity, API consumers and cluster credentials at once. Each affected area may need its own sign-off from identity, platform, security and application owners, plus a documented rollback plan. Regulated organizations often require evidence that the rehearsal ran and that changes were recorded. Ask your change board which approvals a version upgrade requires, how long they usually take, and whether a standard change category applies.

No price is set by the Argo CD project, which is released under the Apache License 2.0 with no paid edition, so the cost is the work to plan, change, test and verify the upgrade. The main cost components are the people who inventory your OIDC clients, redirect URIs, static asset paths, project API consumers and custom scripts, the staging environment and test time, and the change window at cutover. Costs go up when more Argo CD instances, SSO clients or automations call the affected APIs. Costs go down when the instance is small and the usage is documented. A DeployOpen quote follows from a written scope, so ask for the scope items listed in the answer about what the team must provide.

Duration depends on how many Argo CD instances you run, how many applications and clusters they manage, how many OIDC clients use the PKCE flow, and whether anything in your estate calls the v1 resource actions API. The Argo CD project publishes a minor release cadence of four releases a year and supports only the three most recent minor versions with patches, so the timing of your move relative to that window also matters. Ask your delivery partner for a plan that separates inventory, staging validation, production cutover and post-upgrade checks, and confirm the timeline against your own change calendar.

Plan for four kinds of access and decisions before work begins:

• Administrative access to the Argo CD namespace, the Kubernetes clusters it manages, and the Git repositories that hold its manifests.
• Administrative access to your identity provider or bundled Dex configuration, so the OIDC client redirect URIs can be checked and updated.
• Named owners for API consumers, including CI jobs and scripts that call the v1 resource actions endpoint.
• Approved change windows for a staging rehearsal and a production cutover, with a rollback decision owner.

Confirm each item in writing, because a missing identity provider change is the most common reason an SSO login breaks after a move.

Often yes, if the team already runs Argo CD in production and has someone who understands your SSO setup. The upgrade itself is a bounded set of changes, but it touches authentication, API consumers and static asset serving, so the team should review each affected area against its own environment. Teams that lack an owner for the identity provider, or that have many undocumented API clients, usually bring in outside help for the inventory and staging test. Decide early which parts you will own, which parts a partner will carry out under a fixed-scope agreement, and who signs off on the cutover.

Rollback depends on backups and on how the Argo CD state is stored. Argo CD keeps most of its data in Kubernetes objects and treats Redis as a disposable cache, so a backup of the namespace and the Argo CD resources taken before the change is the core recovery artifact. Record the prior image version, the prior OIDC client configuration and the prior API client behavior, then rehearse the rollback in staging. Confirm with the Argo CD upgrade notes and your own test results whether a downgrade is supported for your specific configuration before you commit to it in the change plan.

The Argo CD release process says only the three most recent minor versions receive patch releases, so whether 3.0 still receives patches depends on the minor versions published at the time you read the page. Check the Argo CD release process and the GitHub releases page for the current list of supported minor lines before you plan. Staying on an unpatched minor version leaves security fixes out of reach, so the upgrade decision should be tied to that support window and to your own patch policy.

Engineers should expect SSO sign-in failures if the OIDC client lacks the /auth/callback redirect URI when PKCE is enabled, because the server now handles the authorization code flow in every case. Scripts that call the v1 resource actions endpoint keep working during deprecation but should move to the v2 path. Automation that reads project-scoped repository or cluster credentials from project API responses will stop receiving them, which is intended behavior from the security fix GHSA-786q-9hcg-v9ff. Symlinks in the static assets directory that point outside it now return a 500 error, so check that directory before cutover.