Browserbase vs Browserless vs Chrome: Which Runtime?

# Browserbase vs Browserless vs Chrome: Which Runtime?

Choosing between Browserbase, Browserless, and plain Chrome is really a question about where the browser process lives and who operates it. Browserbase and Browserless are managed browser services; Chrome is the browser you install and run yourself. The comparison matters most when you are running AI agents or browser-use workloads that need to survive retries, scale past one machine, and stay debuggable. This guide breaks down the trade-offs, the cost model behind each option, and the production criteria that actually decide the answer.

If you want the short version: Chrome is the engine, Browserbase and Browserless are hosted wrappers around it, and Remote Browser is a hosted Chromium runtime with CDP access, persistent profiles, and a live viewer. The right pick depends on whether you want to operate browser infrastructure or consume it.

What each option actually is

Chrome is the browser binary. When people say "just use Chrome," they usually mean running Chrome locally or on a VM you control, driven by Playwright, Puppeteer, or Selenium. You own the process lifecycle, the machine, the network egress, and the cleanup.

Browserbase is a managed browser platform. You request a session through their API, get a connection URL, and drive a remote Chromium instance over CDP. It targets teams that want hosted browsers without running the fleet themselves.

Browserless started as a self-hostable Docker image for headless Chrome and grew into a hosted service. It is popular for scraping and screenshot workloads, and it exposes both REST endpoints and CDP/WebSocket connections.

Remote Browser is a hosted Chromium runtime built for AI agents and browser-use workflows. It provides CDP access, Playwright/Puppeteer/Selenium compatibility, a live viewer, persistent profiles, configurable browser settings, session isolation, and usage controls. You connect over CDP and drive it like any remote Chrome.

The common thread: all four ultimately run Chromium. The difference is the operational surface around it.

The real decision: who runs the browser process

Every comparison collapses into one question. Do you want to be in the browser-hosting business?

Running Chrome yourself means:

• Provisioning machines with enough RAM and CPU for concurrent Chromium instances.
• Managing Chrome versions, dependencies, and headless flags across environments.
• Handling crashes, zombie processes, and disk cleanup.
• Building your own session isolation so one agent's cookies do not leak into another's.
• Wiring proxies, timeouts, and retries by hand.

A hosted runtime means someone else does that. You get a connection URL and a session ID. The trade-off is control and, sometimes, cost predictability.

For a single developer running a script, local Chrome is fine. For a fleet of agents that each need an isolated browser, persistent login state, and a way to watch what went wrong, the hosting question dominates everything else.

Comparison table

The table is a starting point, not a verdict. The cost row is where most teams get surprised, so it deserves its own section.

Browserbase vs Browserless cost: what you are actually paying for

"Browserbase vs Browserless cost" is one of the most common search phrasings, and the honest answer is that both bill for browser time, but the surrounding costs differ.

With any hosted browser service, you are paying for three things:

1. Browser time. The wall-clock duration a session is alive. This is the dominant line item for agents, because agents are slow — they reason, call models, and wait on network responses.
2. Network egress. Proxies and bandwidth. Proxy access in particular is priced separately almost everywhere.
3. Concurrency. How many sessions can run at once. This is often a plan limit rather than a metered cost.

With self-hosted Chrome, you pay for compute and, more importantly, engineering time. A single VM running a handful of Chromium instances is cheap on paper. The cost shows up when you need autoscaling, crash recovery, and per-session isolation — the work that hosted services have already done.

The practical guidance: model your cost per *completed task*, not per browser-hour. An agent that takes 90 seconds and three retries costs more than a screenshot job that takes two seconds. If your workload is agentic, browser-hour pricing can look cheap until you measure how long agents actually hold a session open.

For current Remote Browser rates and limits, check /pricing. We do not publish numbers here because they change and because guessing at them would be worse than pointing you at the source.

Where Chrome still wins

Self-hosted Chrome is not the wrong answer. It is the right answer when:

• You are developing locally and want fast iteration with DevTools attached.
• Your workload is a fixed, well-understood script that runs on a schedule.
• You have strict data-residency requirements that forbid a third-party browser.
• You already run a container platform and browser hosting is a small marginal cost.

The failure mode is treating local Chrome as a production runtime. It works until you need ten concurrent isolated sessions, persistent logins, or a way to see why an agent failed at 3 a.m. At that point you are building a browser-hosting platform whether you meant to or not.

Where hosted runtimes win

Hosted Chromium earns its place when the browser is infrastructure rather than a tool. Concretely:

• Session isolation. Each agent gets its own browser context. No cookie bleed between tenants or tasks.
• Persistent profiles. Login state survives across sessions, so agents do not re-authenticate on every run.
• Live viewer. You can watch a session in real time and debug agent behavior without reproducing it locally.
• CDP access. You keep full protocol-level control instead of a restricted API.
• Usage controls. You can cap spend and concurrency per project.

