99.99% Uptimeby Solari Status ↗

How to Migrate From TinyFish to Solari (2026 Guide)

·

6 min read

·

Summarize with AI
ON THIS PAGE

In 2026, the agent is the product. Most companies already run AI agents in production, and the teams that build them compete on their model choice, their prompts and their retry logic, so they want to own that layer and rent only the browser it runs in.

That shift moves teams off all-in-one vendors: TinyFish bundles the agent and the browser, while Solari gives you the browser layer at scale and you keep the agent. Migrating takes five steps: point your Playwright or CDP client at a Solari session instead of TinyFish's cdp_url, move saved logins into Solari profiles, turn on stealth and a proxy for the sites that block bots, rebuild goal-based TinyAgent runs as an agent you control, and record the first runs to check the result. This guide walks through each step, what Solari does for the migrated agent and where browser agents go next.

Why Do Teams Move From TinyFish to Solari?

Teams move for scale, price and control: Solari runs far more browsers at once, costs less per browser hour and leaves the agent in your code. TinyFish sells metered products with no plans or minimums, and its runs include LLM inference, residential proxies and anti-bot handling. That bundle suits a team that wants TinyFish to decide the browser actions for it.

The old way was to rent the whole agent. TinyFish meters TinyBrowser by the minute and TinyAgent by the step, with a low cap on concurrent sessions and runs for each. A job that needs hundreds of browsers at once, or an agent whose model you pick yourself, needs a different setup.

The new way is to own the agent and rent the browser. Solari browsers are ready in 8 ms, and Solari's best self-serve rate is $0.07 per browser hour, with lower rates as your volume grows. For your team, that means a job sized to the whole list instead of a handful of browsers at a time, and a model you can swap without another migration.

Solari vs TinyFish at a glance

How Do You Migrate From TinyFish to Solari?

Most of the migration is one change: where your client gets its browser endpoint. Your page logic, selectors and waits stay the same. Work through these five steps in order:

  • Swap the session call. Replace the TinyFish Browser API call, which returns a cdp_url, with Solari's sessions.create(), which returns a cdpEndpoint. Pass it to Playwright's connectOverCDP exactly as before; Puppeteer, browser-use and any other client that speaks the Chrome DevTools Protocol connect the same way.

  • Move your saved logins. TinyFish keeps login state in Browser Context Profiles, which TinyAgent runs reuse. A Solari profile saves your login, cookies and site data in Playwright's storageState format, so a storageState.json file you already have uploads as is. For a site with two-factor login, open the profile in the Solari console, sign in once in a live browser and hit Save.

  • Turn on stealth and a proxy where you need them. TinyFish routes every Browser API session through its own residential proxy by default. On Solari every session option is opt-in: set stealth and a proxy in the country you pick for sites with bot defenses. Public pages stay on the faster default browser, and captcha solving switches on with one more flag.

  • Rebuild goal-based runs as your own agent. TinyAgent turns a natural-language goal into browser actions using TinyFish's model. On Solari you bring the model and the loop: a framework that speaks CDP, or a model with computer use, drives the Solari browser. You choose the model, the prompts and the retry rules, and you can change any of them without changing vendors.

  • Record the first runs and release every session. Create sessions with the recording flag and replay them in the console next to your TinyFish screenshots and logs. Recording captures input values by default, so leave it off for any session that types a password. Call browser.close() or releaseAndWait() in a finally block so no session stays open after a failure.

A migrated session looks like this in TypeScript:

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

const client = new Solari({ apiKey: process.env.SOLARI_API_KEY! })
const session = await client.sessions.create({ stealth: true, profileId: "prof_abc123" })
const browser = await chromium.connectOverCDP(session.cdpEndpoint)
// the same page code you ran on TinyFish
await browser.close()
await client.sessions.releaseAndWait(session.id)
import { Solari } from "@solarisdk/browser"
import { chromium } from "playwright-core"

