The release candidate reached staging on Thursday afternoon, and the testing agent was asked to walk checkout as a shopper, a returning customer and an admin. By evening it had filed a bug saying the coupon field rejected a valid code. Nobody could reproduce it, and the run log said only that an assertion had failed somewhere after login.
A testing agent asks more of its infrastructure than a fixed suite does: a clean browser for every test, a signed-in account for every role, a private copy of the build, and evidence when something breaks. Solari provides all of it from the same account, with cloud browsers driven by standard Playwright, profiles for test accounts, recordings of failed runs and sandboxes that serve the build. This guide follows a testing agent's run from the build to the bug report.
Why Testing Agents Outgrow the CI Runner
The first change is where the browsers live, because a testing agent does not run the same suite every night. It explores a page, writes a regression test for what it found, runs it, reads the failure and tries again, so the number of browsers it needs rises and falls with each release.
On a shared CI runner, every headless browser competes for the same memory, and tests start failing for reasons that have nothing to do with the app. A flaky result costs more with an agent than with a person, since the agent will file it as a bug. Moving the browsers off the runner starts with the app they test.
Booting the Build Under Test in a Sandbox
Before any browser opens, the agent needs a copy of the build that nobody else is changing. A Solari sandbox is an isolated machine created by API: the agent clones the release branch into it, installs dependencies and starts the app's dev server.
previewUrl(port) then returns a public URL for that server, signed with a token that lasts an hour, and that URL is what the browsers open. A request that arrives before the app is listening answers 425 Too Early, so the agent polls until the page loads instead of reporting a dead build. The signed URL is a credential, so it stays out of logs and tickets.
With the build serving, the agent can point browsers at it.
Running the Test Matrix in Parallel
Parallel runs are where cloud browsers pay off, because each test gets its own session rather than a slot on the runner. A Solari session is a real Chrome driven with the standard Playwright API, so tests the agent wrote locally run unchanged. The sketch below opens a recorded session for the shopper role against the preview URL:
A fresh browser per test keeps cookies and storage from leaking between cases, which is the property a test matrix depends on. How many sessions run side by side is a plan setting, and the figure sets out the limits that matter for QA work.
The concurrent-browser row sets the agent's worker count, and the profiles row sets how many test accounts it can keep signed in. Those accounts are the next problem to solve.
Signing In Test Accounts With Profiles
Logging in at the start of every test wastes time and turns the login page into the most-tested screen in the app. Solari profiles save a login, its cookies and site data such as localStorage in Playwright's storageState format, so each role becomes a profile the agent attaches by profileId. A team can upload a storage-state.json it already has, or sign in once through the console editor.
The rule to remember is that a profile seeds exactly the session's default context. A context the agent creates itself with newContext() starts signed out unless session.storageState is applied to it, which suits a logged-out test and confuses every other one.
When a test account's login expires, profiles.edit() returns a link to a live editor, valid for 30 minutes, where a person signs in again and saves. Profiles hold real logins, so test accounts belong to staging and each environment gets its own API key. What remains is the evidence the agent hands over when a test fails.
Recording the Runs That Fail
A report that says "assertion failed" is the dead end from the opening scene, and recordings replace it with something a developer can watch. Session recording is opt-in at launch, as in the sketch above; after the session closes, getReplayUrl() returns a temporary link and downloadReplay() returns a line-by-line log of everything that happened on the page.
The agent attaches both to the ticket, so the coupon bug arrives with the exact clicks that produced it. Recording captures input values by default, which is a second reason to keep test accounts free of real credentials and to leave recording off for any session that types a production secret. With the evidence in place, the whole loop fits in a few rules.
Choosing the Right Setup
A testing agent on Solari runs the same loop each release: serve the build from a sandbox, open a fresh session per test, attach a profile per role and record the runs. The habits that keep results honest are a clean browser per case, test accounts that live only in staging and recordings that never hold a real secret. How to run Playwright at scale in the cloud covers worker setup in more depth, and the Solari introduction explains how browsers, sandboxes and desktops share the same account.
Get Started With Solari
Start by pointing the agent's existing Playwright tests at a Solari session with recording on, then add a profile for each role. Solari is built to be the fastest and cheapest place for that job: its browsers are ready in 8 ms, it is about 2x cheaper than Browserbase per browser hour, and the Free plan's $3 monthly credits cover the first runs. Create a free Solari account and run the next release's tests on it.
