Sites Browserbase: What the Keyword Actually Means

# Sites Browserbase: What the Keyword Actually Means

People searching for "sites browserbase" are usually not looking for a product page. They are looking for a category. The query tends to come from developers who have seen Browserbase mentioned in a browser-use tutorial, a GitHub issue, or an agent framework's docs, and now want to know which sites and runtimes the term covers — and whether they should build on it. This post answers that directly, then walks through the production criteria that matter once you move past a demo: session lifecycle, CDP access, stealth settings, and how browser-hour billing actually works.

Remote Browser is a hosted Chromium runtime for AI agents and browser-use workflows. It exposes CDP endpoints, works with Playwright, Puppeteer, and Selenium, and meters usage by browser-hour. If you are evaluating "sites browserbase" as a shorthand for "where do I run my agent's browser," the rest of this page is the practical version of that answer.

What "sites browserbase" is really asking

The phrase is a compressed question. It usually means one of three things:

• Which sites can a hosted browser reach? Effectively any site a normal Chromium can reach, subject to your proxy configuration, the target's bot defenses, and your own compliance obligations.
• Which sites does Browserbase support? Browserbase is a cloud browser vendor; it does not maintain a site allowlist. Support is a function of the browser, not the vendor.
• Which sites should I run browser-use agents against? This is the real question, and it has a real answer: the sites where your task is worth automating and where the runtime can hold a session long enough to finish.

If you arrived here from a browser-use tutorial, the term you actually want is *hosted browser runtime*. Browserbase is one implementation. Remote Browser is another. The differences that matter are in the connection model, the session controls, and the pricing unit — not in a list of supported domains.

Hosted browser runtimes: what they are

A hosted browser runtime runs Chromium on infrastructure you do not manage and hands your code a connection string. Your agent connects over the Chrome DevTools Protocol (CDP) and drives the browser exactly as it would a local one. The Chrome DevTools Protocol is the same interface Chrome exposes locally, which is why Playwright's connectOverCDP works unchanged against a remote endpoint.

What you get instead of chromium.launch():

• A CDP WebSocket URL per session
• Isolated browser contexts, so two agents do not share cookies or storage
• Optional persistent profiles when a task needs to stay logged in across runs
• A live viewer for debugging sessions that are already running
• Configurable browser settings, including proxy routing and user-agent controls

What you give up: direct filesystem access to the browser process, the ability to patch Chromium yourself, and the assumption that a session is free. That last one is the part teams underestimate.

Sites, sessions, and the browser-hour

The unit of cost in a hosted runtime is the browser-hour — one browser running for one hour. It is a better mental model than "requests" or "tasks" because agent workloads are dominated by wall-clock time, not request count. An agent that waits on a slow checkout flow for four minutes costs four minutes of browser time whether it made three requests or three hundred.

This changes how you think about what "sites browserbase" covers. A site is cheap to automate if:

1. The task completes in a bounded number of steps.
2. The page does not require long human-like dwell times to avoid detection.
3. The session can be closed as soon as the task finishes.

A site is expensive if your agent polls, retries, or holds a session open waiting for an external event. The fix is architectural: close sessions aggressively, persist state in profiles rather than in live browsers, and treat the browser as a short-lived resource. Current rates and metering details are on the /pricing page.

Comparison: local Chromium vs. self-hosted vs. hosted runtime

The middle column is where most teams start and where most teams stall. Self-hosting Playwright is not hard to *start*; it is hard to *operate*. Container-per-session isolation, CDP endpoint security, profile persistence, and egress configuration are each a small project. If your product is the agent, not the browser fleet, the hosted column is usually the correct default.

Connecting a browser-use agent over CDP

The connection pattern is the same across frameworks. Here is a TypeScript example using Playwright's CDP connect against a hosted session. Replace the endpoint with the one your runtime returns.

import { chromium, Browser, Page } from "playwright";

interface SessionInfo {
  cdpUrl: string;      // wss://... returned by the runtime
  sessionId: string;
}

