A Cloud Browser for AI Agents: What It Is and How to Run One

# A Cloud Browser for AI Agents: What It Is and How to Run One

A cloud browser is a real Chromium instance running on a provider's servers instead of your laptop or CI runner. Your code or AI agent connects to it over the network — typically through the Chrome DevTools Protocol (CDP) — drives it like a local browser, and stops it when the task finishes. For AI agents, a cloud browser removes the hardest part of production: keeping a stateful, isolated, observable browser alive while the model thinks, retries, and navigates. This guide explains how a cloud browser works, how to connect one, and what to evaluate before you depend on it.

Why AI agents need a cloud browser at all

A local Chrome window works fine for a demo. It falls apart the moment an agent runs unattended. The failure modes are predictable:

• The process dies with your script. An agent that takes 40 seconds per step and runs 30 steps needs a browser that survives network blips, worker restarts, and deploy cycles.
• State is trapped on one machine. Cookies, localStorage, and logged-in sessions live in a profile directory. If your worker is ephemeral, that state evaporates.
• You can't see what happened. When an agent fails at step 22, you need a live view or a recording, not a stack trace.
• Isolation is an afterthought. Two agents sharing one browser leak cookies, tabs, and focus between each other.

A cloud browser addresses all four by making the browser a network service. The session has a lifecycle independent of your code, a stable endpoint, and a viewer you can open in a tab. Remote Browser packages this as hosted Chromium sessions with CDP access, Playwright/Puppeteer/Selenium compatibility, persistent profiles, configurable browser settings, session isolation, and usage controls. See remote browsers for AI agents for the broader runtime picture.

How a cloud browser actually works

The architecture is simpler than the marketing suggests. Three pieces:

1. A session — a Chromium process (or a small pool) with its own profile, network identity, and lifecycle. You create it with an API call and get back a connection endpoint.
2. A transport — CDP over WebSocket. Every modern automation library speaks it: Playwright via connectOverCDP, Puppeteer via browserWSEndpoint, Selenium via the CDP bridge or a remote WebDriver endpoint.
3. A control plane — the API that creates, lists, and stops sessions, plus the viewer, recordings, and usage metering.

Your agent code never touches the browser binary. It opens a WebSocket, sends CDP commands, and receives events. That is the same protocol Chrome uses internally, so anything that works against local Chrome works against a hosted one — with the caveat that some launch flags and filesystem paths differ.

The Chrome DevTools Protocol documentation is the authoritative reference for the domains you'll use: Page, Runtime, Network, DOM, and Target.

Connecting an agent to a hosted Chromium session

The typical flow: create a session through the API, read the CDP WebSocket URL from the response, connect, run the task, then stop the session. Here is a TypeScript example using Playwright's connectOverCDP:

import { chromium } from "playwright";

type Session = { id: string; cdpUrl: string };

async function createSession(): Promise<Session> {
  const res = await fetch(`${process.env.RB_API_URL}/sessions`, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      Authorization: `Bearer ${process.env.RB_API_KEY}`,
    },
    body: JSON.stringify({
      // Persistent profile keeps logins across sessions
      profileId: "agent-checkout-v3",
      // Configurable browser settings: viewport, locale, timezone, proxy
      viewport: { width: 1440, height: 900 },
      locale: "en-US",
    }),
  });
  if (!res.ok) throw new Error(`session create failed: ${res.status}`);
  return res.json();
}

async function runTask() {
  const session = await createSession();
  const browser = await chromium.connectOverCDP(session.cdpUrl);

  try {
    const context = browser.contexts()[0] ?? (await browser.newContext());
    const page = await context.newPage();

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

    // Agent logic goes here: read DOM, click, fill forms, extract data
    const title = await page.title();
    console.log("loaded:", title);
  } finally {
    await browser.close(); // detaches; does not necessarily stop the session
  }
}

Two details matter in production. First, browser.close() on a CDP connection detaches your client — it does not always terminate the remote session. Stop the session explicitly through the API so you aren't billed for an idle browser. Second, always wrap the task in try/finally; a thrown error inside an agent loop is the most common cause of orphaned sessions.

