The framework is free.
The engineers aren't.
Beryl runs on Playwright, so this isn't a rivalry. Playwright is the engine. It runs a test, and leaves the rest to you, including writing the tests, storing them, keeping them working, logging in, reading email codes, scheduling runs, and sharing results with the team. Beryl takes all of that on, and every test stays a normal Playwright file you can export any time.
Beryl runs on Playwright. Playwright is the engine. It runs a test and leaves writing, storing, maintaining, scheduling, and sharing the tests to you. Beryl takes all of that on, and every test stays a Playwright file.
Where they differ
| Beryl | Playwright | |
|---|---|---|
| What it is | A testing service on top of Playwright. Your AI coding assistant or Beryl's AI agents write the tests, Beryl runs and repairs them | A free, open-source tool for driving a browser from code |
| How they relate | Every Beryl test is a normal Playwright file, run in real Chrome | The engine underneath |
| What a test looks like | The steps, what the test is for, and what it must prove, in natural language | Every step, selector, and assertion written and read as raw Playwright code |
| Setup | Everything handled, from creating the test account to keeping it signed in. Accounts, sessions, authentication, timeouts, retries, browsers | Accounts, sessions, authentication, timeouts, and retries are yours to set up |
| Test accounts | Created automatically, or bring your own. Signed in once per run and reused everywhere | You create or provide the test accounts manually |
| OTP, 2FA & login links | Built in. Each project has its own inbox, so OTP, two-factor, and magic-link flows just work; password credentials supported too | Not covered. You store credentials, wire an email service for codes, and script every step yourself |
| When a test fails | Screenshots, trace, and replay saved per run and shared with your team in Beryl; no passing trace files around | Trace and report stay on the machine that ran it; nothing is kept per run or shared with the team |
| When the UI changes | Cosmetic drift and flaky tests repair themselves; real breaks stay red | You repair every test by hand, whatever the cause |
| Run history | Pass rates and flaky-test trends per project and environment | Only runs; no history or trends |
| Scheduling & alerts | Daily or weekly runs per environment; Slack alerts on failures | None |
Why teams put Beryl on top
- Tests start as plain English. Describe the flows in a document and Beryl's cloud agent authors a test for each one
- Runs happen in real Chrome in Beryl's cloud, triggered from your agent, a schedule, or CI
- Logins, email codes, and login links are handled by a built-in test account and inbox
- Daily or weekly runs per environment, with Slack alerts when something fails
- When the UI drifts, cosmetic breaks are repaired and real breaks are flagged
- Screenshots, traces, and replays for every run, shared with the whole team
- Every test stays a normal Playwright file; export any time
Common questions
Is Beryl a replacement for Playwright?
No. Beryl runs on Playwright: every Beryl test is a standard Playwright test file executed in real Chrome. Beryl adds the parts Playwright leaves to you: writing the tests, test accounts and logins, scheduling, healing, and sharing results with the team.
Who writes the tests?
Your AI coding assistant (Claude Code, Cursor, and others) over the Beryl MCP, or Beryl's own cloud agent. You describe the flow in plain language; the test is authored, run, and kept healthy for you.
Can I export my tests and leave?
Yes. beryl tests export gives you the Playwright files, and they run anywhere Playwright runs. There is no proprietary runtime to migrate off.
How does Beryl handle logins, OTP codes, and magic links?
Each project gets durable test accounts and its own inbox. Beryl signs in once per run, reads OTP and magic-link email itself, and reuses the session across tests. In plain Playwright you script all of that yourself.
What happens when the UI changes?
Cosmetic drift (a moved button, a renamed label) is healed from the test's recorded intent and the run stays green. A real break stays red and is reported with screenshots, a trace, and a replay.