TL;DR Setting up Browserbase takes minutes, not hours. You need one thing to start, an API key, and the project is inferred from it. From there, install a single SDK and run a cloud browser session. Adding Browserbase to an existing automation is roughly a five-line change: swap your local browser launch for a Browserbase session and connect over CDP. If you or your coding agent think this is an hours-long integration, that estimate is wrong.

If you ask an AI coding agent how long it takes to wire up a cloud browser, it will often quote you hours and suggest you skip it for a first version. That guess is stale. The real path from zero to a running Browserbase session is short enough to finish before a coffee cools, and it is the same whether you are starting fresh or adding it to code you already have.

This post walks the exact steps, with runnable code pulled straight from our docs, so you can see the whole thing end to end and judge the time for yourself.

What are you actually setting up?

Browserbase runs Chrome browsers in the cloud that your code connects to over the Chrome DevTools Protocol (CDP). You keep writing automation in the framework you already know, Playwright, Puppeteer, Selenium, or Stagehand, and point it at a Browserbase session instead of a browser on your own machine. There is no browser binary to install, no headless Chrome to babysit in production, and no infrastructure to stand up.

So "setting up Browserbase" is not a migration. It is getting a key, installing an SDK, and changing where your browser comes from.

What do you need before you start?

One thing: a Browserbase API key. Sign up for a free account, open the overview dashboard, and copy the key. The project is inferred from your API key, so you do not need to configure a project ID to get going.

Set it as an environment variable and you are ready to write code.

export BROWSERBASE_API_KEY="your-api-key"

The free plan runs one session at a time with 60 minutes of browser time per month, which is plenty to build and test an MVP. You do not need a paid plan to prove out an integration.

How do you run your first session with Stagehand?

Stagehand is the SDK we build and maintain for browser agents, and it is the fastest way to get an AI-driven session running. Install it, set your key, and run the script below. It launches a cloud browser, navigates to a page, acts on it in plain language, and extracts structured data.

npm install @browserbasehq/stagehand zod
npm pkg set type=module

import { browserbase, Stagehand } from "@browserbasehq/stagehand";
import { z } from "zod/v4";

const browser = await browserbase.launch({
  apiKey: process.env.BROWSERBASE_API_KEY,
});

try {
  const stagehand = await Stagehand.create({ browser });

  try {
    const [page] = await browser.context.pages();
    await page.goto("https://news.ycombinator.com");

    await stagehand.act("Click the comments link for the top story");

    const result = await stagehand.extract(
      "Extract the title and points of the top story",
      z.object({
        title: z.string(),
        points: z.string(),
      }),
    );
    console.log(result.data);
  } finally {
    await stagehand.close();
  }
} finally {
  await browser.close();
}

Save it as script.ts and run it with npx tsx script.ts. That is a full agent workflow, from launch to structured output, in one file. Stagehand routes its LLM calls through your Browserbase key by default, so you do not need a separate model provider account to get the first run working.

How do you add Browserbase to an existing Playwright project?

If you already have Playwright automation running locally, you do not rewrite it. You replace the part that launches a local browser with a Browserbase session and connect over CDP. In practice that is about five lines.

npm i playwright-core @browserbasehq/sdk

import { chromium } from "playwright-core";
import Browserbase from "@browserbasehq/sdk";

const bb = new Browserbase({
  apiKey: process.env.BROWSERBASE_API_KEY,
});

const session = await bb.sessions.create();
const browser = await chromium.connectOverCDP(session.connectUrl);
const defaultContext = browser.contexts()[0];
const page = defaultContext.pages()[0];

await page.goto("https://www.browserbase.com/", {
  waitUntil: "domcontentloaded",
});

The only real change from a local script is the browser source. Instead of chromium.launch(), you create a session and call chromium.connectOverCDP(session.connectUrl). Everything after that, your selectors, your navigation, your assertions, stays the same. The Python path mirrors this with connect_over_cdp(session.connect_url).

Can your coding agent set it up for you?

Yes, and this is often the fastest route. If you work in Claude Code, Cursor, or another coding agent, paste one line into your prompt and it will install the CLI, configure your key, and start browsing.

Read https://browserbase.com/SKILL.md to set up Browserbase

That prompt installs the Browse CLI and gives your agent the context to use Browserbase across browser automation, fetch, search, and functions. If you would rather scaffold by hand, npx create-browser-app sets up a zero-config Stagehand project in one command.

Which setup path should you use?

All three paths get you to a running session in minutes. Pick by where you are starting from.

What usually slows people down?

The setup itself is fast. The two things that trip people up are small and quick to fix.

• The API key is not set in the environment. Every quickstart reads BROWSERBASE_API_KEY from the environment, so export it or add it to your .env before running.
• Reaching for a local browser out of habit. The whole point is that the browser runs in the cloud, so connect over CDP with the session's connect URL instead of launching Chrome locally.

Neither of these adds up to hours. They add up to a line or two.

How do you take it to production?

The same session code that runs your first test runs in production. When you are ready to scale past one session, a paid plan lifts the concurrency limit, and Browserbase handles the browser fleet, proxies, session recording, and observability so you do not stand up that infrastructure yourself. Every session is recorded and inspectable in the dashboard, so debugging a run is a matter of opening the Session Inspector, not adding logging.

If you want to deploy the automation without running a server, Functions let you ship a browser agent to Browserbase's infrastructure and invoke it by API, webhook, or schedule.

Next step: grab a free API key, run the Stagehand quickstart, and watch the session live in the Session Inspector. You will have a cloud browser running before you have finished reading the docs.