The test suite was quick on a laptop. Then the nightly scraping job grew, the CI runner started swapping memory, and every extra Chromium process slowed the rest down. Someone suggested adding machines, and now there is a fleet of them to patch.
Running Playwright at scale in the cloud means keeping your scripts and moving the browsers off your hardware: each worker connects to a hosted Chrome, drives it with the normal Playwright API, then releases it. Solari runs those browsers as sessions started by API, so the number of parallel runs depends on your plan rather than the size of your CI box. This guide walks through the connection, parallel workers, saved logins, cost and debugging, including the context rule that trips people up.
Why Self-Hosted Playwright Stops Scaling
The trouble starts with how Playwright spreads work. Its test runner uses worker processes, and each worker starts its own browser on the same host. A headless browser has no window, but it still renders pages and runs JavaScript, so memory and CPU set the ceiling long before your test count does.
Sharding across machines lifts that ceiling at the price of images to build and Chromium versions to pin. The scripts were never the problem; where the browsers ran was. That is why the first change is the connection.
How to Connect Playwright to a Cloud Browser
Connecting is the smallest part of the move, because Playwright already knows how to drive a browser it did not launch. On Solari, a session is a real Chrome driven with the standard Playwright API: launch() opens it and connects in a single call, and close() cleans up from a finally block.
If your code already owns its Playwright client, create a session and attach with Playwright's connectOverCDP, which uses the Chrome DevTools Protocol:
Anyone who holds a session's cdpEndpoint or wsEndpoint can drive it until it is released or expires, so keep both out of logs. Because the connection is standard Playwright, teams moving from Browserbase can run their existing code by changing the import. With a single session working, the next question is how many can run at once.
How to Run Many Sessions in Parallel
Parallelism on a hosted fleet is a plan setting rather than a hardware purchase. Each Playwright worker opens its own session, and the plan's concurrency cap decides how many run side by side. The self-serve limits look like this:
The concurrent-browser row in the table is the number to size against: set workers to the cap of your plan, not to your CPU count. Beyond self-serve, Enterprise runs 100,000 concurrent standard browsers on its plan. Stealth sessions carry a separate, lower cap on top of the main limit, and a session over it gets a 429, so a retry with backoff belongs in your worker setup.
Inside each session, Playwright still isolates work with browser contexts, each with its own storage. That isolation helps tests and gets in the way of logins, which is where the next section starts.
How to Keep Logins Across Sessions
Signing in on every run is tolerable for a single script and costly across a fleet, since every worker repeats the login and every login risks a challenge. Solari profiles fix this: a profile saves your login, cookies and site data in Playwright's storageState format. Upload a storage-state.json you already have, or sign in once through the console editor, then pass profileId when you create a session.
The rule that trips people up is about contexts. Attaching a profile seeds exactly the session's default context, and a context you create yourself with newContext() starts empty unless you apply session.storageState to it. Use session.context or session.newPage(), not browser.contexts()[0], which is not guaranteed to be the seeded one.
Since a profile holds a real login, anyone with the API key can act as that account. With logins handled, the remaining questions are money and visibility.
What Playwright at Scale Costs
Cost on a hosted fleet follows open session time. Browsers bill per hour while a session is open, and the Professional plan bills $0.07 per browser hour, with its $200 monthly fee returned as usage credits.
Credits refill each month and do not roll over, and there is no end-of-month overage charge because nothing bills past your balance. Since cost tracks open time, releasing sessions promptly matters as much as the rate, and so does knowing what a failed run did.
How to Debug Runs You Cannot Watch
A failing worker on a remote machine leaves only logs, unless the session was recorded. Session recording is an opt-in flag at launch; after the session closes, getReplayUrl() returns a temporary replay link and downloadReplay() returns a line-by-line log of what happened on the page.
Recording captures input values by default, so leave it off for sessions that type passwords and turn it on for the flaky ones you need to see. That leaves a short list of decisions.
Choosing the Right Setup
Running Playwright at scale in the cloud comes down to how workers connect, how many run at once, where logins live and what gets recorded. Connect with launch() or connectOverCDP, size workers to the plan's concurrency cap, keep logins in profiles attached to the default context, and record only sessions that touch no secrets. Solari's launch overview explains how browsers, sandboxes and desktops share the same account when a job grows past the browser.
Get Started With Solari
Start by pointing an existing Playwright script at a Solari session with the snippet above and running it at your current worker count. Solari is built to be the fastest and cheapest place for that job: it launches a browser in 8 ms, and the Free plan includes $3 of monthly credits, so the first runs cost nothing. Create a free Solari account and move your first fleet today.
