Hosted Browser API: When Browser Sessions Become Infrastructure

Every serious web automation stack eventually hits the same wall: a browser is a process, not a service. You launch Chromium, run your script or agent, and tear it down. It works in development and breaks the moment you need concurrency, persistence, observability, or a session that outlives a single request. A hosted browser API fixes that by reframing the browser as infrastructure: you provision a session, connect to it from anywhere, and release it when you're done — just like a database or a queue.

For teams running browser-use workflows, AI web agents, and Playwright test suites, this shift from process to service is the difference between a promising demo and something you can run in production. Here's what that actually looks like, how a hosted browser API compares to the alternatives, and why browser sessions are becoming the next piece of cloud infrastructure.

The infrastructure gap: why local browsers don't scale

A local browser is tightly coupled to the machine that launched it. That coupling creates a long list of limitations once automation moves beyond a single script:

• Lifecycle is manual. The browser lives and dies with your process. Crash, deploy, or network blip and the session is gone.
• No remote access. Your automation code must run on the same host as the browser, which couples your agent runtime to your browser runtime.
• No isolation. Multiple agents or tests sharing one browser profile bleed state into each other: cookies, localStorage, extensions, tabs.
• No persistence. Want a logged-in session that survives a container restart? You're managing user-data-dirs, snapshots, and file systems by hand.
• No observability. When a headless browser fails, you get a stack trace, not a video. Debugging becomes guesswork.

These aren't edge cases. They're the default conditions of production. An AI agent that runs 24/7 needs a browser that outlives any single task. A team running browser-use against an internal SaaS product needs sessions that stay logged in. A test suite needs isolation so one failing run doesn't poison the next. None of that works with a locally spawned Chromium process.

What a hosted browser API actually provides

A hosted browser API turns a browser session into a first-class resource with a URL, a lifecycle, and access controls. Instead of launching Chromium on your own machine, you ask the API to create a session and get back a connection endpoint — usually a WebSocket URL for the Chrome DevTools Protocol (CDP).

The core primitives look like this:

• Session provisioning. Create a browser session on demand via HTTP or SDK. The API returns a CDP endpoint your code connects to.
• Live viewer. A visual stream of the session so you can watch an agent work, debug a stalled step, or reproduce a bug in real time.
• Persistent profiles. Save session state and reuse it across tasks, so logins and configuration survive between runs.
• Session isolation. Every session runs in its own context, so one workload's cookies, tabs, and storage don't leak into another.
• Configurable browser settings. Tune viewport, user agent, proxy, and other browser-level options per session to match the site or workflow you're targeting.
• Usage controls. Set timeouts, limits, and lifecycle policies so a runaway agent can't burn resources forever.

What makes this "infrastructure" rather than just "a browser in the cloud" is the operational contract. You create it with an API call, connect to it over a standard protocol, monitor it through a control plane, and shut it down when it's no longer needed. Your code no longer cares where Chromium is actually running. It only cares about the session endpoint.

Connecting with Playwright over CDP

Because a hosted browser API speaks CDP, it works with any client that supports remote browser connections. Playwright is the most common choice, and it supports this natively through connectOverCDP.

Here's what that looks like in TypeScript:

import { chromium } from 'playwright';

// The hosted browser API returns a CDP endpoint when you create a session.
// The session is already running in the cloud; you just attach to it.
const browser = await chromium.connectOverCDP(
  'wss://api.remote-browser.dev/v1/sessions/abc123/cdp'
);

// A default context is exposed by the CDP connection.
const context = browser.contexts()[0] || await browser.newContext();
const page = await context.newPage();

await page.goto('https://example.com', { waitUntil: 'domcontentloaded' });
console.log('Page title:', await page.title());

// Take a screenshot to verify state.
await page.screenshot({ path: 'example.png' });

// The session remains alive after this script exits,
// so a later run can reconnect and continue.
await browser.close();

Note what's different from a local Playwright script: the browser was provisioned out-of-band, it persists after your script exits, and you can reconnect to the same session later. That single capability unlocks most of the production use cases — long-running agents, human-in-the-loop approval flows, and stateful multi-step automations. Playwright's official CDP documentation covers the connectOverCDP behavior in more detail if you want to understand the mechanics.

Hosted browser API vs. local vs. DIY

There's a middle ground between running a local browser and using a hosted browser API: standing up your own browser infrastructure on cloud VMs. It's educational, but it's not a good use of engineering time. Here's how the three approaches compare:

