Skip to main content
You get a browser from one of Stagehand’s browser factories and hand it to Stagehand.create(). There are three ways to get one:
  • Browserbase (browserbase.launch): Cloud-managed browser infrastructure optimized for production web automation at scale
  • Local (localBrowser.launch): Run browsers directly on your machine for development and debugging
  • Attach over CDP (localBrowser.connect): Attach to any Chromium browser you are already running, by URL
Stagehand closes only the browsers it launched, so browser.close() is yours to call.

Browserbase environment

Browserbase provides managed cloud browser infrastructure optimized for web automation at scale. It offers advanced features like stealth mode, proxy support, and persistent contexts. It is also the only browser that supports server-side caching and the Model Gateway.

Browserbase

Read the Browserbase documentation for the full set of session settings Stagehand passes through.

Multi-region support

Browserbase runs browsers in four regions, so you can cut latency by starting the browser near your users or your target site, and keep session data in a required jurisdiction. Set the region on browserbase.launch(); us-west-2 is the default.
Supported regions: us-west-2 (default), us-east-1, eu-central-1, ap-southeast-1.
You normally do not need to configure a regional endpoint. Stagehand picks the API deployment that matches your session’s region on its own, including for server-side caching. An explicit Stagehand apiUrl overrides that regional selection.

API endpoint overrides

Browserbase session management and Stagehand managed services use separate APIs. Both default to the production service. The SDKs do not read either URL from an environment variable. Pass baseUrl to Browserbase and apiUrl to Stagehand when testing another deployment. Use the service origin without /v1.
The Browserbase URL controls extension, session, and connection requests that browserbase.launch() and browserbase.connect() make. The Stagehand URL controls Model Gateway and managed-cache requests that the browser runtime makes.

Environment variables

Before getting started, set up the required environment variables:
Get your API key from the Browserbase Dashboard. Stagehand does not read this variable for you: read it in your own code and pass it to browserbase.launch().

Using Stagehand with Browserbase

Basic setup

The simplest way to get started is with default settings. browserbase.launch() needs nothing but your Browserbase API key:

Advanced configuration

Configure browser settings, proxy support, and other session parameters directly on browserbase.launch():
When browserbase.launch() creates a session without an extensionId, Stagehand uploads its extension and starts the session against it. Stagehand deletes the upload when you call browser.close() for a launched session without keepAlive enabled.

Alternative: Browserbase SDK

If you prefer to manage sessions directly, create the session with the Browserbase SDK and hand Stagehand the resulting session through browserbase.connect():

Connecting to an existing session

localBrowser.connect() attaches to any Chromium browser that is already running and exposing a DevTools endpoint, whether that is a Browserbase session you created earlier or a browser on your own machine:
Stagehand never closes a browser it did not launch. When you connect to an existing browser, close() tears down the Stagehand connection and leaves the browser running.

Local environment

Run browsers directly on your machine when you want full control over the browser process and its launch flags. This suits development, debugging, and custom browser setups.

Environment comparison

Basic local setup

Advanced local configuration

Customize browser launch options for local development:
Authenticated local proxies are not supported yet. Setting a proxy username or password raises in all three SDKs; a proxy server and bypass list work everywhere.

Default local launch arguments

When Stagehand launches a local browser, it adds the following Chrome arguments before any values you pass in the launch args:
--enable-unsafe-extension-debugging is required so the SDK can attach a CDP session to the service worker hosting Stagehand’s runtime. Chrome blocks debugger access to extension targets without it. --enable-features=WebMCPTesting,DevToolsWebMCPSupport turns on the browser support behind WebMCP. --window-size follows the viewport option and falls back to 1280,800 when you do not set one.
A larger set of standard Chrome automation flags (disabling background networking, component updates, sync, translation, and similar) is prepended as well. To remove some of them, list the exact flags in the ignore-default-args option:
Set the ignore-default-args option to true to remove all default arguments. Use a list to remove only exact matches while preserving the rest.

Advanced configuration

Keep alive

The keep-alive option controls whether the browser remains running after close() is called. By default, Stagehand terminates the browser it launched and cleans up all resources when it shuts down. Turning keep-alive on keeps the browser running independently so you can reconnect to it later.

Behavior by environment

Local environment

When running locally with keep-alive on, Stagehand leaves the Chrome process running when your script exits. This is useful for debugging or for handing off a browser session to another process. Combine it with a fixed port so you can reattach with localBrowser.connect().
A temporary user data directory is deleted when a local browser shuts down. Set userDataDir (or turn on the preserve option) if you want the profile to survive.

Browserbase environment

On Browserbase, keep-alive keeps the cloud session active so you can reconnect later with browserbase.connect(). This is useful for long-running workflows that span multiple script executions.
Keeping sessions alive is available on the Browserbase Startup plan and above.

Fixed CDP debugging port

Specify a fixed Chrome DevTools Protocol (CDP) debugging port instead of using a randomly assigned one.
Stagehand picks a random free port when you do not set one.

DOM settle timeout

Configure how long Stagehand waits for the DOM to stabilize before taking actions. The default is 5000 ms.
DOM settling applies to act() calls that take a natural-language instruction. Replaying an observed Action skips the wait, and observe() and extract() read a snapshot of the page as they find it.

What is DOM settling?

Before an instruction-based act() call runs, Stagehand waits for the page’s network activity to go quiet, up to the timeout. That gives lazy-loaded content, JavaScript updates, and other dynamic rendering time to finish before the action targets an element.

When to adjust

Increase the DOM settle timeout for pages with:
  • Heavy animations or transitions
  • Lazy-loading or infinite scroll
  • Dynamic JavaScript frameworks (React, Vue, Angular)
  • Complex single-page applications
Setting the DOM settle timeout too low may cause actions to fail on elements that aren’t ready. Setting it too high increases execution time unnecessarily.

Troubleshooting

  • Verify your BROWSERBASE_API_KEY is read and passed to browserbase.launch()
  • Check that your API key has the necessary permissions
  • Ensure your Browserbase account has sufficient credits
  • Remember that browserbase.launch() requires an API key: it fails without one
  • Install Chrome or Chromium on your system
  • Set the correct executable path for your Chrome installation, or set CHROME_PATH
  • Check that required dependencies are installed (Linux: libnss3-dev libatk-bridge2.0-dev libgtk-3-dev libxss1 libasound2)
  • If the extension fails to load, confirm nothing is stripping --enable-unsafe-extension-debugging from the launch arguments
  • Increase the session timeout on browserbase.launch()
  • Turn on keep-alive for long-running sessions
  • Monitor session usage to avoid unexpected terminations