Solari vs Hyperbrowser: How to Migrate Your Browser Agents

In 2026, the cloud browser under an AI agent is no longer a lock-in decision. Every major vendor hands back a Chrome DevTools Protocol endpoint, so moving a browser agent comes down to the few lines that open and close a session.

That makes the browser vendor a choice your team can revisit whenever the invoice or the roadmap changes. Solari is about 2x cheaper than Hyperbrowser per browser hour at scale, and moving an agent across takes four steps: swap the session calls, map the options, carry saved logins into profiles and test before you cut over. This guide covers each step in the order that keeps the old pipeline running until the new one proves itself, then what each vendor costs and where browser agents go next.

Why Move Browser Agents Now?

Browser agents now run daily production jobs, so browser hours and concurrency are a real line on the infrastructure bill. The old way was to pick a vendor once and wrap its SDK deep inside the agent. The new way keeps the agent's Playwright or Puppeteer code vendor-neutral and treats the session as a part you can swap.

Hyperbrowser says each session gives "a WebSocket endpoint to connect with Playwright, Puppeteer, or any CDP-compatible tool" in its session docs. Solari works the same way: sessions.create() returns a cdpEndpoint, and any recent CDP client connects to it.

Every page.goto, locator and wait in your agent carries over untouched, along with the prompts and retry logic above them. What changes is the client that creates the session, the option names and the login format.

How Do You Migrate From Hyperbrowser to Solari?

You migrate one job at a time in four steps, with the old pipeline left running until the new one matches it.

• Swap the session calls. Replace Hyperbrowser's client with @solarisdk/browser, connect to cdpEndpoint and end each job with releaseAndWait() instead of sessions.stop(). The headless browser code between those calls stays exactly as it is.

• Map the options you already use. Stealth, proxy and saved-login settings each have a direct counterpart on Solari, paired in the figure below. Every Solari session option is opt-in, so a session with no flags is a fast headless browser with no profile, recording, proxy or stealth.

• Move saved logins into profiles. Export each signed-in state once and upload it to a Solari profile, or sign in again by hand for sites with two-factor prompts. Your agent then starts every run already signed in.

• Test before you cut over. Run the same job on both sides and compare the results. When they match across several nightly runs, move the remaining jobs over in batches.

The session swap is a few lines at the top and bottom of each job:

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

const client = new Solari({ apiKey: process.env.SOLARI_API_KEY! })

// was: sessions.create({ useStealth: true })
const session = await client.sessions.create({ stealth: true })
const browser = await chromium.connectOverCDP(session.cdpEndpoint)

// ...the same Playwright code...

await browser.close()
await client.sessions.releaseAndWait(session.id) // was: sessions.stop()

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

const client = new Solari({ apiKey: process.env.SOLARI_API_KEY! })

// was: sessions.create({ useStealth: true })
const session = await client.sessions.create({ stealth: true })
const browser = await chromium.connectOverCDP(session.cdpEndpoint)

// ...the same Playwright code...

await browser.close()
await client.sessions.releaseAndWait(session.id) // was: sessions.stop()

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

const client = new Solari({ apiKey: process.env.SOLARI_API_KEY! })

// was: sessions.create({ useStealth: true })
const session = await client.sessions.create({ stealth: true })
const browser = await chromium.connectOverCDP(session.cdpEndpoint)

// ...the same Playwright code...

await browser.close()
await client.sessions.releaseAndWait(session.id) // was: sessions.stop()

The releaseAndWait() call waits until the session is fully closed, which is the point a replay can be read. Treat the endpoint URL as a credential: anyone who holds it can drive the browser until the session is released.

The mapping is close but not identical. On Solari, proxies and captcha solving need stealth turned on, and stealth needs a paid plan, so a proxied job sets stealth: true alongside its proxy.

Solari proxies take a country code plus an optional tier of residential, static ISP or mobile. A shared session label keeps the same exit IP across runs, so a multi-step login does not trip a security check halfway through.

How Do You Move Saved Logins Into Profiles?

