The overnight run reported success, yet the morning spreadsheet had gaps where prices should have been. Nobody could say whether the site had changed, the login had expired or the browser had died mid-page. The logs held a timeout and little else.
The most reliable browser infrastructure for AI agents makes those failures rare and, when they happen, explainable: every session isolated on its own machine, a clean start and release, capacity limits you can plan around, logins that survive between runs and a record of what the page did. Solari runs browsers as sessions started by API and covers each of those parts in the same account. This guide walks through them in order, with the setting that matters in each.
What Reliable Means for a Browser Agent
Reliability for an agent is less about a headline figure and more about which failures can happen at all. A headless browser is a full rendering engine with no window, and it fails in ordinary ways: it runs out of memory, inherits state from the last job, hits a rate limit or loses a login. Good infrastructure removes the first two, makes the third predictable and the fourth recoverable.
A useful test is whether you can tell what went wrong in a failed run without running it again. The first thing to check is what separates one session from the next.
Isolation Between Sessions
Isolation comes first because a session that shares a host with other work inherits its problems. Each Solari session runs in a Cloud Hypervisor microVM with its own kernel, separated from its neighbours by hardware virtualization, as the pricing page sets out. It is its own machine, not a process on a shared host.
Inside a session, Playwright adds a second layer with browser contexts, each holding its own storage. That layer helps tests and becomes a trap for logins, covered below. Before that, the session needs a predictable start and end.
Clean Starts and Clean Releases
Most flaky runs trace back to state nobody asked for, so a reliable session starts empty. Every session option on Solari is opt-in: the default is a fast headless browser with no profile, recording, proxy or stealth, and each extra is a flag you set on purpose. A fresh session per task beats reusing a browser that still carries the last job's tabs.
The end matters as much as the start. browser.close() shuts the browser down and cleans up, so call it from a finally block; with sessions.create(), releaseAndWait(id) waits until the release is complete. Treat the cdpEndpoint and wsEndpoint URLs as credentials, since anyone holding them can drive the browser until it is released. Once single sessions behave, the question is how many can run at once.
Capacity You Can Plan Around
A fleet fails loudly when it asks for more browsers than the plan allows, so the limits belong in your code. The paid self-serve plans set these caps:
Size your worker pool to the concurrent-browser row, not to the CPU count of the machine running the agent. Stealth sessions carry a separate, lower cap on top of that, and a session over it receives a 429 response under the plan limits. Wrap session creation in a retry with exponential backoff so a burst waits instead of failing.
A long crawl that might outlive the plan's maximum session should save its progress and continue in a new session. With capacity handled, the remaining failures come from the sites themselves.
Logins That Survive Between Runs
Logins are where long-running agents most often break, because every fresh sign-in is another chance to hit a challenge. Solari profiles save your login, cookies and site data in Playwright's storageState format, and a session started with a profileId opens already signed in.
The rule that catches teams is about contexts. A profile seeds exactly the session's default context, so use session.context or session.newPage(); a context you create yourself starts empty unless you apply session.storageState to it. When a login expires, profiles.edit() returns a link a person opens to sign in again.
Sites with bot defenses are the other half of the problem. Stealth mode makes the browser look like an ordinary person's and is the prerequisite for proxies and captcha solving; start in the default mode and switch the moment blocks appear. Some runs will still fail, and the last part is knowing why.
Evidence When a Run Fails
A failed run is only cheap if you can see it. Session recording is a 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 jobs you need to watch back. That leaves the parts that add up to a reliable setup.
Choosing the Right Setup
Reliable browser infrastructure comes down to isolated sessions, clean releases, capacity handled in code, logins kept in profiles and recordings of the runs that fail. In practice: start each task in a fresh session, release it from a finally block, size workers to your plan's cap with backoff on a 429, attach profiles to the default context and record the jobs you need to debug. The launch overview explains how browsers, sandboxes and desktops share one account when a job grows past the browser.
Get Started With Solari
Start by moving your flakiest scheduled job onto a recorded Solari session with a profile attached, then watch the replay of its next failure. Solari is built to be the fastest and cheapest place for that work: Solari browsers are ready in 8 ms, and the Free plan includes $3 of monthly credits, so the first runs cost nothing. Create a free Solari account and put your most fragile job on it tonight.
