CI/CD

Every Vercel preview deployment, tested before it merges

Vercel builds a preview for every pull request - Lastest tests it. The GitHub Action fires when the preview is ready, points your recorded suite at the preview URL, diffs every screen against the production baseline, and blocks the merge until you approve what changed. Deterministic replays, $0 in AI tokens per run.

Try Lastest free →Read the docs

What you get

Three things this integration does - and what they mean for your team.

01

Test the preview, not localhost

The suite runs against the real preview deployment - same build output, same edge config, same environment your users would get if the PR merged. What gets tested is exactly what ships.

02

Triggered when the preview is ready

Vercel emits a GitHub deployment_status event when the preview goes live. The workflow fires on success, passes the preview URL to Lastest, and the run starts within seconds of the deploy - no polling, no sleep steps.

03

Merge blocked until diffs are approved

With fail-on-changes enabled and the Lastest check added to branch protection, a PR with unapproved visual changes cannot merge. Approve the diff in the review UI and the check goes green.

How it works

Data flow, configuration, and result routing - visualised.

Diagram 1 · Preview-deploy trigger

From git push to a tested preview

GITHUBVERCELLASTESTPush to PRfeat/checkoutdeployment_statusstate: successPreview buildsame as prodPreview URLenvironment_urlSuite replaysagainst previewPR verdictcheck + diff link1 build2 live3 event4 preview-url5 verdict
Push to a PR → Vercel builds the preview → GitHub receives deployment_status: success → the workflow passes the preview URL to Lastest → the recorded suite replays against the preview and posts the verdict on the PR.

Diagram 2 · Preview vs production baseline

What the diff actually compares

Preview deployPR buildProd baselineapprovedPixelmatchpixelSSIMstructuralButteraugliperceptualunchangedflakynoise · ignoredchangedneeds review
Each screen of the preview deployment is diffed against the approved production baseline across three engines (pixel, structural, perceptual) - so the verdict is about the release, not about runner rendering noise.

Diagram 3 · Merge gate

Blocking the merge on unapproved changes

Diff foundfail-on-changesCheck: redbranch protectionApprove diffnew baselineReject difffix the PRMergecheck greenBlockedstays redhuman review
fail-on-changes marks the check red when a non-flaky diff is found. Branch protection holds the merge until a human approves the change in Lastest - then the check flips green and the PR merges.

Configure

Drop-in config for Vercel

GitHub Actions - run the suite when the Vercel preview is live

name: Visual tests on Vercel preview
on:
  deployment_status:
jobs:
  visual:
    if: github.event.deployment_status.state == 'success'
    runs-on: ubuntu-latest
    steps:
      - uses: las-team/lastest/action@main
        with:
          server-url: ${{ secrets.LASTEST_SERVER_URL }}
          runner-token: ${{ secrets.LASTEST_RUNNER_TOKEN }}
          preview-url: ${{ github.event.deployment_status.environment_url }}
          fail-on-changes: 'true'

Frequently asked questions about Lastest + Vercel

Does this work with Next.js on Vercel?
Yes - Lastest tests the deployed preview over HTTP, so it is framework-agnostic. Next.js, SvelteKit, Astro, Remix, or a static export all work the same way.
How does Lastest know the preview URL?
Vercel creates a GitHub deployment per preview. The deployment_status event carries environment_url - pass it to the runner as the target base URL (--base-url or the preview-url action input).
Do preview runs cost AI tokens?
No. Preview runs are deterministic Playwright replays of tests you already recorded or generated. AI is used only at create-time and fix-time, so testing every preview costs $0 in tokens regardless of PR velocity.
What about password-protected previews?
For previews behind Vercel Deployment Protection, use a protection bypass token and inject it as a header or query parameter in the test environment so the runner can reach the preview.
Can I also test Netlify deploy previews?
Yes - the pattern is identical. Any host that exposes the preview URL to CI (Netlify, Cloudflare Pages, Render) works: pass that URL as the base URL and the same suite runs against it.