You export the signed-in state from the old session's default context and upload it to a Solari profile. Solari profiles store Playwright's storageState format: cookies plus per-origin localStorage, where a login almost always lives.

The quickest route is to export from a signed-in session on the old side and save it on the new one:

// old session, signed in, before it stops
const state = await browser.contexts()[0].storageState()

// Solari
const profile = await client.profiles.create({ name: "checkout-login" })
await client.profiles.save(profile.id, state)

// old session, signed in, before it stops
const state = await browser.contexts()[0].storageState()

// Solari
const profile = await client.profiles.create({ name: "checkout-login" })
await client.profiles.save(profile.id, state)

// old session, signed in, before it stops
const state = await browser.contexts()[0].storageState()

// Solari
const profile = await client.profiles.create({ name: "checkout-login" })
await client.profiles.save(profile.id, state)

Sites with two-factor prompts are easier to redo by hand in the console's profile editor. Either way, attach the profile with profileId and keep one rule in mind: a profile seeds only the session's default context, so a context your agent creates itself starts signed out.

To confirm the move, check session.storageState?.cookies?.length for the loaded login and a present session.proxy for a proxied session. Those are the two settings that fail quietly when they are missing.

What Does Each Cost per Browser Hour?

Solari costs the same per browser hour at entry and less as your volume grows.

Hyperbrowser says browser usage costs $0.10 an hour on its free and self-serve paid plans, with 25 concurrent sessions for $30 a month, 100 for $100 a month and proxy data at $10 per GB.

Solari starts at the same hourly rate, and each step up lowers it until you reach the 2x saving from the introduction. The middle Solari tier also runs 150 concurrent browsers, so a job that needs wide concurrency gets more parallel sessions and a lower rate in the same move.

What Role Does Solari Play?

Solari is the infrastructure your browser agents run on after the move: cloud browsers, sandboxes and desktops from one API.

• Sessions ready when the job starts. Solari browsers are ready in 8 ms, so you can run one agent or a fleet of thousands in parallel. Your agent works through a full list in one pass instead of queueing.

• Logins that carry over. Profiles use the format Playwright writes, so a login exported from Hyperbrowser imports as is. Every later run opens already signed in.

• Sites that block automation. Turn on stealth where a site needs it, route traffic through a proxy in the country you choose and let Solari solve the captchas that still appear. Every other site runs on the faster default browser.

• A record of every run. Record any session and replay it in the console, so you can compare a Solari run with the old one step by step. Leave recording off for sessions that type a password, because it captures input values by default.

Solari puts browsers, sandboxes and desktops under one API. Sandboxes run the code your agent writes and desktops operate apps that have no API, all on one account and one bill.

Where Are Browser Agents Going Next?

Most teams still treat the browser vendor as a fixed choice. Over the next year that changes in four ways:

• Switching becomes routine. With CDP as the shared protocol, teams will rerun their own jobs on two vendors and move work to whichever is faster and cheaper.

• One agent, three surfaces. A single task will browse the web, run code and operate a desktop app, so teams will want all three under one account.

• Screens as well as pages. Models with computer use already operate software through a screen. Browser agents will hand off to desktop agents for tools that never shipped a web app.

• Replays as review. A recording of each run will become the evidence a reviewer checks before an agent's output ships.

What stays human is judgment: which jobs agents run, which accounts they may sign in to, and what happens with the results.

Should You Move From Hyperbrowser to Solari?

Moving from Hyperbrowser to Solari comes down to four swaps: the session client, the option names, the login format and a side-by-side test, with your Playwright code left alone. The hourly rate matches at entry and falls as your volume grows.

Choose Solari when browser hours and concurrency drive your bill, or when the same agent needs sandboxes and desktops from one account. Hyperbrowser is the broader bundle for web data, with fetch, search and hosted agents on one credit balance; Solari is the focused infrastructure layer and moves faster on speed and price.

Get Started With Solari

Start with the job whose login matters most: export its state into a profile and run it on Solari next to the old pipeline until the results match. 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.