Argo CD 3.4 to 3.5 upgrade

Every custom UI extension built against the earlier React setup must be rebuilt, because Argo CD 3.5 requires extensions to externalize react/jsx-runtime for React 19. Count your extensions before planning, and note which ones your teams depend on day to day. Each extension needs a build change, a test in a non-production instance, and a check that it still renders on the pages it targets. An extension owned by a team outside the platform group adds coordination time, since that team must rebuild and retest it on the same schedule. Extensions that are no longer used are better removed than rebuilt, which shortens the list before the work starts. Confirm the exact build steps in the 3.4 to 3.5 upgrade notes against your own extension code.

They can, because Argo CD 3.5 moves to Helm v4, and plain-HTTP OCI registries may need the --insecure-oci-force-http flag. OCI dependency registries must also be registered explicitly. The effort depends on how many registries serve plain HTTP, how many charts pull dependencies from OCI, and whether those registries are internal or shared. Each registry needs a connectivity test from the repo-server, a decision on whether to move it to TLS, and a review of every Application that references it. Teams that pin charts to older versions should also test those charts under Helm v4 before cutover. List every chart source your Applications use, including nested dependencies, since missed sources tend to surface only during a sync.

Yes. Argo CD 3.5 deprecates signatureKeys, the add-signature-key and remove-signature-key commands, and --repo-server-strict-tls. Both still work with warnings, but they may be removed in 3.6 or later. If your installation uses GnuPG signature keys, the work includes designing Source Integrity rules, testing them per source, and retiring the old keys. If you use the strict TLS flag, you must move to --repo-server-ca-cert-path and confirm that the repo-server trusts the right CA for every repository. Teams that defer these changes until a later release often face a larger batch of changes at once. Check which of these settings appear in your Argo CD configuration and in any automation that runs the deprecated commands.

The work grows with the number of clusters, projects and service accounts that rely on impersonation, because 3.5 extends impersonation to all server operations. Each cluster and project that uses impersonation needs its RBAC reviewed to confirm that the impersonated identity has the rights it needs for operations it previously did not perform through impersonation. A single shared project with few clusters is quick to review. Dozens of projects spread across many clusters require a repeatable test matrix and a review by the owners of each team's access. Plan the review before the upgrade so you do not find denied operations after cutover. The exact operations covered are described in the 3.4 to 3.5 upgrade notes.

Any integration that reads Argo CD's gRPC event APIs must be checked, because 3.5 changes those APIs to an Argo CD EventList type. Typical consumers include internal dashboards, notification or audit pipelines, and custom controllers that watch Applications through the API. Inventory each consumer, identify the client library or generated code it uses, and confirm whether it parses the event response directly. Consumers built by other teams or vendors may need a version bump from their owners, which adds lead time. Test each integration against a non-production 3.5 instance and check that events still arrive with the fields your monitoring depends on.

It can, because the install method determines how the new version reaches the cluster and how you roll back. An instance that manages its own manifests from Git must bump the version in its base and reconcile that change without losing control of itself. A Helm-managed instance depends on the chart version and the Argo CD version it ships, so both upgrade notes must be read. An HA installation adds replicas, controller sharding and Redis behavior to the rollout, so replica counts and node anti-affinity must be checked afterward. Each path needs its own backup and rollback plan. Confirm with your platform team which installation method you use, since that choice sets most of the sequence.

Your own team can handle it if it has time to read both upgrade notes, inventory the affected extensions, sources, clusters and consumers, and test on a non-production instance. A partner is useful when the inventory is large, when several teams own extensions or integrations, or when the change window is short. DeployOpen plans, implements, tests and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask any partner to show the written inventory, the test plan and the rollback steps before you agree on scope.

A quote should list each cost component and who is paid for it: inventory, extension rebuilds, registry and chart changes, security setting migrations, impersonation review, integration testing, the cutover, and documentation. Ask which items are one-time work and which recur, such as ongoing support or patch planning. The quote should state what drives its size, including the number of extensions, registries, clusters, projects and integrations in scope. DeployOpen does not publish a price list, and a quote follows from the written scope. Ask for assumptions in writing so you can see what changes the price.

No fixed price applies, because the cost follows the work in your environment. The main drivers are how many Argo CD instances you run, how many OCI registries and Helm chart dependencies use plain HTTP or need registration, whether you run custom UI extensions that must be rebuilt for React 19, and whether you still use GnuPG signature keys or the --repo-server-strict-tls flag in scripts and pipelines. Upgrades on a single instance with standard manifests are much smaller than upgrades across several clusters with custom tooling. Ask any partner for a fixed-scope quote built from a written inventory of those items. Expect the quote to separate one-time work (inventory, testing, cutover, documentation) from recurring work (patching and support), which you can request as a separate retainer.

Duration depends on the same drivers as cost: instance count, the number of integrations and the state of your test environment. Teams with a current non-production instance and a short list of changes can usually plan the work as a sequence of checks rather than a large project. Teams that must rebuild UI extensions, migrate OCI registry configuration for Helm 4, or replace deprecated signing configuration will need longer for build and test cycles. Before you commit to a date, read the upgrade notes for 3.5 and confirm each affected item in your own environment. Argo CD releases ship roughly every three months according to the project's release process, so plan your upgrade window around the next patch and minor releases rather than a fixed calendar date.

The work needs people who own three things: the Argo CD configuration (projects, RBAC, SSO and repository definitions), the cluster and network access used for testing, and the change approval for production. You will also need a named owner for each external dependency, such as the OCI registry, the Helm chart repository and any custom UI extensions. Provide access to a non-production Argo CD instance that mirrors production as closely as possible, along with a current backup of Argo CD resources. Ask your partner to produce a written list of what they need from your team before work starts, so approvals and access requests can begin early.

Yes, a team with Kubernetes and Argo CD experience can perform the upgrade alone, provided it reads the 3.4 to 3.5 notes in full and tests each change. The risks are mostly in the details: impersonation now covers every server operation, so service accounts and automation may need new permissions, and deprecated flags still work but generate warnings that will become failures in a later release. Outside help is most useful for a structured inventory, a repeatable test plan, and documentation that auditors can review. Whichever route you choose, record the decisions and evidence from the upgrade so the change is traceable.

According to the Argo CD release process, only the three most recent minor versions receive patch releases. When 3.5 ships, you should confirm with the project's release notes which patch releases are still published for 3.4, and plan to move off it within that support window. The GitHub releases page lists current patch releases, and the release cadence page explains the schedule. Keep 3.4 in production only while patches are available for it, and treat a 3.4 instance without patches as an unpatched system in your risk register.

Argo CD 3.5 deprecates signatureKeys, the add-signature-key and remove-signature-key commands, and --repo-server-strict-tls. All of them still work with warnings, but the upgrade notes say they may be removed in 3.6 or later. Because the removal version is not fixed, do not wait for an error. Replace --repo-server-strict-tls with --repo-server-ca-cert-path, and move signature checks to Source Integrity. Search your manifests, scripts and pipelines for these names before the upgrade, and check the 3.5 notes for the exact replacement steps.

Impersonation now applies to all server operations in 3.5, so any automation that calls the Argo CD API or CLI with restricted identities may be refused operations it previously completed. Test every pipeline, bot and service account against a non-production instance before cutover, and review the RBAC policy each one uses. Also check the gRPC event API change, which moves to an Argo CD EventList type, if you have tools that consume those events. Ask your team to list each automated caller and its expected operations, which gives a concrete test plan for the upgrade.