Run your Puppeteer scripts on Browser Use’s cloud browsers. Every session runs in a hardened Chromium fork with stealth, anti-fingerprinting, and residential proxies enabled by default — no configuration needed.
When to use this:
- You have existing Puppeteer scripts and want to run them on stealth infrastructure
- You want low-level CDP control from Node.js without managing Chrome yourself
- You want to combine agent tasks with manual browser automation
Option 1: WebSocket URL (no SDK)
Connect with a single URL. All configuration is passed as query parameters.
Query parameters
Option 2: SDK
Create a browser via the SDK, then resolve the WebSocket endpoint. Unlike Playwright, Puppeteer can’t connect to an HTTP CDP URL directly — fetch /json/version to get the webSocketDebuggerUrl first.
The SDK also gives you a liveUrl to watch or embed the session.
Create response
browsers.create() wraps POST https://api.browser-use.com/api/v3/browsers, which returns 201 with:
Field names are camelCase in the REST API and TypeScript SDK (cdpUrl, liveUrl). cdpUrl and liveUrl are nullable — check them before connecting.
Stopping a session over REST
There is no POST /browsers/{id}/stop endpoint. Stopping is an update:
Gotchas
- Use
puppeteer-core. It’s the connect-only package — installing full puppeteer downloads a local Chromium you’ll never use.
browserWSEndpoint must be a ws:///wss:// URL. Passing the SDK’s HTTPS cdpUrl directly fails; resolve it via /json/version as shown above.
- Viewport. Puppeteer applies its own 800×600 default viewport after connecting. Pass
defaultViewport: null to puppeteer.connect() to keep the browser’s real window size.
- Closing the connection vs stopping the session. With the WebSocket URL, disconnecting stops the browser. With the SDK,
browser.close() only disconnects your client — call client.browsers.stop(browser.id) to end the session.
Always stop browser sessions when done. Sessions left running will continue to incur charges until the timeout expires.
See also