---
title: "Migrate from Playwright, nodriver or a cloud browser"
description: "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."
canonical: "https://scalebrowser.net/docs/migrate"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://scalebrowser.net/llms.txt
> Use this file to discover all available pages before exploring further.

# 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

<Steps>

<Step title="Keep your code, change the browser">

Start a profile and point your existing tool at the `cdp_ws` it 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](/docs/cdp#get-a-connection) shows the one call that hands out the address.

</Step>

<Step title="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](/docs/sdks) or, for an AI agent, to the [MCP server](/docs/agents/mcp-server). Both speak CDP directly and route every click and keystroke through the human input layer.

</Step>

</Steps>

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](/docs/cdp#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](/docs/proxies) |
| Fingerprint or user-agent options | Nothing to set. The profile draws a coherent identity from its seed. See [Profiles & personas](/docs/profiles) |
| 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 |

<Note>

**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](/docs/account/plans).

</Note>

## Guides per tool

<CardGroup columns={2}>
  <Card title="From Playwright or Puppeteer" href="/docs/migrate/playwright">
    Attach with `connect_over_cdp`, drop the stealth plugin, then move strict targets to the SDK driver.
  </Card>
  <Card title="From nodriver" href="/docs/migrate/nodriver">
    Already direct CDP. Attach it to a profile's port and keep your code as it is.
  </Card>
  <Card title="From Browserbase" href="/docs/migrate/browserbase">
    Swap the session's connect URL for a profile's `cdp_ws`, and a context for the profile itself.
  </Card>
  <Card title="From browser-use" href="/docs/migrate/browser-use">
    Point the agent at a profile's CDP address, or hand the browser to your coding agent over MCP.
  </Card>
</CardGroup>

## Before you start

You need a running daemon and a profile. The [Quickstart](/docs/quickstart) gets you both in five steps, and the trial runs seven days with one browser.