Solari vs Browserless: How to Migrate Your Browser Agents

In 2026, browser automation is no longer a set of scripts that print PDFs on a schedule. Enterprise AI agents have moved beyond experimentation and into production, and the browser is where most of them work: reading pages, signing in, filling forms and checking the result.

That shift changes what a team needs from a hosted headless browser. Moving from Browserless to Solari takes one connection change for most Playwright and Puppeteer code: you create a Solari session and connect to its endpoint instead of the Browserless WebSocket URL. This guide covers why teams switch, the migration step by step, and what your agents get on Solari.

Why Do Teams Migrate From Browserless to Solari?

Teams migrate when their workload changes from short scripts to long-running agents. Browserless built a browser-as-a-service for scripts, with REST endpoints for screenshots and PDFs and a licence for self-hosting, and it does that job well.

Agents stretch that model in two places. Browserless bills in units, and it defines a unit as a block of browser time of up to 30 seconds per browser connection, with reconnects charged as new connections, so an agent that holds a session open while a model thinks pays for every block. Browserless also caps session time per plan, so long agent runs get split into pieces.

The second is scope. Agents rarely need only a browser: the code they write needs a sandbox, and some apps need a full desktop. On Solari those run on the same account and the same API key as your browsers.

How Do You Migrate From Browserless to Solari?

The first step is a one-line change; the rest move your settings over one at a time.

1. Swap the connection: today Playwright calls connectOverCDP with a WebSocket URL that carries your token. On Solari, you call sessions.create() and pass session.cdpEndpoint to the same call. Locators, waits and assertions stay exactly as they are.

2. Move launch options into session options: options that sat as query parameters on the old URL, and the separate stealth path, become fields on sessions.create(). In a Solari session, every option is opt-in: stealth, a proxy, captcha solving, recording and a profile. The default is a fast headless browser with none of them, so you turn on only what each site needs.

3. Bring your logins over: if your scripts load a Playwright storage state file, upload it to a Solari profile as is, because profiles use the same storageState format. A session created with that profile starts already signed in, and for sites with two-factor sign-in a person can log in once in the profile editor and save.

4. Turn on recording where you need a record: create the session with recording: true, release it with releaseAndWait, then open a replay link or download the run as a line-by-line log. Solari recording captures input values by default, so leave it off for sessions that type passwords or payment data.

5. Rewrite REST calls as page calls: screenshot and PDF endpoints become Playwright's own page.screenshot() and page.pdf() inside a Solari session. Scripts written in BrowserQL, a proprietary query language, move to Playwright or Puppeteer; plan for that step, because it is the one that takes real work.

6. Run both side by side, then cut over: send a share of your runs to Solari, compare results on your own sites, then move the rest. Keep cdpEndpoint and wsEndpoint out of your logs: both carry the session's signed id, and anyone who holds one can drive the browser until the session is released.

Here is the swap in code:

import { chromium } from "playwright-core"
import { Solari } from "@solarisdk/browser"

// Before
// const browser = await chromium.connectOverCDP(`wss://production-sfo.browserless.io?token=${TOKEN}`)

// After
const client = new Solari({ apiKey: process.env.SOLARI_API_KEY! })
const session = await client.sessions.create({ stealth: true })
const browser = await chromium.connectOverCDP(session.cdpEndpoint)

// ...drive the browser...

await browser.close()
await client.sessions.releaseAndWait(session.id)

import { chromium } from "playwright-core"
import { Solari } from "@solarisdk/browser"

// Before
// const browser = await chromium.connectOverCDP(`wss://production-sfo.browserless.io?token=${TOKEN}`)

// After
const client = new Solari({ apiKey: process.env.SOLARI_API_KEY! })
const session = await client.sessions.create({ stealth: true })
const browser = await chromium.connectOverCDP(session.cdpEndpoint)

// ...drive the browser...

await browser.close()
await client.sessions.releaseAndWait(session.id)

import { chromium } from "playwright-core"
import { Solari } from "@solarisdk/browser"

// Before
// const browser = await chromium.connectOverCDP(`wss://production-sfo.browserless.io?token=${TOKEN}`)

// After
const client = new Solari({ apiKey: process.env.SOLARI_API_KEY! })
const session = await client.sessions.create({ stealth: true })
const browser = await chromium.connectOverCDP(session.cdpEndpoint)

// ...drive the browser...

await browser.close()
await client.sessions.releaseAndWait(session.id)

What Do Your Agents Get on Solari?

Solari is the infrastructure your agents run on: cloud browsers, sandboxes and desktops from one API. Your agent brings the logic; Solari gives it a place to work at production scale.

• Browsers that start at once: Solari browsers are ready in 8 ms, so an agent that opens a fresh browser for every task spends its time on the task. Short jobs spend almost nothing on waiting.

• A whole queue in parallel: with Solari you can launch up to 100,000 browser sessions at once. Your agent works through a full list in one pass instead of draining it a few browsers at a time.

• Sites that block automation: turn on stealth for sites with bot defences, route traffic through a proxy in the country you pick, and let Solari solve any CAPTCHA that still appears. Every other site runs on the faster default browser.

• The client you already use: Solari works with Playwright, Puppeteer and any client that speaks the Chrome DevTools Protocol. Your existing agent code moves over without a new SDK to learn.

• A record of what the agent did: every recorded session replays in the console, so the person who reviews an agent's work sees exactly what it read and clicked.

Browsers are only part of the job. Solari sandboxes run the code your agent writes in an isolated Linux machine you can pause and resume exactly where it stopped, and Solari desktops give computer-use models a full screen to operate, all on one account and one bill.

Where Are Browser Agents Going Next?

Today most browser agents run one task at a time. Over the next year that changes in four ways:

• From tasks to workflows: one agent will take a goal, open the browsers it needs, run code on the results and report back without a person starting each step. The infrastructure has to hold all three in one place.

• Beyond the browser: models with computer use already operate software through a screen. Agents will move between a browser tab and a desktop app in the same run.

• Logins as managed state: agents will keep their sign-ins in saved profiles that a person refreshes when a site asks again, instead of passwords pasted into code.

• Replays as evidence: teams that answer for what their agents do will keep recordings the way they keep logs today.

What stays human is judgement: which sites an agent may touch, what it may submit under your name, and when a result needs a second look. The teams that win will spend their people on those calls and hand the clicking to agents.

Get Started With Solari

Browserless is the more established vendor, with self-hosting and a longer track record; Solari is the younger company and moves faster on speed and price. Start with one script: swap its connection for a Solari session and run it against the same sites you run today. Solari is the fastest and cheapest way to run cloud browsers and VMs for browser agents. Get started with a free account and start running your agents today.