Kernel Browserbase: Comparing Hosted Browser Runtimes

# Kernel Browserbase: Comparing Hosted Browser Runtimes

"Kernel browserbase" is a query that usually means one of two things: you are comparing Kernel and Browserbase as hosted browser providers, or you are trying to figure out which one fits a browser-use agent stack. Both are cloud Chromium runtimes that expose sessions over CDP, and both compete on the same axis — how fast a session starts, how well it survives protected sites, and how much control you get over the browser process. This guide breaks down where they differ, what to measure before committing, and how to connect either one to Playwright without rewriting your agent.

If you want the broader runtime model first, read Remote Browser for AI agents before picking a vendor. The short version: the provider matters less than whether the session lifecycle, CDP surface, and profile handling match your workload.

What Kernel and Browserbase actually are

Kernel and Browserbase are both managed browser infrastructure. You request a session through an API, get back a CDP endpoint (usually a WebSocket URL), and drive it with Playwright, Puppeteer, or a raw CDP client. Neither one is a browser automation framework — they are the runtime underneath whatever framework you already use.

The differences show up in the details:

• Session startup model. Kernel has positioned itself around fast session creation and VM-level control. Browserbase has positioned itself around developer ergonomics and a managed session API. Startup latency is the metric most teams notice first, because it compounds across thousands of short agent tasks.
• Stealth and proxy handling. Browserbase ships managed stealth and proxy options as first-class features. Kernel exposes more of the underlying VM, which means more configuration surface but more responsibility.
• Self-hosting. Neither is open source in the way Browserless or Steel are. If self-hosting is a hard requirement, that changes the comparison entirely — see the notes below.
• CDP fidelity. Both expose CDP, but the practical question is whether you get a full browser-level endpoint or a page-scoped one. Full browser-level CDP lets you create contexts, set permissions, and attach to multiple targets. Page-scoped endpoints are simpler but constrain what Playwright can do.

The honest framing: these are close competitors. The right choice depends on your workload shape, not on a feature checklist.

Comparison table: Kernel vs Browserbase vs self-hosted

Treat this table as a starting map, not a verdict. Pricing and limits change; check each provider's current docs and Remote Browser pricing for the runtime you actually deploy.

The metric that matters most: time to first CDP command

Agent workloads are usually many short sessions, not a few long ones. A browser-use task might run for 30 seconds to 3 minutes. If session startup takes 2 seconds, that is a meaningful fraction of total task time — and it is pure overhead you pay for on every task.

When you benchmark Kernel against Browserbase, measure this directly:

1. Time from session-create API call to receiving the CDP WebSocket URL.
2. Time from connecting over CDP to the first successful Page.navigate.
3. Time to a stable DOMContentLoaded on a representative target site.

Do not trust published startup numbers without reproducing them on your own network path. Region matters: a provider with a fast control plane in us-east will look slow if your workers run in eu-west and the browser session is pinned elsewhere. Co-locate your agent workers with the browser region.

Connecting either runtime to Playwright over CDP

Both Kernel and Browserbase hand you a CDP endpoint. The connection code is nearly identical, which is the point — you can abstract the provider behind one function and swap it later.

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

type SessionProvider = "kernel" | "browserbase";

interface SessionHandle {
  cdpUrl: string;
  sessionId: string;
}

// Provider-specific session creation is isolated here.
async function createSession(provider: SessionProvider): Promise<SessionHandle> {
  const res = await fetch(`${process.env.RUNTIME_API}/sessions`, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      Authorization: `Bearer ${process.env.RUNTIME_API_KEY}`,
    },
    body: JSON.stringify({ provider, region: "us-east" }),
  });
  if (!res.ok) throw new Error(`session create failed: ${res.status}`);
  const data = await res.json();
  return { cdpUrl: data.cdpUrl, sessionId: data.id };
}

async function runTask(provider: SessionProvider) {
  const session = await createSession(provider);
  let browser: Browser | undefined;
  let context: BrowserContext | undefined;

  try {
    // connectOverCDP attaches to the remote browser process.
    browser = await chromium.connectOverCDP(session.cdpUrl, {
      timeout: 30_000,
    });

    // Reuse the default context so cookies and storage persist
    // for the life of the session.
    context = browser.contexts()[0] ?? (await browser.newContext());
    const page = await context.newPage();

    await page.goto("https://example.com", { waitUntil: "domcontentloaded" });
    const title = await page.title();
    console.log({ sessionId: session.sessionId, title });
  } finally {
    // Closing the CDP connection does not always terminate the
    // remote session; call the provider's terminate endpoint too.
    await context?.close().catch(() => {});
    await browser?.close().catch(() => {});
    await fetch(`${process.env.RUNTIME_API}/sessions/${session.sessionId}`, {
      method: "DELETE",
      headers: { Authorization: `Bearer ${process.env.RUNTIME_API_KEY}` },
    }).catch(() => {});
  }
}

