Changelog

New updates and improvements to Argos.

Deployments

Argos Deployments

Deployments turn Argos into a host for your static builds. Run argos deploy ./storybook-static and get a unique live URL on every pull request—no extra infrastructure to maintain.

  • Preview & production environments: PRs ship to immutable preview URLs; merges to your production branch promote to a stable production domain.
  • Stable URLs to share: every deployment exposes an immutable deployment URL, a branch URL that follows the latest build, and—for production—a project-wide domain.
  • Access protection: keep previews private to your team while leaving the production domain public, or lock everything behind Argos login.
  • Built into the PR comment: deployment links sit next to your Argos visual build, with a commit status you can require in branch protection.

Works with Storybook, Vite, Next.js exports, plain HTML—anything that builds to a static directory.

Learn more in the Deployments documentation.

Secure GitHub Actions authentication

GitHub OIDC and tokenless authentication

Argos can now authenticate GitHub Actions uploads without storing a long-lived ARGOS_TOKEN secret in your repository.

With GitHub OIDC, each workflow run receives a short-lived identity token signed by GitHub. Argos verifies the token against the linked repository and workflow, then accepts the upload with credentials scoped to that build.

For workflows where GitHub does not issue OIDC tokens, especially pull requests from forks, the SDK falls back to a more secure tokenless flow. Argos verifies the in-progress workflow run through the GitHub API before issuing a short-lived token.

  • OIDC where available: Enable GitHub OIDC in Project Settings -> Authentication, add id-token: write to your workflow permissions, and remove ARGOS_TOKEN from the job.
  • No long-lived CI secret: Uploads use GitHub-signed identity and short-lived scoped credentials instead of a reusable Argos token.
  • Safer tokenless fallback: Forked pull requests and public repositories can still upload without secrets while Argos checks the repository, commit, branch, and workflow run.
  • One workflow for every PR: Internal PRs use OIDC, while forked PRs fall back to tokenless automatically when OIDC is unavailable.

Learn more in the GitHub OIDC documentation and the GitHub tokenless documentation.

Build reviews from the CLI

Build reviews from the CLI

Argos builds can now be inspected and reviewed from the terminal.

Use the new CLI commands to fetch build metadata, list snapshots that still need review, and submit an approval or request changes without leaving your development workflow.

Install the CLI with npm install -D @argos-ci/cli, then see the CLI documentation for authentication, commands, and examples.

argos build get <build>
argos build snapshots <build> --needs-review
argos build review <build> --conclusion approve

Built for humans and agents

The CLI gives developers a fast way to review Argos builds locally, and gives coding agents a structured way to inspect visual changes during pull request reviews.

Agents can fetch build status, read machine-friendly snapshot data, compare visual diffs against the pull request intent, and help catch regressions before they merge.

From a build page, use the new Copy prompt button to start an agent review with the build URL, pull request context, and review guidance already included.

Reviews submitted from the CLI use personal access tokens and respect existing project permissions.

Tag-based filtering

Tag-based filtering

You can now filter screenshots using tags to focus on the parts of a build that matter.

Tags let you quickly isolate relevant screenshots, whether you’re reviewing a specific workflow, a single Storybook story or a particular environment like mobile.

  • Automatic and custom tags: Use built-in metadata like viewport, browser or color scheme, or define your own tags in the SDK.
  • Test and snapshot tags: Filter based on tags coming from tests or individual screenshots.
  • Composable filters: Combine multiple tags to narrow down results with AND logic.

Read more about tags in the Argos documentation.

Auto-ignore flaky changes

Auto-ignore flaky changes

When a visual change is detected as flaky, the Argos bot now auto-ignores it.

This keeps build reviews focused on real regressions by reducing noise from unstable visual diffs.

  • Enabled by default: Active automatically on all projects.
  • Available on all plans: Included for every Argos user.
  • Customizable: You can configure the number of times a change must be detected as flaky before auto-ignoring it in your project settings.

Read more about flaky changes and how to manage them in the Argos documentation.

SAML Single Sign-On

SAML SSO

You can now configure SAML Single Sign-On (SSO) for your Argos team on the Enterprise plan.

SAML settings are available for team owners in Team Settings -> Security and Privacy. Once configured, team members can authenticate with your identity provider, and users signing in with SAML for the first time are automatically added to the team. It also supports enforcing SAML authentication for team members, and you can share a team-specific login URL that shows only the SAML login option.

Learn more in the SAML SSO documentation.

Subset builds

Argos running on a Playwright test suite with some skipped builds

Subset builds let you run Argos on a partial test suite while keeping feedback focused on what actually ran. When a build is marked as subset, Argos ignores removed screenshots and only reports changed and added screenshots from the tests that executed.

  • Fast feature validation: Skip the full E2E suite on branches without losing visual insight.
  • No false removals: Missing screenshots from skipped tests won’t be flagged.
  • Baseline safe: Full runs on the main branch still power baseline builds.

Learn more in our Subset builds documentation.

Tests dashboard

Tests dashboard showing tests sorted by flakiness

The new Tests dashboard gives you a project-wide view of all tests ranked by flakiness, so you can quickly spot the most unstable areas and focus your efforts where they matter most. It’s another step in Argos’ complete flaky test management, helping teams stay ahead of noisy or unreliable tests.

  • Flakiness-first sorting: Tests are ordered by instability so the biggest problems rise to the top.
  • Project-wide coverage: See every test in one place to understand overall health at a glance.
  • Faster prioritization: Focus on the tests most likely to cause noise in reviews and builds.

Learn more in our Tests dashboard documentation.

GitHub Merge Queue support

Argos GitHub Merge Queue support

Argos now runs inside the GitHub Merge Queue so the visual checks you rely on during pull requests also guard queued merges. With the Argos GitHub App, Argos reads commit history to compute the right merge base and publish required checks, making sure only clean, intentional visual changes land on your protected branches.

  • Queue-aware required checks: Argos computes the merge base against the last approved commit on the target branch and publishes required visual checks along the merge queue path, preventing regressions that only appear after rebases or batched merges.
  • Straightforward setup: Listen to both pull_request and merge_group events so Argos runs for reviews and queued merges.

Read more in our documentation.

ARIA Snapshots in Playwright

ARIA Snapshots in Playwright

Argos now supports ARIA Snapshots with the Playwright SDK, giving you a structured view of your page’s accessibility tree directly in your visual testing workflow.

  • Easily review text changes: You can now easily spot changes in text content.
  • Accessibility insights: Capture the ARIA representation of your pages to detect accessibility regressions over time.
  • Combined or standalone: Use argosScreenshot with ariaSnapshot: true to capture both visuals and ARIA trees, or call argosAriaSnapshot for ARIA-only tests.

This feature helps teams combine visual and accessibility testing in one unified workflow, improving overall UI quality and inclusiveness.

Learn more in the docs