Argo Workflows v4.0.8 - CLI and Controller Installation

Argo Workflows v4.0.8 was published on July 22, 2026. The main operator facing detail is the availability of CLI binaries and a controller and server install manifest tied to the same tag. This is a stable release, not a prerelease.

The full release notes and downloads are on the GitHub release page.

The documented CLI path downloads a compressed binary with curl, expands it with gunzip, makes it executable, and moves it into /usr/local/bin/argo. The final argo version command gives operators a direct check that the installed binary starts and reports its version. That check is worth keeping in automated image builds because the download and installation steps otherwise complete without validating the executable.

The shell fragment selects darwin when uname -s returns Darwin; every other result selects linux. It then requests argo-$ARGO_OS-amd64.gz. The example is therefore specific to amd64. It does not provide an architecture detection branch or show an alternative artifact for other CPU types.

The release notes also omit checksum or signature verification steps. That does not establish that verification material is unavailable. It means the provided quick start is only a download and execution path. Platform teams that mirror release assets or build internal images still need their normal artifact verification controls around this example.

For cluster installation, the release creates the argo namespace and applies the tagged install.yaml with kubectl. Both the controller and server are covered by that manifest path. Pinning the URL to v4.0.8 makes the input repeatable, which is preferable to applying a manifest from a moving branch.

The instructions are intentionally short. They do not enumerate the resources in the manifest, explain RBAC scope, list CRD schema changes, or describe controller configuration differences. They also do not separate a fresh installation from an upgrade of an existing Argo Workflows deployment. Operators should inspect the tagged install manifest before applying it to a managed cluster, especially where CRDs and cluster scoped permissions are controlled by a separate deployment pipeline.

The two commands also perform direct cluster mutations. In production, the same tagged manifest can be placed behind GitOps or another reviewed deployment path. The important release detail is the immutable source URL, not the use of an interactive kubectl apply command.

The release page has headings for breaking changes and known issues, but it does not list a release specific breaking change, fix, security item, or migration step. Instead, it points readers to the general upgrading guide and the project issue tracker. The release is not marked as a prerelease, but that status is not a substitute for an upgrade impact assessment.

The same limitation applies to behavioral changes. The notes redirect readers to the project changelog and blog without summarizing what changed in v4.0.8. From this release page alone, operators cannot determine whether workflow execution, artifact handling, persistence, scheduling, or API behavior differs from their deployed version.

For a production rollout, compare the tagged manifest with the currently deployed resources, read the relevant upgrading guide entries, and confirm the CLI and controller report the intended version. The published quick start is enough to locate and install the artifacts. It is not a complete change record or migration plan.