Two details that bite people in production:

• `connectOverCDP` is Chromium-only. That is fine here because both providers run Chromium, but do not expect the same call to work against Firefox or WebKit. The Playwright CDP documentation is the authoritative reference for what the connection supports.
• Closing the browser object is not the same as ending the session. If you only call browser.close(), you may leave a billable session running until it times out. Always call the provider's terminate endpoint in a finally block.

If you want a deeper walkthrough of the CDP handshake, see remote browser online.

Where Kernel tends to win

Kernel's pitch is control and speed. Teams that pick it usually care about one of these:

• Latency-sensitive loops. Short tasks where startup overhead is a large share of total time.
• VM-level access. Workloads that need to install system packages, run a local proxy, or otherwise touch the machine the browser runs on.
• Custom Chromium builds. If you need a patched browser binary, a VM-oriented provider is easier to work with than a tightly managed one.

The trade-off is that more control means more configuration. You will spend more time on proxy setup, stealth tuning, and session cleanup than you would with a more opinionated managed product.

Where Browserbase tends to win

Browserbase's pitch is managed ergonomics. Teams that pick it usually care about:

• Stealth out of the box. Managed stealth and proxy options reduce the tuning work for sites that block automated traffic.
• Developer experience. A clean session API, inspector, and documentation lower the time to first working agent.
• Predictable operations. Less surface area to misconfigure means fewer 3 a.m. pages.

The trade-off is less control over the underlying machine. If your workload needs a custom binary or system-level changes, you will hit the edges of the managed model.

The self-hosting question

Neither Kernel nor Browserbase is open source. If your requirement is "run this in my own VPC" or "no third-party data processor," the comparison should include Browserless and Steel, which you can self-host. That is a different trade-off: you take on scaling, patching, session isolation, and browser version management in exchange for control and data residency.

A common pattern is hybrid: use a hosted runtime for burst capacity and self-host for steady-state or sensitive workloads. That requires your agent code to treat the browser endpoint as configuration, not a hard dependency — which is exactly what the abstraction in the code block above gives you.

For a broader look at the hosted-vs-self-hosted decision, see remote web browser.

Production criteria to evaluate before you commit

Before you pick a provider, run this checklist against your actual workload:

• Session lifecycle. Can you create, inspect, and terminate sessions programmatically? Is there a hard timeout, and what happens to orphaned sessions?
• CDP surface. Do you get a browser-level endpoint? Can you create multiple contexts and attach to popups and iframes?
• Profile persistence. Can you reuse cookies and localStorage across sessions? How is profile storage isolated between tenants?
• Proxy and network controls. Can you set per-session proxies and verify the egress IP? Is there a way to detect proxy failures early?
• Live debugging. Is there a viewer you can hand to a human when an agent gets stuck? See remote control browser for why this matters operationally.
• Observability. Do you get session logs, network traces, and console output? Can you export them?
• Cost model. Is billing per browser-hour, per session, or per task? What counts as billable time — startup, idle, or only active navigation?
• Data handling. Where is session data stored, and for how long? Is there a zero-retention option?

Score each provider on these against your own traffic. A provider that wins on startup latency but loses on profile isolation is the wrong choice for a multi-tenant agent product.

A note on "best" and "fastest" claims

Searches like "best browserbase" or "browserbase fastest" usually surface vendor comparison pages, and those pages are written by vendors. Treat any published benchmark — including ones that favor a provider you like — as a hypothesis to test. Benchmark methodology varies wildly: which sites are tested, whether stealth is enabled, which region the session runs in, and whether startup time includes DNS and TLS handshake.

If you need a repeatable comparison, build a small harness that runs the same ten tasks against each provider from the same region and records time-to-first-byte, task success, and cost per solved task. That is more useful than any leaderboard.

How Remote Browser fits

Remote Browser is a hosted Chromium runtime for AI agents and browser-use workflows. It exposes CDP endpoints that work with Playwright, Puppeteer, and Selenium, plus a live viewer, persistent profiles, configurable browser and proxy settings, session isolation, and usage controls. It is not a replacement for Kernel or Browserbase in every case — it is another point on the same map, and the right choice depends on the criteria above.

If you are migrating an agent from a local Chrome instance, the documentation covers the CDP connection flow and session API. If you are comparing cost models, pricing has the current details.

Bottom line

Kernel and Browserbase are both credible hosted browser runtimes with real differences in control versus managed ergonomics. Pick based on your workload shape: latency-sensitive and VM-hungry workloads lean Kernel, stealth-heavy and ergonomics-first teams lean Browserbase, and data-residency requirements push you toward self-hosting. Whatever you choose, keep the CDP endpoint behind an abstraction so the decision stays reversible — and measure startup latency and cost per solved task on your own traffic before you sign anything.