CI integration

Snapvisor is designed to run inside the CI you already have: your pipeline uploads screenshots, Snapvisor diffs them and posts a status check back to the pull request on GitHub or GitLab.

Access tokens

Snapvisor has two kinds of credentials — using the right one keeps CI uploads and agent access cleanly separated:

• Project token (the ARGOS_TOKEN you set in CI) authenticates screenshot uploads for a single project. It is upload-scoped: it can send builds, but it cannot read the API or drive the MCP server. Find it under your project's settings; store it as a CI secret and rotate it from the same screen if it leaks.
• Personal access token acts on your behalf across the REST API and the MCP server. Create one under Settings → Tokens. Use it for scripts, agents, or any headless MCP connection.

GitHub tokenless authentication

On GitHub Actions your builds can authenticate without setting an ARGOS_TOKEN at all. When a build runs inside a GitHub Actions workflow on a connected repository, Snapvisor trusts the workflow's context to authorize the upload — no long-lived secret to store or rotate.

Requirements:

• The project must be connected to its GitHub repository.
• The build has to run in that repository's GitHub Actions — not a fork or an unrelated CI provider.

Tokenless authentication is a per-project switch; disable it if you want every CI run to set an explicit token. For a middle ground that still avoids a static secret, Snapvisor also supports short-lived GitHub OIDC tokens.

Parallel testing

Large suites run faster when sharded across machines. Snapvisor groups the shards into one build so review stays a single, coherent step.

Each parallel shard uploads its screenshots as a batch tagged with a shared nonce, so Snapvisor knows they belong to the same build. The build tracks how many batches it expects against how many it has received; once every batch lands, the build finalizes and the comparison runs across all shards at once.

Two modes decide when a parallel build is complete:

• Automatic — you declare the total shard count up front. The build finalizes on its own once that many batches arrive, and aborts after a timeout if the last batch never does.
• Manual — the shard count isn't known ahead of time, so the build stays open until you run an explicit finalize command:

# after every shard has uploaded its batch, close the build
npx @snapvisor/cli finalize

Parallel builds behave like any other build once finalized — they diff against the same baseline and post a single check to your pull request. Combine them with summary checks to require the whole run before merge.

Notifications

Snapvisor can send Slack and email notifications when a visual regression lands on a branch you watch.