Solari vs Cloudflare: How to Migrate Your Agents (2026 Guide)

Solari runs the browsers, sandboxes and desktops AI agents work in, from one API, and moving an agent there from Cloudflare changes the connection, not the agent. In 2026 agents sign in, work through long tasks, run the code they write and hand off to a person when they get stuck, and Cloudflare built for that with Sandboxes reaching general availability in April next to Browser Run, the product formerly called Browser Rendering.

To migrate from Cloudflare to Solari, point your existing Playwright or Puppeteer code at a Solari session instead of Browser Run, move sandbox calls to Solari's sandbox client, and import saved logins as Solari profiles. This guide covers why teams switch, each step of the migration and what your agents get once they land.

Why Are Teams Moving Agents From Cloudflare to Solari?

Cloudflare built its agent products into Workers, so the browser and the sandbox sit behind the Worker that already handles your traffic. That fits well when the agent lives inside a Cloudflare application. It is a heavier fit when the agent loop runs in your own backend, a job queue or another cloud.

Limits follow the Workers plan too. Browser Run limits set concurrency per account, cap how fast new browsers start and close a session after a short idle window unless you keep it alive. Cloudflare Sandboxes are reached through a Worker, so the code that drives a sandbox runs on Cloudflare as well.

Solari takes the other approach. Browsers, sandboxes and desktops come from one API key you can call from anywhere, so your agent keeps running where your team already runs code and only the environment underneath it moves.

How Do You Migrate From Cloudflare to Solari?

Most of the code you keep is standard Playwright or Puppeteer. What changes is the connection and where the agent's machine lives.

These are the steps, in the order most teams run them:

• Map what runs where. List every Worker that launches a browser or a sandbox, and note whether it uses Quick Actions, a browser session or a container. Quick Actions such as screenshots and PDFs become a short Playwright call on a Solari session. Browser sessions and containers map one to one.

• Swap the browser connection. Replace the Browser Run launch with a Solari session and connect your client to its CDP endpoint. Browser Run's Playwright support is Cloudflare's fork of Playwright, while Solari works with standard playwright-core, Puppeteer and any client that speaks the Chrome DevTools Protocol. The change is the connection URL and the import.

• Carry your logins over. If your agent keeps a signed-in state, export it as a Playwright storage state file and upload it to a Solari profile. Every later session that attaches the profile starts already signed in, so your agent stops logging in on every run.

• Move sandbox code to the sandbox client. A container command becomes a call to run a command in a Solari sandbox, and file writes, git operations and preview URLs have direct equivalents. Pause a sandbox and its memory and processes are saved, so a long task resumes exactly where it stopped.

• Move the agent loop out of the Worker. With a Solari API key, the orchestration can run in your backend, a CI job or a Solari sandbox itself. Keep secrets in your own secret store and pass each session only what it needs.

• Run both side by side, then cut over. Send a slice of jobs to Solari, record those sessions and compare the replays with the Cloudflare runs. Once the results match, move the rest of the traffic.

The browser swap itself is a few lines:

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

const solari = new Solari({ apiKey: process.env.SOLARI_API_KEY! })
const session = await solari.sessions.create({ profileId: "prof_abc123" })
const browser = await chromium.connectOverCDP(session.cdpEndpoint)

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

const solari = new Solari({ apiKey: process.env.SOLARI_API_KEY! })
const session = await solari.sessions.create({ profileId: "prof_abc123" })
const browser = await chromium.connectOverCDP(session.cdpEndpoint)

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

const solari = new Solari({ apiKey: process.env.SOLARI_API_KEY! })
const session = await solari.sessions.create({ profileId: "prof_abc123" })
const browser = await chromium.connectOverCDP(session.cdpEndpoint)

What Role Does Solari Play?

Solari is the infrastructure your agent runs on after the move: cloud browsers, sandboxes and desktops from one account and one API. Your agent keeps its logic; Solari gives it a place to work.

• Browsers ready when the agent is. Solari browsers are ready in 8 ms, and with Solari you can launch up to 100,000 browser sessions at once. Your agent can run a whole job list in parallel instead of working through it in batches.

• Logins a person can fix. A profile saves a session's cookies and site data, and a person can open it in a live browser to sign in to sites with two-factor prompts, then save it for every later run. Your agent never stalls on a login it cannot complete alone.

• Sites that block automation. Turn on stealth for the sites that need it and route traffic through a proxy in the country you pick. Every session option is opt-in, so every other job runs on a fast default browser.

• A record of every run. A recorded session replays afterwards, so you can see exactly what the agent read and clicked. Recording captures input values by default, so leave it off for sessions that type a secret.

• Sandboxes for the code your agent writes. Each dedicated Solari sandbox is a microVM of its own, with 1 to 8 CPUs and up to 16 GB of memory. Snapshot a running sandbox and fork it to try several approaches from the same state.

• Desktops for computer use. Solari desktops are full Linux computers with a screen that computer use models can see and operate. A VM starts usually in about a second, with a live view you can watch and take over.

The move also lowers the sandbox bill. Solari bills $0.114 an hour for a 4 vCPU, 8 GB sandbox at its lowest published rate, and Solari's pricing comparison lists Cloudflare at $0.365 for the same size at list price, as of 6 October 2026.

What Comes Next for Agents After the Move?

Agent workloads are changing faster than the platforms they started on. Over the next year, four shifts will shape where teams run them:

• Longer sessions. Agents will run tasks that take hours, pausing while they wait on a model or a person. Infrastructure that saves state on pause, rather than closing a session on idle, becomes the baseline.

• Browser and code in one job. One agent will read a site, write a script to process what it found and run it, all in a single task. Teams will want both environments on one account instead of two vendors.

• Computer use beyond the browser. Models already operate software through a screen. Agents will move into desktop apps that never shipped an API, and they will need a real Linux desktop to do it.

• Portable agent code. Teams will keep their agents on standard Playwright and CDP so the environment underneath can change without a rewrite. Migrations like this one get shorter every year.

What stays human is the judgment: which jobs an agent takes on, what it is allowed to send and the review of what it did. Cloudflare is the more established platform, with a global network and the wider Workers ecosystem; Solari is the younger company and moves faster on speed and price.

Get Started With Solari

Start by moving one browser job, such as a nightly screenshot run or a signed-in report, and compare its replay with the Cloudflare run. Solari is the fastest and cheapest way to run cloud browsers and VMs for browser and coding agents. Get started with a free account and start running your agents today.