Servers Browserbase: Hosted Browser Runtimes Compared

# Servers Browserbase: Hosted Browser Runtimes Compared

When people search for "servers Browserbase," they usually want one of two things: a clear picture of what infrastructure Browserbase runs your sessions on, or a shortlist of hosted browser servers that do the same job. This guide covers both. It explains what a hosted browser server actually is, how Browserbase and its peers differ on the dimensions that matter in production, and how to connect an agent to a remote Chromium session over CDP without rebuilding your stack later.

The short version: a hosted browser server is a managed pool of Chromium instances you create over an API, drive over CDP, and pay for by session time. The differences between providers show up in session startup, concurrency limits, proxy and stealth controls, persistence, and price per browser-hour. Those are the criteria to compare, not marketing pages.

What "servers Browserbase" actually refers to

Browserbase is a hosted browser infrastructure product. You call its API to create a session, receive a CDP WebSocket endpoint, and connect Playwright, Puppeteer, or Selenium to that endpoint. The browser itself runs on Browserbase's servers, not yours. You never install Chrome, manage a container fleet, or patch a headless binary.

That model is the same across the category. Browserbase, Browserless, Steel, Kernel, Hyperbrowser, Anchor, and Remote Browser all sell some version of "a real Chromium instance, reachable over the network, billed by time." The category name varies — cloud browser, remote browser, browser-as-a-service — but the architecture is consistent:

• An API creates a session and returns a connection URL.
• Your code connects over the Chrome DevTools Protocol.
• The session runs in an isolated container with its own profile, cookies, and network settings.
• The session ends on timeout or explicit stop, and you are billed for the wall-clock time it existed.

If you are new to the model, Remote Browser for AI agents covers why agents need this layer at all rather than a local Chrome install.

Why the server side matters

The server side is where reliability is won or lost. A local Chrome on a laptop is fine for a demo. In production, an agent may run many sessions a day across regions, need clean IPs, need to survive a worker restart mid-task, and need a recording when a task fails. Those are infrastructure problems, and they are the reason teams move off self-managed Playwright containers.

How a hosted browser session works

The lifecycle is short and worth knowing precisely, because most production bugs trace back to one of these steps.

1. Create. Your backend calls the provider's session API with options: viewport, proxy, timeout, profile ID, and any stealth or browser settings the provider exposes.
2. Connect. The API returns a CDP endpoint, typically a wss:// URL. You pass it to chromium.connectOverCDP() in Playwright or puppeteer.connect() in Puppeteer.
3. Drive. Your agent or script issues CDP commands through the connection. Navigation, DOM queries, input, and screenshots all flow over the same socket.
4. Observe. Most providers offer a live viewer URL so a human can watch the session, plus recordings or logs after the fact.
5. Stop. You release the session explicitly, or it times out. Billing stops when the session ends.

The connection step is where portability lives. Because CDP is a standard protocol, code written against one provider's endpoint usually works against another with a URL change. That is the single most important fact for avoiding lock-in. The Chrome DevTools Protocol documentation is the reference for what commands are available.

Comparing hosted browser servers

The table below compares the dimensions that actually affect production behavior. Pricing figures are illustrative of the category and change often — check each provider's pricing page, including Remote Browser pricing, for current numbers. Do not treat any single number here as a quote.

A few notes on specific names that come up in this search:

• Browserbase is the most established hosted option and has broad framework support. Its plans are tiered by concurrency and included hours, with overage billed per hour.
• Browserless and Steel are the usual answers when someone wants to self-host. Both are open source and can run on your own infrastructure, which shifts the operational burden back to you.
• Kernel and Hyperbrowser compete on session startup speed and developer ergonomics.
• Anchor is often compared on stealth and proxy quality.
• Remote Browser focuses on CDP-first sessions with a live viewer, persistent profiles, configurable browser settings, and usage controls, priced per browser-hour.

If your priority is raw session startup latency, benchmark it yourself against your target sites. Published numbers rarely match your workload.

Connecting an agent over CDP

The code below is the pattern that works across providers. It creates a session through an API, connects Playwright over CDP, runs a task, and closes cleanly. Replace the session-creation call with your provider's SDK or REST endpoint.

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

interface SessionResponse {
  id: string;
  cdpUrl: string; // wss://... endpoint returned by the provider
}

