Comparison
The difference is
the machine underneath.
Both give you a cloud Chrome behind a CDP URL, and both spare you from running browser infrastructure. Where they part company is what the page sees when it looks.
| BrowserFleet | Typical cloud browser | |
|---|---|---|
| Browser | Real Google Chrome, headful | Chrome or Chromium, often headless |
| macOS hardware | Apple M2, Metal GPU | Linux only |
| GPU string | Metal renderer, drawn by a real GPU | SwiftShader / software |
| Protocol | Plain CDP, no driver | Usually plain CDP |
| Billing | Per active minute, prepaid | Per hour or per session, often monthly |
| Live view | VNC + server-side real input | Varies |
| Linux entry price | $0.03 / hr | Typically higher |
Competitor capabilities change often — check their current docs before deciding. The column above describes the common shape of a Linux-only cloud browser, not a snapshot of any one vendor on any one day.
Migrating
It's a URL swap.
Because both ends speak CDP, moving over means changing where
connectOverCDP points. Your selectors, waits and page logic are untouched — which also
means leaving is just as cheap. That's the point: lock-in should come from the product being better,
not from your code being trapped.
// npm i @browserfleet/sdk
import { BrowserFleet } from "@browserfleet/sdk";
import { chromium } from "playwright";
const bf = new BrowserFleet({ apiKey: process.env.BROWSERFLEET_API_KEY });
// a real Chrome on Apple Silicon
const session = await bf.createSession({
image: "chrome-stable",
machineClass: "mac-shared",
});
const browser = await chromium.connectOverCDP(BrowserFleet.cdpUrl(session));
const page = await browser.newPage();
await page.goto("https://example.com");
await bf.endSession(session.id); // billing stopsPoint your existing code at a real Mac.
Sign up, take the $2 of trial credit and run a session — five hours on Apple Silicon, enough to check the fingerprint against whatever has been blocking you.