Why UI Verify renders screenshots in the cloud
UI Verify renders every screenshot on its pinned Linux and browsers, so pixels match across machines. That is why it needs an API key and a test to drive the UI.
UI Verify does not screenshot on your laptop or your CI runner. Your test uploads what it captured, and UI Verify renders the screenshot on its own machines: one pinned version of Linux, the browser, and the fonts, the same for every build. That single render environment is what makes a diff mean something.
Why not just screenshot locally?
A screenshot is not deterministic across machines. The same page renders different pixels on macOS versus Linux, on one Chromium version versus the next, and with a different font stack installed - antialiasing, subpixel hinting, and emoji all shift. If every developer and every CI job screenshotted locally, the baseline would change with the machine, not the UI, and the check would flag noise on every run.
Rendering centrally removes that variance. Your baseline is the same commit's pixels from the same environment, so a diff is a real change to the UI and nothing else. Chromatic renders centrally for the same reason: its browser docs (checked 2026-10-17) describe a Capture Cloud that spins up its own Chrome, Firefox, Safari, and Edge machines.
Why does it need an API key?
The API key (uv_proj_...) authenticates the upload and scopes it to your project, so a build lands under the right team and its baselines belong to the right branch. It is a project-level key you set once as a CI secret. Grab it from your project settings and pass it to the uiverify CLI.
Why does a capture need a test?
UI Verify captures a state, and it needs something to drive the UI into that state - a Storybook story, or a Playwright, Vitest, or Bun test that navigates and sets the page up. It does not crawl your app and guess. That is a feature: you decide exactly which states are worth a screenshot, so coverage is intentional and the snapshot count (which is the cost) stays in your control.
- Storybook: each story is a capture. Point UI Verify at your built Storybook.
- Playwright, Vitest, or Bun: each test that drives the page records an archive UI Verify replays and screenshots.
- No test writes the states you want captured - so an agent can write them (see Set up visual testing).
What actually gets uploaded?
For Storybook, the CLI uploads your built bundle and UI Verify renders each story. For Playwright, Vitest, and Bun, the capture SDK records an archive of the page (its DOM and network) at test time, and UI Verify replays that archive in the cloud and screenshots it. Either way the pixels are produced in one place, not on the machine that ran your tests. See How visual regression testing works.
Set up visual testing
From no visual tests to a green check on every pull request.
Visual testing for agents
UI Verify is visual regression testing for Playwright, Storybook, Vitest and Bun. Your coding agent sees what its UI change did and fixes it before it ships. See how it works.
Get started