Every pull request, actually run.
Code review tells you the diff is plausible. A browser pass tells you the change works. Kery adds the second one to every pull request, automatically.
Approving a diff is not the same as opening the app
A reviewer can catch a bad abstraction, a missing null check, or a query that will not scale. What no reviewer catches by reading is that the submit button now sits behind a modal, that the redirect loops for logged-out users, or that the empty state renders as a blank page.
Those are browser facts. They need a browser to find them, on every pull request, not on the ones somebody had a spare twenty minutes for.
What happens when a PR opens
- Kery reads the diff and works out what the change is claiming to do.
- It waits for the preview deployment built for that pull request.
- It signs in using the environment and credentials you configured once.
- It walks the flows the change touched in a real browser, recording throughout.
- It posts each check back to the PR with a verdict and video of what happened.
- Contradicted checks fail the build. Everything else is reported.
Why it does not block on a maybe
A gate that fires on uncertainty gets disabled within two weeks — every team that has run a flaky required check knows exactly how that story ends. So the bar for failing a build is deliberately high: the run has to have disproved something the pull request claimed.
Reported vs. enforced
Everything Kery notices lands on the pull request, so a reviewer can weigh it. Only a direct contradiction turns the check red. The result is a gate people leave switched on.
The artefact outlives the conversation
Each check carries a recording, logs, and repro context, and "watch this moment" seeks straight to the step that decided the verdict. That matters a week later, when someone asks whether this was already broken before the release.
How PR checks work.
How do I automatically test every pull request in a browser?
Install the Kery GitHub App on the repository. Each pull request is picked up along with its preview deployment, the flows the diff touches get walked in a real browser, and the verdict is posted back to the PR. There is no workflow file to write.
Does this require CI configuration?
No. Kery Cloud runs the checks itself against the preview deploy. If you would rather own the pipeline, the open-source engine runs in your existing CI with Docker.
What actually fails the build?
Only a contradicted check — a claim the pull request made that the browser run actively disproved. Ambiguous or low-confidence findings are reported on the PR rather than enforced, so merges do not get blocked on a maybe.
How does Kery know what to test?
From the diff. It reads what changed, infers what the change is claiming to do, and derives the flows worth walking. You can also save specific flows in plain English and have them run every time.
Does it get noisy over time?
It gets quieter. Kery keeps a model of your app's routes and conventions and remembers findings you have marked as false positives, so repeats drop off run after run.
What if a PR has no preview deployment?
Kery can run against a configured environment instead, or locally through the open-source engine. Preview deploys are the default because they match the change under review most closely.
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.