Browser Use Remote Browser Chrome: Hosted Chromium Guide

# Browser Use Remote Browser Chrome: Hosted Chromium Guide

If you're running browser use remote browser chrome workflows, the core question is simple: where does the actual Chrome process live? In a local setup, it lives on your laptop or CI runner, and your agent talks to it over a local port. In a remote setup, Chrome runs in a hosted environment and your agent connects over the network using the Chrome DevTools Protocol (CDP). That single change — moving the browser off your machine — is what separates a demo from something you can run continuously.

This guide explains how remote Chrome sessions work with browser-use style agents, how to wire them up with Playwright and CDP, and what to check before you put one in production.

What "Remote Browser Chrome" Actually Means

A remote browser is a real Chromium instance running on infrastructure you don't manage. You don't install Chrome, you don't patch it, and you don't keep a machine awake to hold the session. Instead, you request a session, get back a CDP endpoint (a WebSocket URL), and connect your automation code to it.

For browser-use style agents, this matters because the agent loop — observe the page, decide an action, execute it — depends on a stable, long-lived browser context. When that context lives on your laptop, it dies when you close the lid. When it lives in a hosted runtime, it survives across workers, restarts, and deploys.

Remote Browser provides hosted Chromium sessions with CDP access, Playwright/Puppeteer/Selenium compatibility, a live viewer, persistent profiles, configurable browser settings, and session isolation. You can read the full capability list in the documentation.

Why Move Chrome Off Your Machine

Local Chrome is fine for development. It becomes a liability in three specific situations:

• Long-running agents. A task that polls a dashboard every ten minutes for six hours needs a browser that stays alive. A local Chrome tied to a terminal session does not.
• Parallel workloads. Ten agents need ten isolated browser contexts. Running ten Chrome instances on one laptop means memory pressure, port conflicts, and cross-session cookie leakage.
• Protected or geo-specific sites. Some sites behave differently based on IP reputation and region. A hosted runtime lets you configure proxy and browser settings per session rather than fighting your home network.

There's also the operational angle. When Chrome runs remotely, your agent code becomes stateless. You can deploy it to a serverless function, a container, or a queue worker, and it connects to the browser the same way every time. That's the same reasoning behind remote browser for AI agents as a runtime layer.

How the Connection Works: CDP in Practice

CDP is the wire protocol Chrome exposes for external control. Playwright, Puppeteer, and Selenium all speak it (Selenium via a driver, Playwright and Puppeteer natively). When you connect to a remote browser, you're opening a WebSocket to a CDP endpoint and issuing commands over it.

The flow looks like this:

1. Your code requests a session from the remote browser API.
2. The API returns a CDP WebSocket URL and a session ID.
3. Your Playwright/Puppeteer client calls connectOverCDP with that URL.
4. Commands flow over the WebSocket; the hosted Chromium executes them.
5. You close the session when done, or let it expire.

Here's a minimal TypeScript example using Playwright:

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

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

async function connectToRemoteChrome(session: SessionInfo): Promise<{
  browser: Browser;
  page: Page;
}> {
  // connectOverCDP attaches to an already-running Chromium.
  // No local Chrome binary is launched.
  const browser = await chromium.connectOverCDP(session.cdpUrl, {
    timeout: 30_000,
  });

  // Reuse the existing context if the session already has one,
  // otherwise create a fresh context.
  const contexts = browser.contexts();
  const context = contexts.length > 0
    ? contexts[0]
    : await browser.newContext();

  const page = await context.newPage();

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

  return { browser, page };
}

async function run() {
  const session: SessionInfo = {
    cdpUrl: process.env.REMOTE_CDP_URL!,
    sessionId: process.env.REMOTE_SESSION_ID!,
  };

  const { browser, page } = await connectToRemoteChrome(session);

  try {
    const title = await page.title();
    console.log('Page title:', title);
  } finally {
    // Close the connection, not the remote browser, unless you own it.
    await browser.close();
  }
}

run().catch((err) => {
  console.error('Remote browser task failed:', err);
  process.exit(1);
});