async function createSession(): Promise<SessionResponse> {
  const res = await fetch(`${process.env.BROWSER_API_URL}/sessions`, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      Authorization: `Bearer ${process.env.BROWSER_API_KEY}`,
    },
    body: JSON.stringify({
      timeoutSeconds: 300,
      viewport: { width: 1280, height: 800 },
      // Provider-specific: proxy, profileId, browser settings
    }),
  });
  if (!res.ok) throw new Error(`Session create failed: ${res.status}`);
  return (await res.json()) as SessionResponse;
}

async function runTask(url: string): Promise<string> {
  const session = await createSession();
  let browser: Browser | undefined;

  try {
    browser = await chromium.connectOverCDP(session.cdpUrl);
    const context = browser.contexts()[0] ?? (await browser.newContext());
    const page: Page = context.pages()[0] ?? (await context.newPage());

    await page.goto(url, { waitUntil: "domcontentloaded", timeout: 30_000 });
    await page.waitForLoadState("networkidle").catch(() => {
      // networkidle is best-effort; long-polling pages never settle
    });

    const title = await page.title();
    return title;
  } finally {
    // Closing the browser disconnects; the provider ends the session
    await browser?.close();
  }
}

runTask("https://example.com").then(console.log).catch(console.error);

Three implementation details that matter:

• Always close in a `finally` block. A leaked session keeps billing until the provider's timeout fires.
• Do not rely on `networkidle` alone. Many production sites hold open connections. Use explicit selectors or waitForFunction for the element your agent needs.
• Reuse contexts, not browsers. If your provider supports persistent profiles, pass a profile ID at creation so cookies and logins survive across sessions.

For a deeper walkthrough of the connection layer, see the Remote Browser documentation.

Production criteria beyond the provider name

Choosing a hosted browser server is a procurement decision as much as a technical one. These are the questions that separate a demo from a system that holds up.

Session isolation and data handling

Each session should run in its own container with a clean filesystem and its own network namespace. Ask whether profiles are shared across tenants, how long recordings are retained, and whether the provider offers zero data retention. If you handle regulated data, get the DPA and retention terms in writing.

Concurrency and rate limits

Concurrency caps are the most common surprise. A plan that allows 25 parallel sessions sounds generous until your agent fan-out hits 60. Model your peak concurrency before you commit, and check whether the provider lets you raise it on demand or requires a plan upgrade.

Proxy and stealth controls

If your agents touch sites with bot detection, proxy quality matters more than any other factor. Broad country coverage and configurable browser settings are the baseline. Be careful with claims: "stealth" means different things at different providers, and no provider can guarantee a site will not block you. Test against your actual targets.

Observability

You need a live viewer for debugging, session recordings for post-mortems, and console and network logs you can pull programmatically. An agent that fails silently is worse than one that fails loudly.

Pricing shape

Per-browser-hour pricing scales down to zero when you are idle. Subscriptions with included hours are cheaper at steady, high utilization and more expensive when your traffic is spiky. Run the math on your own usage curve rather than comparing headline rates. Remote Browser pricing lists current per-hour details.

Portability

Because everything runs over CDP, switching providers should be a configuration change, not a rewrite. Keep session creation behind an interface in your codebase so the provider is a detail, not a dependency.

When to self-host instead

Self-hosting Browserless or Steel on your own servers is the right call in a few situations:

• You have strict data residency requirements that a hosted provider cannot meet.
• Your volume is high and steady enough that owning the infrastructure is cheaper.
• You need to modify the browser binary or run a custom build.

The trade-off is real. Self-hosting means you own container orchestration, autoscaling, proxy management, session cleanup, and the on-call rotation when a Chrome update breaks something. For most teams running AI agents, that is not where the value is. The remote browser overview covers the operational comparison in more depth.

A practical decision path

If you are still deciding, work through this in order:

1. List your hard constraints. Data residency, compliance, and required frameworks (Playwright, Puppeteer, Selenium) narrow the field fast.
2. Benchmark session startup and task success against three or four real target sites, not a demo page.
3. Estimate peak concurrency from your agent fan-out and check plan limits.
4. Price your actual usage curve, including idle time, at each provider.
5. Verify the debugging story. Open a live viewer, trigger a failure, and confirm you can see what happened.
6. Write the provider behind an interface so you can switch if the numbers change.

The category is competitive and the differences are mostly operational. Pick the runtime that fits your constraints, connect over CDP, and keep the integration thin enough that the choice stays reversible.