TL;DR: A headless browser as a service is a hosted platform that runs real browsers in the cloud and exposes them over an endpoint you call from code. You connect to it, drive the page with a framework like Playwright or Stagehand, and skip running, scaling, and babysitting Chrome yourself. Use one when you have outgrown a single local browser and need concurrency, reliability, and identity without building the infrastructure.

Running one headless browser on your laptop is easy. Running hundreds of them in production, without crashes, memory leaks, and blocked requests, is a full infrastructure problem. A hosted browser service is the answer to that problem: someone else runs the browsers, you just call them.

What is a headless browser as a service?

A headless browser as a service is a platform that runs headless browsers on remote infrastructure and gives you a connection endpoint to control them. Instead of installing Chrome, managing processes, and scaling servers, you make a call to create a browser session, receive a connection URL, and drive that browser from your own code.

A headless browser is a real browser with no graphical interface, controlled by code instead of a person. A hosted browser service takes that idea and moves it off your machine: the browser runs in the cloud, and the endpoint is how your code reaches it.

How does a headless browser service work?

You create a session over the platform, get back a connection URL, and connect to it with a standard automation framework over the Chrome DevTools Protocol (CDP). From that point the remote browser behaves like a local one: you navigate, click, type, and read the page.

First, create a session. This returns a connectUrl your framework connects to.

import { Browserbase } from "@browserbasehq/sdk";

const bb = new Browserbase({ apiKey: process.env.BROWSERBASE_API_KEY! });
const session = await bb.sessions.create({
  // Add configuration options here
});

Then connect a framework to that session and drive the page. With Playwright, you connect over CDP and use the browser exactly as you would locally.

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

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

// Create a session
const session = await bb.sessions.create();

const browser = await chromium.connectOverCDP(session.connectUrl);

// Use the default context and page
const context = browser.contexts()[0];
const page = context.pages()[0];

The framework is up to you. The same session works with Playwright, Puppeteer, Selenium, or Stagehand, an AI browser automation framework, so you keep the tooling you already know and swap only where the browser runs.

Why would you use a hosted browser service instead of running your own?

Because a single local browser stops being enough the moment you need scale or reliability. Running headless browsers yourself in production means owning a list of problems that have nothing to do with your actual task.

• Managing browser instances and the resources they consume
• Handling many concurrent sessions without exhausting memory
• Recovering from browser crashes and cleaning up zombie processes
• Scaling infrastructure up and down as demand changes
• Monitoring performance, and debugging what went wrong when a run fails

A hosted browser service absorbs all of that. You spend your time on what the browser should do, not on keeping the fleet of browsers alive.

What should you look for in a headless browser service?

The connection is the easy part. What separates providers is everything around the browser: whether it can reach the sites you need, keep state across runs, and show you what happened.

When do you not need a hosted browser service?

When a plain HTTP request already gets you the data. If a page returns everything in its initial HTML or exposes a real API, fetching it directly is faster and cheaper than driving a browser. Reach for a browser when the content is behind JavaScript, a login, or an interaction that only a real browser can perform. For lighter reads, a fetch API is often the right first step.

How do you run a headless browser service in production?

This is where a managed platform earns its place. Browserbase runs real browsers in the cloud and gives your agents Browsers, Search, Fetch, Identity, and Observability behind a single API, so you connect over CDP with the framework you already use and leave the infrastructure to us. You get concurrency, verified access, session persistence, and recordings without operating any of it. Start with the create a session guide to make your first call.

Last updated: August 2026