Two details matter here. First, connectOverCDP does not launch a browser — it attaches to one. If you're used to chromium.launch(), the mental model is different. Second, browser.close() closes your connection; whether it terminates the remote session depends on how the session was created. Check your runtime's session lifecycle docs before assuming either behavior.

For the protocol-level details, the Chrome DevTools Protocol documentation is the authoritative reference, and Playwright's CDP connection guide covers the client side.

Local Chrome vs Hosted Chromium: A Comparison

The trade-off is straightforward: hosted Chromium costs money per session-hour and adds network latency to every CDP command. Local Chrome is free and fast but doesn't survive a laptop lid closing. For anything that needs to run unattended, the hosted option wins on reliability alone.

Wiring Browser-Use Style Agents to Remote Chrome

Browser-use agents typically operate in a loop: capture the DOM or accessibility tree, ask a model what to do, execute the action, repeat. The browser is the agent's hands. If the hands disappear mid-task, the agent fails.

When you point a browser-use agent at a remote Chrome session, three things change:

The agent becomes stateless. Your agent process can crash and restart without losing the browser. Reconnect to the same CDP URL and the page is still there.

Observation gets cheaper to parallelize. Multiple agents can each hold their own session, so you're not serializing tasks through one browser.

Debugging gets easier. A live viewer lets you watch what the agent is doing in real time, which is far more useful than reading a log of failed selectors. Remote Browser exposes this through its viewer, and the remote control browser post covers the interaction model.

If you're using a Hermes-style agent browser UI or a browser skill, the integration point is the same: the skill needs a CDP endpoint, not a local Chrome path. Most agent frameworks accept a connection URL as a configuration value, so the change is usually a config swap rather than a code rewrite.

Production Criteria Before You Commit

Before you move a workload to hosted Chromium, check these:

• Session lifecycle. How long can a session live? What happens on idle? Can you reconnect to an existing session after a network blip?
• Profile persistence. Does the runtime keep cookies, localStorage, and login state across sessions? This matters for anything behind auth.
• Proxy and network controls. Can you set a proxy per session? Are there region options? IP quality affects success rates on protected sites.
• Isolation. Are sessions isolated from each other? Shared state between concurrent agents is a correctness bug waiting to happen.
• Observability. Can you watch a session live? Can you pull a trace or a screenshot after a failure?
• Usage controls. How is usage metered, and can you cap it? Unbounded browser-hours are an unbounded bill.

Remote Browser addresses these with session isolation, persistent profiles, configurable browser settings, a live viewer, and usage controls. Current pricing and limits are on the pricing page — check there rather than assuming a number.

Common Mistakes When Connecting Remotely

Launching instead of connecting. If your code calls chromium.launch() while also holding a remote CDP URL, you're running two browsers and wondering why your actions don't land. Use connectOverCDP.

Assuming `browser.close()` kills the session. It usually doesn't. If you're paying per browser-hour, orphaned sessions are wasted spend. Close sessions explicitly when your task is done.

Ignoring reconnect logic. Networks drop. A production agent should catch a CDP disconnect and attempt to reconnect to the same session before declaring failure.

Hardcoding timeouts. Remote CDP commands cross a network. A 5-second timeout that works locally may be too tight for a cold remote session. Set timeouts based on measured latency, not habit.

Skipping the live viewer during development. Watching a session run is the fastest way to find out that your agent is clicking the wrong element. Use it before you ship.

When Local Chrome Is Still the Right Call

Remote browsers aren't universally better. Keep Chrome local when:

• You're iterating on selectors and want zero network latency.
• The task is short, single-shot, and runs on your machine anyway.
• You need a browser extension or a specific local Chrome profile that can't be reproduced remotely.
• You're testing something that depends on your local network or hardware.

The decision rule is simple: if the browser needs to outlive your process, run it remotely. If it doesn't, local is fine.

Getting Started

The shortest path is: create a session, grab the CDP URL, and connect with connectOverCDP. Everything else — profiles, proxies, viewers — is configuration on top of that. Start with the documentation for the session API, then look at remote browser online if you want to try a session without writing code first.

The point of a remote browser isn't novelty. It's that your agent's browser stops being a thing you babysit and becomes a thing you call.