async function runAgentTask(session: SessionInfo, url: string) {
  // connectOverCDP attaches to an existing browser, it does not launch one.
  const browser: Browser = await chromium.connectOverCDP(session.cdpUrl, {
    timeout: 30_000,
  });

  // A hosted session usually exposes one default context.
  const context = browser.contexts()[0] ?? (await browser.newContext());
  const page: Page = await context.newPage();

  try {
    await page.goto(url, { waitUntil: "domcontentloaded", timeout: 45_000 });

    // Your agent loop goes here: observe, decide, act.
    const title = await page.title();
    console.log(`[${session.sessionId}] loaded: ${title}`);

    return title;
  } finally {
    // Close the page, not the browser, if the session should persist.
    await page.close();
    // await browser.close(); // only when the session is truly done
  }
}

Three details that matter in production:

• `connectOverCDP` does not launch a browser. If the endpoint is stale, you get a connection error, not a new session. Handle reconnection explicitly.
• Do not call `browser.close()` reflexively. On a hosted runtime, closing the browser may terminate the session and stop the meter — which is what you want at the end of a task, but not between steps of a multi-page workflow.
• Set timeouts on every navigation. Hosted sessions are billed by time; a hung goto is a hung meter.

For a broader walkthrough of the runtime layer, see /blog/remote-browser-for-ai-agents.

Stealth, proxies, and what "supported sites" really means

The reason "sites browserbase" gets searched at all is that some sites are hard. Login walls, CAPTCHAs, and bot-detection systems are the practical boundary of what any hosted runtime can do.

What a hosted runtime can legitimately offer:

• Configurable browser settings — user agent, viewport, locale, timezone, and related context options.
• Proxy routing — datacenter or residential egress, depending on your plan and provider.
• Session isolation — a clean context per task, so one agent's cookies do not poison another's.
• Persistent profiles — a stable identity across runs, which is often more effective than any single stealth flag.

What no runtime can honestly promise: that every site will work. Bot detection is adversarial and changes. A runtime that claims universal access is either measuring the wrong thing or will not hold up in production. Treat stealth as a configuration surface, not a guarantee, and validate against the specific sites your agent needs.

If your workload depends on residential egress or hardened browser builds, confirm current capabilities before committing — those are plan-dependent, not universal.

Production criteria before you pick a runtime

Use this as a checklist when comparing hosted options, including Browserbase, Remote Browser, and anything else you find:

• CDP compatibility. Can you connect with the Playwright, Puppeteer, or Selenium client you already use, without a vendor SDK wrapper? Lock-in usually starts here.
• Session lifecycle control. Can you create, inspect, and terminate sessions via API? Can you reconnect to a live session after a worker restart?
• Profile persistence. Are profiles first-class, or do you have to serialize cookies yourself?
• Observability. Is there a live viewer or session recording? Debugging a failed agent run without one is guesswork.
• Isolation guarantees. Is each session a separate browser context, or a separate process? The answer affects both security and cost.
• Metering transparency. Is usage reported per session, and can you see browser-hours before the invoice arrives?
• Egress options. Which proxy types are available, and in which regions?
• Data handling. Retention policy, DPA availability, and whether session data is stored at rest.

Two of these — CDP compatibility and session lifecycle control — eliminate most options quickly. If a runtime requires you to rewrite your agent against a proprietary API, the migration cost will exceed the savings.

When a hosted runtime is the wrong choice

Be honest about the cases where you should not use one:

• You need to patch Chromium. Hosted runtimes run a managed build. If your task depends on a custom binary, self-host.
• Your workload is tiny and bursty. A handful of runs per day may not justify a metered service; a local browser is fine.
• You need sub-second latency to a specific datacenter. Network hops to the runtime add up. Co-locate or self-host.
• Your compliance posture forbids third-party browser infrastructure. Then the question is not which vendor, but which internal platform team owns the fleet.

For everyone else — agents that run continuously, tasks that need isolation, teams that would rather ship product than operate browsers — the hosted model is the shorter path. See /blog/remote-browser-online for the setup walkthrough, and /documentation for the API surface.

The short version

"Sites browserbase" is not a list of domains. It is shorthand for a category: hosted browser runtimes that give AI agents a real Chromium over CDP, billed by browser-hour. The sites you can reach are the sites your configuration allows; the sites you *should* reach are the ones where your task completes inside a bounded session. Pick a runtime on CDP compatibility, session control, and observability — then keep your sessions short and your profiles persistent.