If you'd rather not manage the connection lifecycle yourself, the documentation covers the session API, viewer, and profile endpoints in detail.

What to evaluate in a cloud browser

Not every hosted browser is built for agent workloads. The differences show up under load, not in a hello-world test. Here is a comparison of the criteria that actually matter:

The metering row deserves emphasis. Agent workloads are bursty: ten agents may run for two minutes, then one runs for an hour. A per-browser-hour model maps cleanly to that; a per-request model can surprise you. Remote Browser's current rates and plan details are on the pricing page — check there rather than relying on secondhand numbers, since hosted browser pricing changes frequently across the market.

Cloud browser vs. self-hosted Playwright

The honest trade-off is control versus operational load. Self-hosting means you run Chromium in containers, manage a pool, handle zombie processes, patch the browser, and build your own viewer. That is a real engineering project — often several weeks before the first reliable agent run.

A cloud browser trades some low-level control (you can't mount arbitrary filesystem paths or install Chrome extensions freely) for a managed lifecycle. For most agent teams the trade is worth it. For teams that need custom Chromium builds or unusual launch flags, self-hosting or a provider with custom image support may fit better.

A middle path: use a cloud browser for the agent's interactive work and keep your own infrastructure for deterministic, high-volume scraping where you control every variable. Many production stacks run both.

Production patterns that hold up

A few patterns separate agents that work from agents that demo well.

One session per task, not per agent. Reusing a session across unrelated tasks leaks state and makes failures hard to attribute. Create a session, run the task, stop it.

Persist profiles deliberately. A profile is a credential store. Treat profileId like a secret: scope it per customer or per workflow, and rotate it when a login is revoked. Persistent profiles are the main reason agents can skip login flows on repeat runs.

Set timeouts at every layer. Page navigation timeout, per-step timeout, and a hard session timeout. The session timeout is your backstop against a model that loops forever.

Record and review failures. A live viewer helps during development; recordings help after the fact. When an agent fails in production, the recording is usually the fastest path to the root cause.

Watch concurrency, not just cost. Your provider's concurrency limits determine how many agents can run at once. Plan capacity against peak, not average. If you're running many parallel automations, the infrastructure setup guide covers the capacity side.

Keep the agent loop outside the browser. The model decides; the browser executes. Don't put retry logic inside a page script — it will be lost on navigation.

Common mistakes

• Assuming `browser.close()` stops billing. It usually doesn't. Call the stop endpoint.
• Hardcoding a CDP URL. Session URLs are per-session and expire. Read them from the create response every time.
• Ignoring locale and timezone. A site that renders prices in EUR because the browser defaults to a European timezone will confuse an agent trained on USD pages. Set them explicitly.
• Sharing one context across parallel tasks. Playwright contexts are cheap; use one per task.
• Skipping the viewer during development. Watching the agent navigate is the fastest way to find selector drift.

When a cloud browser is the wrong choice

Be honest about fit. A cloud browser adds network latency to every CDP command — usually negligible for agent workflows where the model's thinking time dominates, but noticeable for tight, high-frequency automation loops. If you're running thousands of sub-second interactions per minute, local or co-located browsers may be faster.

It's also the wrong choice if you need deep OS-level control: custom fonts, native file dialogs, or hardware-backed DRM. Hosted Chromium gives you a browser, not a desktop.

For everything else — agents that log in, navigate, fill forms, extract data, and need to be debuggable — a cloud browser is the pragmatic default. If you want to try one without local setup, the online remote browser guide walks through the first session, and the remote control browser overview explains how code and agents share the same runtime.

The bottom line

A cloud browser is infrastructure, not a feature. The value comes from what it removes: process management, profile plumbing, viewer tooling, and isolation bugs. Choose one by checking the connection protocol, session lifecycle, profile model, observability, and metering — in that order. Then write the agent loop so that every session has an owner, a timeout, and a stop call. That discipline matters more than which provider you pick.