Migrate from Playwright, nodriver or a cloud browser
Move existing browser automation to Scalebrowser in two steps: attach your current code to a profile over CDP, then replace the parts a page can observe.
Most automation code moves over in two steps, and the first one is small. Every tool on these pages can attach to a Chromium that is already running, and a Scalebrowser profile hands you exactly that: a DevTools WebSocket on your own machine. The second step is where the gain is, and it is optional per target.
The two steps
- Keep your code, change the browser
Start a profile and point your existing tool at the
cdp_wsit returns. Navigation, selectors and your own logic keep working, and you gain what the profile brings: one identity across starts, cookies and storage that persist, its own proxy, and the engine it runs in. Direct CDP shows the one call that hands out the address. - Remove what the page can see
Two things in a typical script are visible from inside the page no matter which browser runs underneath. A stealth plugin patches browser properties with scripts the page can inspect, and a Playwright or Puppeteer control plane has a shape anti-bot stacks recognise. Drop the plugin entirely, and for strict targets move the driving to the SDKs or, for an AI agent, to the MCP server. Both speak CDP directly and route every click and keystroke through the human input layer.
For a forgiving target, the first step is often the whole migration. For a site that fingerprints the control plane, only the second step reaches it; why direct CDP and not Playwright explains the reasoning.
What maps to what
| In your code today | In Scalebrowser |
|---|---|
| Launching a browser | Starting a profile: POST /v1/profiles/<id>/start, or launch in the SDKs |
| A user data directory, a storage state file, a cloud "context" | The profile itself. Cookies and storage persist between starts without a file of your own |
| A proxy passed at launch | A proxy stored once and assigned to the profile. See Proxies & exits |
| Fingerprint or user-agent options | Nothing to set. The profile draws a coherent identity from its seed. See Profiles & personas |
| A stealth plugin | Nothing. Remove it |
page.click(selector) | The SDK's element click (humanize_click_element in Python, humanizeClickElement in Node) with the element's box, or click over MCP |
Typing with page.fill or send_keys | humanize_type (Python) or humanizeType (Node), or type_text over MCP |
| A headless flag | headless on the start call. Omit it and the start is headless |
Profiles are unlimited; what a plan counts is browsers running at the same time. A script that used to create a fresh browser per job can keep one profile per identity instead, and start only the ones it needs. See Plans & limits.
Guides per tool
Attach with connect_over_cdp, drop the stealth plugin, then move strict targets to the SDK driver.
Already direct CDP. Attach it to a profile's port and keep your code as it is.
From BrowserbaseSwap the session's connect URL for a profile's cdp_ws, and a context for the profile itself.
Point the agent at a profile's CDP address, or hand the browser to your coding agent over MCP.
Before you start
You need a running daemon and a profile. The Quickstart gets you both in five steps, and the trial runs seven days with one browser.