Build vs Buy: Self-Hosting Chromium for AI Agents (2026 Guide)

The browser started as a container next to the agent, launched by the same Playwright script the tests used. It worked for weeks. Then the job list grew, the container began crashing under memory pressure, and a site that loaded cleanly last month started answering with a challenge page.

Self-hosting Chromium makes sense while an agent visits a few trusted sites at low volume. Once the job needs many sessions at once, saved logins, proxies, CAPTCHA handling or replays, buying from a provider costs less than the engineer time a fleet consumes. Solari is that provider: real Chrome sessions started by API and driven with Playwright, so the agent keeps its code and drops the fleet. This guide covers what the build side involves, what each side costs, and how to move without a rewrite.

What Self-Hosting Chromium Actually Involves

The build side is easy to underestimate, so it comes first. Running a headless browser on a laptop takes a few lines of code; running a fleet of them for an agent is an operations job.

Playwright's own Docker guide sets the tone: its image "is intended to be used for testing and development purposes only", and without --ipc=host "Chromium can run out of memory and crash." Running the image as root also disables the Chromium sandbox, so crawling untrusted sites needs a non-root account and a seccomp profile.

Add version pinning, image rebuilds and a scheduler that queues sessions when hosts fill up, and the fleet, not the browser, becomes the project. That is the visible work; the larger share sits in what the agent needs from each page.

Where the Hidden Work Sits

The hidden work is everything a website does to tell an agent from a person, and each piece is a separate system on the build side.

Logins come first. An agent that signs in on every run trips security checks, so teams save cookies between runs and build storage and access control around them. On Solari, profiles do that job: a profile saves "your login, your cookies and site data" in Playwright's storageState format, and a session started with its profileId opens already signed in.

Network and debugging follow. Solari sessions take stealth, proxy and captcha as options at create time, and session recording is an opt-in flag that returns a replay link and a line-by-line log of the page. Each is a flag rather than a project, which changes the cost comparison.

What Each Option Costs

Cost is where building looks strongest, because the server bill is visible and the engineer hours are not. The comparison below sets the two side by side.

On the self-hosted side, the line items are hosts, a proxy contract, a CAPTCHA service and the hours of whoever keeps them running, and the hours are usually the largest. Solari bills browsers only while a session is open, at $0.07 per browser hour on the Professional plan, whose $200 monthly fee returns as usage credits.

Proxies and CAPTCHA draw from the same balance, at $4.00 per GB and $0.005 per solve on Professional. Nothing bills past the balance, so there is no end-of-month overage charge. With both columns priced, the open question is when building still wins.

When Building Still Makes Sense

Building remains the right call in a few cases. An agent that reads internal tools, runs a handful of sessions a day and never meets a login wall gets little from a provider. A team that must keep every page load inside its own network has a compliance constraint that price cannot move.

Teams already running Chromium for end-to-end tests can stretch that setup for a small agent on trusted sites, the case Playwright's image is built for. Outside those cases, what matters is how easy it is to leave.

How to Move an Agent to Solari

Leaving is smaller than most teams expect, because Playwright already drives browsers it did not launch. Create a session, then attach the agent's existing client with Playwright's connectOverCDP:

const session = await client.sessions.create()
const browser = await chromium.connectOverCDP(session.cdpEndpoint)
// ...the agent's existing Playwright code...
await browser.close()
await client.sessions.releaseAndWait(session.id)

const session = await client.sessions.create()
const browser = await chromium.connectOverCDP(session.cdpEndpoint)
// ...the agent's existing Playwright code...
await browser.close()
await client.sessions.releaseAndWait(session.id)

const session = await client.sessions.create()
const browser = await chromium.connectOverCDP(session.cdpEndpoint)
// ...the agent's existing Playwright code...
await browser.close()
await client.sessions.releaseAndWait(session.id)

To carry logins over, upload the existing storage-state.json into a profile and pass its profileId at create. The profile seeds only the session's default context, so a context the agent creates itself needs session.storageState applied. Keep the cdpEndpoint out of logs, since anyone holding it can drive the session.

Concurrency is a plan setting, from 3 browsers at once on Free to 20 on Starter and 150 on Professional, so size workers to the cap rather than to a host's CPU count. With the agent connected, the decision comes down to a short rule.

Choosing the Right Setup

Build versus buy for Chromium comes down to volume, logins, the sites the agent visits and who carries the pager. Self-host while sessions are few, sites are trusted and nobody needs a replay. Buy once the agent needs parallel sessions, saved logins, proxies or CAPTCHA handling; the Solari launch overview shows how browsers, sandboxes and desktops share a single account as the agent grows.

Get Started With Solari

Start by pointing the agent's current Playwright script at a Solari session with the snippet above and running it on a real job. Solari is built to be the fastest and cheapest home for that job: it launches a browser in 8 ms, and Enterprise browsers cost a tenth of Team's rate. The Free plan includes $3 of monthly credits, so create a free Solari account and retire the first container today.