Remote Browser is designed around these. The live viewer in particular changes how you debug agents: instead of reading logs and guessing, you watch the session and see the exact step where the agent went sideways. See /blog/remote-browser-for-ai-agents for how that fits into an agent architecture.

Connecting over CDP: the code

The reason hosted runtimes are compatible with your existing tooling is CDP. Playwright's connectOverCDP attaches to a remote Chromium instance using a WebSocket endpoint. The same code works against Browserbase, Browserless, or Remote Browser — only the endpoint and auth differ.

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

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

// Your runtime's session API returns a CDP WebSocket URL.
async function createSession(): Promise<SessionInfo> {
  const res = await fetch('https://api.remote-browser.dev/v1/sessions', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${process.env.REMOTE_BROWSER_API_KEY}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      // Persistent profile so login state survives across runs.
      profile: 'agent-checkout',
      // Configurable browser settings; check docs for supported keys.
      settings: { viewport: { width: 1280, height: 800 } },
    }),
  });

  if (!res.ok) {
    throw new Error(`Session create failed: ${res.status} ${await res.text()}`);
  }
  return res.json() as Promise<SessionInfo>;
}

async function runAgentTask(): Promise<void> {
  const { cdpUrl, sessionId } = await createSession();
  let browser: Browser | undefined;

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

    await page.goto('https://example.com/dashboard', {
      waitUntil: 'domcontentloaded',
      timeout: 30_000,
    });

    // Agent logic goes here: read state, act, verify.
    const title = await page.title();
    console.log(`[${sessionId}] loaded: ${title}`);
  } finally {
    // Always close the browser handle; the hosted session ends separately.
    await browser?.close();
  }
}

runAgentTask().catch((err) => {
  console.error(err);
  process.exit(1);
});

Two details matter in production. First, browser.close() closes your CDP connection, not necessarily the hosted session — check your runtime's API for explicit session termination so you are not billed for idle browsers. Second, always set explicit timeouts. Agents that hang on a goto will hold a session open and burn budget.

Playwright's CDP connection behavior is documented in the Playwright `connectOverCDP` reference, and the underlying protocol is specified in the Chrome DevTools Protocol docs. Both are worth reading before you build retry logic.

Production criteria that separate the options

When you evaluate Browserbase, Browserless, Chrome, and Remote Browser for a real workload, score them on these:

• Session lifecycle control. Can you explicitly end a session, or does it linger? Lingering sessions are the most common source of surprise cost.
• Profile persistence. Does login state survive a crash and a redeploy?
• Debugging surface. Logs alone are not enough for agents. You want a live view or a replay.
• Protocol fidelity. Full CDP access means your Playwright and Puppeteer code ports without rewriting.
• Isolation guarantees. One agent's cookies must not reach another's session.
• Proxy and network options. Datacenter vs other proxy types, and whether you can pin geography.
• Usage controls. Per-project caps on concurrency and spend.
• Exit cost. How hard is it to move to another runtime? If the answer is "rewrite everything," that is a risk.

Notice that raw speed is not on the list. For agent workloads, reliability and debuggability beat latency almost every time, because a failed task costs a full retry plus model tokens.

A note on browser settings and stealth

"Stealth" is an overloaded term. Some services advertise configurable browser settings; others expose a smaller set of options and let you decide. Remote Browser takes the second approach: you can configure browser settings and use proxies, but we do not claim to defeat every detection system, because no runtime honestly can. If a site actively blocks automation, the durable fix is usually better session hygiene — consistent profiles, realistic timing, appropriate network egress — not a magic flag. See /blog/remote-web-browser for how network identity interacts with session design.

How to decide

Use this as a decision tree:

• Local development or a one-off script? Chrome, driven by Playwright locally.
• Scraping and screenshots at moderate scale, self-hostable? Browserless is a reasonable fit, especially if you want the Docker option.
• Managed CDP sessions with a mature dashboard? Browserbase.
• AI agents and browser-use workloads needing persistent profiles, a live viewer, and usage controls? Remote Browser.

You can also mix. Many teams prototype on local Chrome, move to a hosted runtime for staging, and keep a self-hosted fallback for data-residency edge cases. The connection code is the same because it is all CDP.

If you are still mapping the landscape, /blog/remote-browser-online covers what "remote browser" means in practice, and /documentation has the connection details for Remote Browser. For a broader look at driving sessions programmatically, see /blog/remote-control-browser.

Bottom line

Browserbase, Browserless, and Chrome are not competitors so much as points on a spectrum from "you run it" to "someone runs it for you." Chrome gives you maximum control and maximum operational burden. Browserbase and Browserless give you managed browsers with different strengths. Remote Browser targets the specific case where the browser is the runtime for an AI agent — isolated sessions, persistent profiles, a live viewer, and CDP access so your existing Playwright code keeps working.

Pick based on who you want operating the browser process, then verify the cost per completed task rather than the headline per-hour rate. That is the number that shows up on your bill.