How to Migrate From Browser Use to Solari (2026 Guide)

In 2026 the agent and the browser it runs in are two separate choices. Open-source frameworks such as browser-use drive any Chromium that speaks the Chrome DevTools Protocol, so the browser layer is a part you can swap without touching the agent.

That makes the move simple. To migrate a browser-use agent to Solari, you keep your agent code, create a Solari session and pass its CDP URL to the framework's Browser as cdp_url. Then you move saved logins into Solari profiles and switch on stealth, proxies and captcha solving only where sites need them. This guide covers why teams move the browser layer, the six steps, and what Solari adds once your agent runs on it.

Why Move Your Agents to Solari Now?

Browser agents have left the demo stage. They sign in to real accounts, run on schedules and work through long task lists every day, so the browser underneath now carries production load: how fast a session starts, whether logins survive between runs, which sites block it and how many sessions run at once.

The browser-use team pairs the framework with a hosted cloud. Setting use_cloud=True provisions one of its cloud browsers, with a cloud profile and a proxy country passed as options. That suits a team that wants the framework, the models and the browsers from one vendor.

Teams move when the browser layer has to do more: run the code the agent writes, operate an app with no web interface, or come from a vendor that only builds infrastructure while the team keeps its own models and logic. The framework is not the part you replace. Your prompts, tools, model choice and task code stay as they are; only the place the browser runs changes.

What Changes When You Migrate to Solari?

Only the browser settings change. Each hosted cloud option has a Solari session option that does the same job:

Every Solari session option is opt-in. The default is a fast headless browser with no profile, recording, proxy or stealth, and you add each one only for the sites that need it. Stealth, proxies and captcha solving run on paid plans, so a free account runs the default browser.

How Do You Migrate to Solari, Step by Step?

The migration takes six steps, and the agent code changes in one place. Most teams finish the first two in an afternoon; the rest take as long as you have sites that need them.

1. Get a Solari key. Create a key in the API Keys tab of the Solari console and export it as SOLARI_API_KEY. Install the Python SDK with pip install solari-browser. The key is shown once, so copy it when you create it.

2. Point the agent at a Solari session. Call sessions.create() and pass the session's cdpEndpoint to Browser(cdp_url=...) in place of use_cloud=True. Solari sessions name the framework's BrowserSession as a supported client, and any recent CDP client works. Treat the endpoint like a password, because anyone who holds it can drive the browser until the session ends.

3. Move your logins into profiles. A Solari profile saves your login, cookies and site data, so the agent starts every run already signed in. Upload a Playwright storage state file you already have, or sign in once in the console's profile editor, which handles sites with 2FA. A profile seeds the session's default context only, so keep the agent on that context rather than opening a new one.

4. Turn on stealth where sites push back. Set stealth: true for sites with bot defenses, add a proxy by country, and set captcha: true so Solari solves reCaptcha, hCaptcha, Turnstile and other CAPTCHA widgets in the background. Proxies and captcha solving both require stealth, while public pages stay on the faster default browser. Solving is not instant, so let the agent wait for the response field to fill before it submits a form.

5. Record the runs you need to audit. Create the session with recording on, then replay it in the console or download it as a line-by-line log. Release the session with releaseAndWait before you read its replay. Recording captures input values by default, so leave it off for sessions that type passwords.

6. Run both, then cut over. Run the same task list on the hosted cloud and on Solari for a few days, and compare completion and time per task on your own sites. Once the results hold, make Solari the default and remove use_cloud=True from the code.

What Role Does Solari Play?

Solari is the infrastructure your agent runs on: cloud browsers, sandboxes and desktops from one API. The agent brings the logic; Solari gives it a place to work.

• Sessions 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 tasks stop waiting on setup.

• A whole task list in one pass. With Solari you can launch up to 100,000 browser sessions at once, so you can run a full backlog in parallel instead of queueing it overnight. Your agent works every item on the list at the same time.

• Logins that carry over. Profiles use the same storage state format as Playwright, so a login you already saved imports as is. Your agent signs in once, and every later session reopens the same cookies.

• Stealth only where you need it. The default browser is the fastest to start and the cheapest to run, and stealth, proxies and captcha solving switch on per session. Public pages stay fast and cheap while defended sites get the full set.

• A record of what the agent did. A recorded session replays exactly what happened on the page. Whoever reviews the agent's work sees what it read and clicked before anything shipped.

• Bring the agent you have. Solari works with Playwright, Puppeteer and any client that speaks CDP, so your browser-use agent connects with a single URL. Moving your next agent over is the same one-line change.

The browser-use team is the established name in open-source browser agents and pairs its framework with its own models and cloud; Solari is the younger company, focused on agent infrastructure, and moves faster on speed and scale.

Browsers are only part of the job. Solari sandboxes run the code your agent writes and pause with memory and processes saved, and Solari desktops give computer-use models a full Linux screen, all on one account and one bill. The introduction to Solari covers all three surfaces.

What Comes Next for Browser Agents?

Browser agents are moving from single tasks to standing jobs. Over the next year that changes four things:

• Scheduled agents. More agents will run every morning without a person starting them, signed in through saved profiles. Saved logins and recordings become the first things a team checks.

• Browsers next to code. An agent that reads a page will write and run code on what it found in the same run. Teams will want the browser and the sandbox on one account.

• Agents beyond the browser. Models with computer use already operate software through a screen. Browser agents will reach into desktop tools that never shipped an API.

• Swappable browser layers. With frameworks built on CDP, teams will choose browser infrastructure on speed, scale and isolation, and change it when their needs change. Keeping the browser layer swappable becomes a day-one design choice.

What stays human is judgment: which tasks to hand over, which accounts an agent may sign in to, and the review of what it did. The teams that do well keep people on those calls and hand the clicking to agents.

Get Started With Solari

Start with one task that already runs on the hosted cloud, point it at a Solari session, and compare the two runs side by side. Solari is the fastest and cheapest way to run cloud browsers and VMs for browser-use agents. Get started with a free account and start running your agents today.