const client = new Solari({ apiKey: process.env.SOLARI_API_KEY! })
const session = await client.sessions.create({ stealth: true, profileId: "prof_abc123" })
const browser = await chromium.connectOverCDP(session.cdpEndpoint)
// the same page code you ran on TinyFish
await browser.close()
await client.sessions.releaseAndWait(session.id)
import { Solari } from "@solarisdk/browser"
import { chromium } from "playwright-core"

const client = new Solari({ apiKey: process.env.SOLARI_API_KEY! })
const session = await client.sessions.create({ stealth: true, profileId: "prof_abc123" })
const browser = await chromium.connectOverCDP(session.cdpEndpoint)
// the same page code you ran on TinyFish
await browser.close()
await client.sessions.releaseAndWait(session.id)

Only the session call and the profile ID are new. Everything between connectOverCDP and close() is the code your team already tested.

What Role Does Solari Play?

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

  • A whole job list in one pass. With Solari you can launch up to 100,000 browser sessions at once, so an agent that worked through a queue a few sessions at a time runs every task in parallel. Each task gets its own fresh browser, and nothing carries over between runs unless you attach a profile.

  • Logins that stay signed in. Attach a profile by its ID and the session starts already signed in. When a site asks for a login again, Solari gives you a link to the profile editor, a person signs in inside a live browser and saves, and your code waits for the save.

  • Sites that block automation. Stealth makes the browser look and behave like a real person's, and proxies come as rotating residential, static ISP or mobile IPs in the country you pick. Solari solves a CAPTCHA such as reCaptcha, hCaptcha or Cloudflare Turnstile in the background when a challenge still appears.

  • An audit trail for every run. A recorded session replays in the console or downloads as a line-by-line log of everything that happened on the page. Whoever reviews the agent's work sees exactly what it read and clicked.

  • The client you already use. Solari works with Playwright, Puppeteer and any CDP client, so the page code you wrote for TinyFish keeps running. Your team changes vendors without rewriting its agents.

Browsers are only part of most agent jobs. Solari sandboxes run the code your agent writes, and pausing one saves memory and processes so a resume picks up exactly where it stopped. Solari desktops give computer-use models a full Linux screen for apps with no API, all on one account, one API key and one bill.

TinyFish is the more established all-in-one vendor, with search, fetch and a hosted agent behind one wallet; Solari is the younger company and moves faster on speed and price.

Where Are Browser Agents Going Next?

Over the next year, browser agents change in four ways:

  • Agents own their loop. Teams keep the model, prompts and evaluation in their own code and treat the browser as interchangeable infrastructure. Switching models becomes a config change, not a migration.

  • Fleets, not sessions. Jobs get sized to the whole list, with thousands of browsers running at once. Work that ran overnight finishes before the morning standup.

  • Logins as managed state. Saved logins get handled like credentials, with a person signing in again through a link when a site expires a session. Agents stop failing silently at a login wall.

  • Agents that use any app. Computer-use models move work from browsers to full desktops. Agents operate software that never shipped an API.

What stays human is judgment: which jobs to hand to agents, what they may do under your company's name and who reviews the result. The teams that win will spend their people on those calls and let the infrastructure carry the rest.

Get Started With Solari

Start by moving one TinyBrowser job: swap the endpoint, attach a profile and record the first runs, then move the rest once it runs cleanly. 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.

Share this article

Give every agent
a place to work

Browsers, sandboxes and desktops from one API. Start free and scale when you need to.

Planet horizon at sunrise
opsra logo

The Fastest AI Infrastructure

Unsubscribe anytime. See our Privacy Policy.

Copyright © 2026 Solari

Engineered by Pinetree

opsra logo

The Fastest AI Infrastructure

Unsubscribe anytime. See our Privacy Policy.

Copyright © 2026 Solari

Engineered by Pinetree

opsra logo

The Fastest AI Infrastructure

Unsubscribe anytime. See our Privacy Policy.

Copyright © 2026 Solari

Engineered by Pinetree