denis256 notes and projects

Argo Workflows v4.0.7 was published on July 7, 2026. This release is not marked as a prerelease, and its GitHub notes are mostly a quick start path for installing the CLI, controller, and server rather than a long list of fixes.

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

A compact release note for operators

The v4.0.7 notes do not enumerate every pull request or internal change. They keep the focus on getting Argo Workflows installed, then point readers to the project blog and changelog for the broader “What’s New” material. That is useful, but it also means readers should not assume a hidden feature list from this page alone.

For teams tracking Argo Workflows in a cluster, the practical signal is clear. This tag has published release assets, a current install manifest, and a CLI download path. The release page also links to the upstream blog and changelog for anyone who needs the larger context before rolling it into an environment.

The absence of inline fix details matters. If you need to justify an upgrade through a change advisory board, this page is the starting point, not the whole paper trail. The release notes say where to install from and where to check for known upgrade material.

CLI install path stays explicit

The release includes a direct Mac and Linux CLI install flow using curl, gunzip, chmod, and a final move into /usr/local/bin/argo. The example detects Darwin first, then falls back to Linux, and downloads the amd64 compressed binary from the release assets for v4.0.7.

That makes the path easy to script for local developer machines and simple build hosts. The commands are plain shell, with no package manager assumed. The final check is argo version, which is the right low friction test after replacing or adding the binary.

The detail worth noticing is the asset naming pattern. The notes use argo-$ARGO_OS-amd64.gz, so anyone adapting the command for automation should keep the operating system value and architecture visible rather than hiding it in a copy pasted URL. Small install scripts age badly when those pieces become implicit.

Controller and server install from release assets

For Kubernetes installation, the release notes use a two command flow. First create the argo namespace. Then apply install.yaml from the v4.0.7 release assets into that namespace.

The manifest URL is tied to this tag, not to a moving branch. That is the main operator benefit in these notes. A pinned release asset gives you a repeatable input for cluster bootstrap, GitOps review, or a controlled manual install.

This is still an install path, not a replacement for environment review. Teams with existing controllers should compare the generated resources against their current deployment model, RBAC, service accounts, and namespace conventions. The notes give the default path. Production clusters usually carry local policy around it.

Upgrade notes

The release page has a specific section for breaking changes and known issues, but it does not list them inline. Instead, it points readers to the Argo Workflows upgrading guide and to existing GitHub issues.

That is a blunt but important instruction. Before moving from an older Argo Workflows version to v4.0.7, operators should read the upgrading guide for version level behavior, then check open issues for anything that matches their controllers, executors, archive setup, or workflow patterns.

The release itself is not flagged as alpha, beta, or a release candidate. Even so, “not a prerelease” is not the same thing as “safe for every cluster without review.” Treat the upgrade guide as part of the release material.

Where to get it

• Release page: Argo Workflows v4.0.7
• Repository: argoproj/argo-workflows
• Tag: v4.0.7