The DIY path looks appealing on a whiteboard ("it's just Chromium in a container!") and becomes a full-time job in practice. You own base images, Chromium version drift, zombie process cleanup, network security, session proxying, and a WebSocket gateway. Meanwhile, the hosted browser API abstracts all of that behind a session endpoint, and you get back the engineering time you'd have spent building browser infrastructure instead of shipping your actual product.

Why browser-use teams move to a hosted browser API in production

Browser-use has become the default open-source framework for letting AI agents drive real browsers. The pattern is straightforward: the agent gets a task, decides on actions, and the framework executes them in a browser. In development, that browser is local headless Chromium. In production, the browser layer needs to be dramatically more robust — and that's where a hosted browser API becomes the missing runtime layer.

Consider what a production browser-use agent actually needs:

• 24/7 availability. An agent monitoring a competitor's site or performing nightly reconciliations can't depend on a laptop or a CI runner spinning up.
• Session continuity. A long-running agent that logs into a dashboard once and operates across multiple steps needs the session to survive between calls.
• Concurrent workloads. Multiple agents working on different tasks require isolated browser sessions that don't share cookies, tabs, or local storage.
• Observability for debugging. When an agent takes a wrong turn, you need to see what it did — a live viewer and session history are worth more than another log line.
• A stable connection protocol. Since browser-use drives the browser via CDP, any runtime that exposes a CDP endpoint is compatible. That's exactly what a hosted browser API exposes.

This is also why browser-use alternatives — custom web agent frameworks, in-house agent runtimes, and orchestration platforms — increasingly default to hosted browser APIs rather than bundling a browser. If your agent runtime is a container, adding a browser to that same container couples scaling of the agent to scaling of the browser. With a hosted browser API, the agent and the browser scale independently, and each session is just an API resource.

Security, isolation, and session controls

Once browser sessions become infrastructure, they inherit infrastructure expectations: isolation, access control, and limits. A hosted browser API has to deliver on all three.

Session isolation. Each session runs in its own browser context, so credentials, cookies, and site data from one workload never leak into another. For a team running multiple agents or test suites, this is non-negotiable.

Proxy and network configuration. Some sites are region-restricted or aggressively rate-limit traffic. A hosted browser API gives you configurable proxy settings per session, so you can route traffic through the right egress point without building that into your application code. The API also exposes browser settings that help you present a consistent, ordinary-looking session to target sites — useful for production automation that has to coexist with bot detection.

Usage controls. Unattended agents can spin out of control — infinite retry loops, memory-hungry pages, sessions that never terminate. Usage controls let you set session timeouts, idle limits, and resource bounds before a problem becomes a bill.

Security isn't an afterthought here; it's the difference between a browser API you can trust with production workloads and a toy you only use for prototypes. The control plane around sessions is what makes the browser part of your infrastructure rather than a liability inside it.

Getting started with a hosted browser API

The practical path to a hosted browser API starts with a single session. Create one, connect to it with Playwright or your browser-use setup, and run a task end-to-end. You'll notice the differences immediately: the session persists after your script exits, you can watch it live, and you can reconnect from any machine.

For a deeper look at the architecture and how hosted browser sessions fit into AI agent workloads, start with the remote browser for AI agents post. If you're evaluating the runtime layer specifically, the remote web browser guide covers the practical details of running real Chromium without managing Chrome yourself. And for implementation details, the documentation has the full API surface, session lifecycle, and integration examples for Playwright, Puppeteer, and Selenium.

Pricing for hosted browser sessions varies by provider, and the details change over time — check the pricing page for current rates and limits before you commit to a workload design. The broader point stands regardless of which platform you choose: when browser sessions become infrastructure, your automation stops being a collection of fragile scripts and starts being a service you can actually operate.

The browser is not your application — and that's the point

Teams that succeed with web automation and AI agents share a common realization: the browser is an execution medium, not the product. Your agent's value comes from what it accomplishes on the web, not from its ability to launch Chromium. A hosted browser API respects that boundary by making the browser a consumable, disposable, observable resource — infrastructure in the same sense as a message queue or a managed database.

The shift from local process to hosted session API is where browser automation matures. Once you're provisioning and releasing browser sessions the same way you provision compute or storage, you can stop thinking about "how do I keep a browser alive?" and start thinking about the actual problem: what should the agent or the test accomplish next.

That's the real case for the hosted browser API. Not cheaper browsers, not faster scripts — a fundamentally better model for how software and agents interact with the web.