Managed auth providers
Clerk, Supabase Auth, Auth0, and Firebase — including the hosted redirect flows that break naive automation.
Use case
Most agents stop at the sign-in page. That is where the app starts.
Public marketing pages are the easy part. Checkout, settings, permissions, billing and dashboards all sit behind auth, which is exactly where automated browser checks tend to give up.
Everything interesting is one login away
Ask any browser agent to check your product and watch where it ends up: a sign-in form, waiting for a password it does not have, or bounced into a redirect it cannot resolve. The run technically completed. It covered your landing page.
Meanwhile the flows that actually break — a permission that leaks, a billing page that renders empty, a settings save that silently fails — are all on the other side of that form.
Sign-in paths Kery handles
Plain form login
Email and password against your own auth, with the session carried through the rest of the run.
Second factors
2FA codes and magic links, handled as part of sign-in rather than as a reason to stop.
Deployment protection
Vercel preview protection, so per-PR preview URLs are reachable before your own auth even begins.
What breaks conventional setups
- Storage state goes stale. Capture a session fixture, change the auth flow, re-capture. Forever.
- Hosted redirects bounce across domains, which naive selector-based scripts handle badly.
- Second factors are treated as an unsolvable step rather than a step.
- Preview protection blocks the URL before the app is even reached.
- Role coverage gets skipped because setting up three accounts triples the fixture work.
Kery signs in during the run rather than replaying a captured session, so an auth change is just a different sign-in, not a broken fixture.
The same flow, as different people
Permission regressions rarely show up as an error. They show up as an admin-only button appearing for a normal user, or a workspace switcher listing something it should not. Walking the same flow with different configured accounts is how those get caught, and it costs nothing extra once the accounts exist.
FAQ
Auth, credentials and roles.
How do I test flows that are behind a login?
Configure the environment and credentials once, and Kery signs in the way a user would before walking the flow. Form login, Clerk, Supabase Auth, Auth0, Firebase, 2FA codes, magic links, and Vercel preview protection are all supported.
Can it handle two-factor authentication?
Yes. 2FA codes and magic-link flows are handled as part of sign-in, which is usually where automated browser checks stop.
Does this work with Clerk?
Yes. Clerk is one of the supported providers, alongside Supabase Auth, Auth0, Firebase, and plain form login.
Do I need to manage storage state or session fixtures?
No. There is no storage-state file to capture and re-capture every time the auth flow changes. Kery performs the sign-in as part of the run.
Where do the credentials live?
In the environment configuration for the project. Running the open-source engine, everything stays in your own environment — Kery only sends prompts and the context a run needs to the LLM provider you configure.
Can it test different roles or permission levels?
Yes. Configure the accounts you care about and Kery can walk the same flow as different users, which is how most permission regressions surface.
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.