Endless devices.
The tests are still on you.
BrowserStack is a testing cloud. Browser grids, real phones, Percy for screenshot diffs. It runs the tests your team writes and maintains. Beryl is the product that makes those tests exist. They are written, run, and repaired by the AI coding assistant you already use. A device cloud can't help until somebody writes the tests.
BrowserStack is a testing cloud. It runs the tests your team writes. Beryl is the product that makes the tests exist, written, run, and repaired by the AI coding assistant you already use.
Where they differ
| Beryl | BrowserStack | |
|---|---|---|
| What it is | A testing service. Beryl's cloud agent writes the tests from a document you give it, then Beryl runs and repairs them | A device cloud that runs the tests your team writes across browsers and real devices |
| Who writes the tests | Beryl's cloud agent, from a plain-English document describing the flows | Nobody on their side. Your engineers write them in your framework, or QA uses the low-code editor |
| Test framework | Managed. Tests become Playwright tests; export the files any time | Bring your own Selenium, Playwright, Cypress, or Appium suite |
| 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. Inboxes, codes, and links are your test code's problem |
| What a test looks like | Plain JSON your coding agent can read, diff, and fix over the MCP and CLI; every change is proved with a replay before it saves | Framework code in your repo; the grid just runs it |
| When the UI changes | Cosmetic drift and flaky tests repair themselves; real breaks stay red | Only low-code tests self-heal. Your framework suite is yours to fix |
| Scheduling & alerts | Daily or weekly runs per environment; Slack alerts on failures | No scheduler of its own. Your CI triggers runs; alerts go through Slack and Jira plugins |
| CI integration | One command runs tests against a preview URL; pass or fail is the exit code | SDKs and CI plugins; your framework drives the grid |
BrowserStack capabilities summarized from browserstack.com as of August 2026. Verify current capabilities with the vendor.
Why teams start with Beryl
- 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 BrowserStack alternative?
Only if the problem is getting tests written. BrowserStack is a device cloud that runs the tests your team writes across browsers and real devices. Beryl gets the tests written by your coding assistant, then runs and repairs them. Teams often start with Beryl and add a grid later for cross-device coverage.
Who writes the tests?
With Beryl, its cloud agent, from a plain-English document you write; your coding assistant kicks off the job and reviews the result. BrowserStack runs what your engineers write in Selenium, Playwright, Cypress, or Appium, or what QA builds in its low-code editor.
Do I have to manage test accounts and OTP flows?
Not with Beryl. Test accounts are created automatically or brought in, signed in once per run, and each project has its own inbox for OTP, two-factor, and magic-link email. On BrowserStack that stays in your test code.
Can my coding agent stay in the loop?
Yes. Every Beryl command is an MCP tool, so the agent you already use creates tests from a document, triggers cloud runs, reads failures, and fixes a test's plain-JSON plan, with every fix proved by a replay before it saves. On BrowserStack, authoring and maintenance stay in your test code.
Does Beryl schedule runs and alert on failures?
Yes. Daily or weekly runs per environment with Slack alerts on failure, plus a one-command CI gate whose exit code is pass or fail. BrowserStack has no scheduler of its own; your CI triggers runs.