Every preview deploy, actually opened.
Vercel already builds a preview for each pull request. Kery is the part that signs in, walks the flows the change touched, and tells you whether they still work.
A preview URL nobody opens
The Vercel bot comments a preview link on every pull request. In theory somebody clicks it and walks the flow. In practice the link gets opened for visual changes and skipped for everything else, which is a shame, because it is the most accurate representation of the change that will ever exist.
Kery treats that preview as the thing to test against. Not staging, not a mock, not a local build — the deployment produced by this specific pull request.
Where Next.js apps tend to break in the browser
- Middleware auth bounces. A redirect rule that works logged in and loops logged out, or vice versa.
- Client transitions. The page renders on hard load and breaks on soft navigation, or the other way round.
- Streamed segments and loading states that never resolve on a slower connection.
- Server action failures that surface as a form that simply does nothing.
- Layout shifts from next/image and font swaps, which only show up at real viewport sizes.
- Env drift between preview and production, where the build is fine and the runtime is not.
None of these are visible in a diff. All of them are obvious within seconds of a browser actually walking the flow.
Protected previews are the normal case
Most real Next.js apps put the interesting flows behind two layers: Vercel deployment protection on the preview itself, then your own auth inside the app. Agents that drive browsers typically stop at the first and give up at the second.
Supported out of the box
Vercel preview protection, form login, Clerk, Supabase Auth, Auth0, Firebase, 2FA codes, and magic links. Configure the environment and credentials once per project.
What connecting looks like
- Install the GitHub App on the repository. No workflow YAML.
- Point Kery at the environment — preview URL pattern and test credentials.
- Open a pull request. Kery picks up the preview deployment and runs the flows the diff touches.
- Read the verdict on the PR, with video seeking to the deciding step.
Prefer to run it yourself? The engine is open source and runs locally with Docker against
next dev.
Next.js specifics.
How do I run end-to-end tests on a Next.js app without writing them?
Point Kery at the app and connect the repo. It reads each pull request, works out which flows the change touches, and walks them in a real browser against that PR's preview deployment. There is no spec file, no fixture, and no selector to maintain.
Does Kery work with Vercel preview deployments?
Yes — that is the default target. Each pull request gets its own preview URL, and Kery runs against that rather than a shared staging environment, so the check matches the change under review.
Can it get past Vercel deployment protection?
Yes. Protected previews are supported, along with form login, Clerk, Supabase, Auth0, Firebase, 2FA codes, and magic links.
Does it handle the App Router and Server Components?
Kery drives a real browser, so it sees whatever the user sees — streamed segments, client transitions, loading states, and route handlers included. It does not need to know how the page was rendered.
What about middleware redirects?
Those are exercised the same way a user would hit them. Redirect loops and auth bounces show up as a real browser navigating, which is usually how they get noticed in production too.
Can I run it locally against next dev?
Yes. The open-source engine runs with Docker and can point at your local app, which is useful for building out flows before wiring up the PR checks.
Put proof in every pull request.
Connect a repo and Kery starts checking pull requests against their preview deploys. No test scripts, no CI config.