The new engineer's opening question on the agent team was a fair one: when the agent opens a web page, where does that browser actually live? Somebody said a container, somebody said a vendor, and somebody said it depends on whether last night's login still works.
All three answers point at the same thing. A cloud browser is a real Chrome that starts on someone else's machine when code asks for it, takes commands over the Chrome DevTools Protocol from Playwright or any client that speaks it, and shuts down when the job ends. Solari runs cloud browsers as sessions, with profiles for logins, proxies for network location and recording for replay, each switched on per session. This guide walks through those parts in the order an agent meets them.
What a Cloud Browser Session Is
The session is the unit everything else attaches to, so it comes first. On Solari, a session is a real browser driven with the standard Playwright API: launch() opens it and connects in one call, and close() shuts it down and cleans up, which makes it safe to call from a finally block.
By default that browser is a headless browser, a browser with no graphical interface, controlled entirely through code. Every Solari session option is opt-in: the default is a fast headless browser with no profile, recording, proxy or stealth, so a session carries only what the code asked for.
A session is only useful once code can talk to it, which is the job of the protocol underneath.
How CDP and Playwright Connect to It
Most teams already have browser code, so the connection layer decides how much of it survives the move. Chrome exposes a remote-control interface called the Chrome DevTools Protocol, and Playwright attaches to it with connectOverCDP. Puppeteer, browser-use and other CDP clients attach the same way.
On Solari, sessions.create() returns a cdpEndpoint, and the client a team already uses connects to it. The short version looks like this:
The cdpEndpoint and wsEndpoint URLs are credentials. Anyone who holds one can drive the browser until the session is released or expires, so they stay out of logs, error reports and client-side code.
A connected browser starts empty, though, and an empty browser is signed in to nothing.
How Profiles Keep an Agent Logged In
Logins are where most agents first break, so persistence is the next piece. A browser remembers a login through cookies and per-site localStorage, and a fresh session has neither.
A Solari profile saves that state in Playwright's standard storageState format and reopens it in any later session by profileId. A person can sign in once through the profile editor in the console, which handles sites with two-factor prompts or captchas, or a team can upload a storageState file Playwright already wrote. Every run after that starts signed in.
The rule that trips people up is that a profile seeds only the session's default context. A context created later with newContext() does not carry the login unless the code applies session.storageState to it at creation time. Treat profiles like passwords: anyone with the API key can attach one and act as that account.
Being signed in answers who the browser is; sites also check where it appears to come from.
How Proxies Change Where the Browser Appears
Network location is the next layer a site inspects. A proxy server sits between the browser and the site, so the site sees the proxy's address instead of the data centre's.
Solari proxies take a country code and an optional tier: rotating residential by default, static ISP for a fixed IP all session, or mobile carrier IPs for the strictest targets. Proxies require stealth: true and a paid plan. Sessions that share a proxy.session label share an exit IP, which keeps multi-step logins from tripping a security challenge.
Proxy traffic is billed per GB, so the blockHeavy option refuses video, audio and large images before they cross the proxy. When a proxied run still goes wrong, the question becomes what the page actually showed.
How Recording and Replay Work
Logs say which call failed; a replay shows what the page looked like when it did. Solari session recording is switched on with recording: true at create time, and afterwards getReplayUrl() returns a temporary link while downloadReplay() returns NDJSON, a line-by-line log of everything that happened on the page. The console plays the same replay from any session row.
Recording captures input values by default. A session that types passwords or payment data should be left unrecorded, or its replays restricted and purged on the team's compliance schedule.
Those are the parts an agent touches; the remaining question is what they cost.
What a Cloud Browser Costs
Every part above draws from a single credit balance, so the price is easiest to read in one place. Solari bills browsers per hour while a session is open, and the rate falls as the plan grows.
The bars come from the pricing page in the docs, which also carries the add-ons: proxies at $4.00 per GB on Professional, and replay retention from 1 day on Free to 90 days on Team. The Free plan includes $3 of monthly credits, and there is no end-of-month overage charge.
With the parts and the price in view, the setup decisions are short.
Choosing the Right Setup
A cloud browser is a session first, and everything else is an option attached to it. Start with a plain session over Playwright or CDP, add a profile when the agent needs a login, add a proxy only when a site checks location, and turn on recording for runs that do not type secrets. Treat endpoint URLs and profiles as credentials throughout. The Solari introduction shows how the same account adds sandboxes and desktops when the agent needs more than a browser.
Get Started With Solari
The first step is to create a profile, sign in once in the console editor, and launch a recorded session with that profile attached. Solari browsers are ready in 8 ms, and Solari is about 2x cheaper than Browserbase per browser hour. Create a free Solari account and the Free plan's credits cover the first sessions.
