Browser Remote Control: How to Drive Hosted Chromium from Anywhere

Browser remote control is the practice of driving a browser instance that runs on infrastructure you don't manage locally. Instead of launching Chrome on your laptop or a single EC2 instance, you connect to a hosted Chromium session over the network using protocols like the Chrome DevTools Protocol (CDP), Playwright, or Puppeteer. This approach solves a set of production problems that local browser automation cannot: session persistence, horizontal scaling, network egress quality, and team-wide access to the same browser state.

For AI agents, browser remote control is not a convenience—it's a requirement. A web agent that runs a task for 30 minutes needs a browser that stays alive, holds cookies, and maintains a consistent profile. If that browser lives on a developer's machine, the task fails the moment the laptop sleeps. If it lives in a container that gets recycled, the agent loses its login state. Remote Browser provides a hosted Chromium runtime designed for exactly these workloads.

This guide covers what browser remote control means in practice, how to connect to a hosted browser with Playwright and CDP, and the production criteria you should evaluate before choosing a remote browser infrastructure.

What Is Browser Remote Control?

Browser remote control is the ability to send commands to a browser process that is not running on your local machine. The browser runs in a data center, on a VM, or in a container, and you interact with it through a WebSocket or HTTP endpoint.

The most common protocol for this is CDP. CDP is the same protocol Chrome DevTools uses to inspect pages. It exposes methods for navigation, DOM manipulation, network interception, JavaScript execution, and input events. Playwright and Puppeteer both speak CDP under the hood, which means you can use their high-level APIs to control a remote browser without writing raw CDP commands yourself.

There are two architectural patterns for browser remote control:

1. Connect to an existing session. You start a browser on a remote host, then connect to it from your application. This is what Playwright's connectOverCDP does. The browser keeps running even if your client disconnects.
2. Launch a browser on demand. You call an API that spins up a fresh browser instance, run your automation, then tear it down. This is the model most cloud browser APIs use.

Remote Browser supports both patterns. You can launch a new session via the API, or connect to an existing session using its CDP endpoint.

Why Local Browser Automation Breaks in Production

Local browser automation works fine for a script that runs for 30 seconds on your machine. It breaks in production for reasons that have nothing to do with the quality of your code.

Session lifetime. A local browser dies when your machine sleeps, reboots, or loses power. An AI agent that needs to run for hours cannot depend on a local process.

Concurrency. If you need 50 parallel browser sessions for a scraping job or a load test, your laptop cannot handle it. You need distributed infrastructure.

Network egress. Websites see requests coming from your local IP. If you are scraping or testing geo-specific content, you need to control the IP address the browser uses. A hosted browser lets you attach proxies and choose egress locations.

Team access. If three developers need to debug the same browser session, a local browser is useless. A remote browser with a live viewer lets everyone see the same screen.

Profile persistence. Logins, cookies, and local storage need to survive across sessions. A local browser profile is tied to one machine. A hosted browser with persistent profiles gives your agent a stable identity.

How to Connect to a Remote Browser with Playwright

Playwright is the most common way to control a remote browser. The library supports connecting to an existing browser over CDP with chromium.connectOverCDP(). Here is a TypeScript example that connects to a Remote Browser session, navigates to a page, and extracts data:

import { chromium } from 'playwright';

// The CDP endpoint from your Remote Browser session
const CDP_ENDPOINT = 'wss://remote-browser.dev/cdp/session_abc123';

async function main() {
  // Connect to the existing hosted Chromium session
  const browser = await chromium.connectOverCDP(CDP_ENDPOINT);

  // The default context is the one the remote browser started with
  const context = browser.contexts()[0];
  const page = context.pages()[0] || await context.newPage();

  // Navigate and interact
  await page.goto('https://example.com');
  await page.click('button#accept-cookies');
  
  const title = await page.title();
  console.log(`Page title: ${title}`);

  // Keep the browser connected; the session stays alive on the server
  // Do NOT call browser.close() if you want to reuse the session later
}

main().catch(console.error);

Key points about this pattern:

• connectOverCDP attaches to an existing browser. It does not launch a new one.
• The browser session continues to run on the remote host even after your script exits.
• You can disconnect and reconnect later, as long as the session has not been terminated.
• If you call browser.close(), you close the connection, not the remote browser process. To terminate the remote session, use the Remote Browser API.

Keeping Browser Sessions Alive Across Workers

A common question from teams building AI agents is: *how do I keep a browser session alive across multiple cloud workers?*

The answer is to separate the browser process from the worker process. The browser runs as a long-lived service on a remote host. Workers connect to it, perform tasks, and disconnect. The browser state—cookies, local storage, DOM—persists on the remote host.

This pattern is useful for:

• Multi-step tasks. An agent logs into a site, then a different worker completes a purchase. Both workers connect to the same session.
• Retry logic. If a worker crashes mid-task, a new worker can reconnect to the same browser and resume from where the previous one stopped.
• Human-in-the-loop workflows. A human reviews the browser state in a live viewer, then approves an action that a worker executes.

Remote Browser supports this with persistent profiles and session isolation. Each session has a unique ID. You can reconnect to it from any worker as long as the session is active.

CDP: The Underlying Protocol

If you are building custom tooling, you may want to work with CDP directly instead of using Playwright or Puppeteer. CDP gives you fine-grained control over the browser, including network interception, performance tracing, and JavaScript debugging.

Here is a minimal example of connecting to a remote browser over CDP using the ws library in Node.js:

import WebSocket from 'ws';

const ws = new WebSocket('wss://remote-browser.dev/cdp/session_abc123');

ws.on('open', () => {
  // Enable the Page domain
  ws.send(JSON.stringify({
    id: 1,
    method: 'Page.enable',
    params: {}
  }));

  // Navigate to a URL
  ws.send(JSON.stringify({
    id: 2,
    method: 'Page.navigate',
    params: { url: 'https://example.com' }
  }));
});

ws.on('message', (data) => {
  const msg = JSON.parse(data.toString());
  if (msg.id === 2) {
    console.log('Navigation complete');
    // Evaluate JavaScript in the page
    ws.send(JSON.stringify({
      id: 3,
      method: 'Runtime.evaluate',
      params: { expression: 'document.title' }
    }));
  }
  if (msg.id === 3) {
    console.log('Title:', msg.result.result.value);
    ws.close();
  }
});

Raw CDP is powerful but verbose. For most use cases, Playwright or Puppeteer is the better choice because they handle session management, waiting, and retries for you.

Browser Remote Control vs. Browser Automation APIs

There is a distinction between browser remote control and browser automation APIs. A browser automation API typically abstracts away the browser entirely. You send a command like "click the login button" and the API returns a result. You never see the browser.

Browser remote control is lower-level. You get a CDP endpoint, a live viewer, and direct access to the browser. You are responsible for writing the automation logic, but you also get full control over the browser's behavior.

For AI agents, the lower-level approach is usually better. Agents need to see the page, make decisions, and adapt. A high-level API that hides the browser makes it harder to debug failures and harder to handle unexpected page states.

Remote Browser is positioned as a runtime: it gives you the browser, the CDP endpoint, and the tooling to observe and control it. You bring your own agent logic, whether that is a Playwright script, a Puppeteer script, or a custom CDP client.

Production Criteria for Remote Browser Infrastructure

When evaluating a browser remote control solution, consider these criteria:

Session persistence. Can you disconnect and reconnect to the same session? Does the browser keep its cookies and local storage?

Live debugging. Can you see what the browser is doing in real time? A live viewer is essential for debugging AI agents that go off the rails.

Proxy support. Can you attach a proxy to the session? This matters for geo-targeted testing and for avoiding IP-based rate limiting.

Usage controls. Can you set timeouts and limits on sessions? You do not want a runaway agent burning browser hours indefinitely.

API stability. Is the API well-documented? Does it support the protocols you already use (CDP, Playwright, Puppeteer)?

When Browser Remote Control Makes Sense

Browser remote control is not the right tool for every job. If you are running a simple script that takes 10 seconds and runs once a day, a local browser is fine. But if you are building anything that runs unattended, needs to scale, or requires a stable browser identity, remote control is the better choice.

Use cases that benefit most:

• AI web agents. Agents need long-lived sessions, persistent profiles, and the ability to recover from failures.
• Web scraping at scale. You need many parallel sessions and control over egress IPs.
• Cross-browser testing. You need to run tests against multiple browser versions and view the results remotely.
• 24/7 monitoring. You need a browser that stays alive and reports on page state continuously.

Getting Started with Remote Browser

Remote Browser provides a hosted Chromium runtime with a CDP endpoint, Playwright and Puppeteer compatibility, a live viewer, and persistent profiles. The documentation covers the API in detail, including how to create sessions, connect over CDP, and manage profiles.

For a deeper look at how remote browsers fit into AI agent workflows, see our post on remote browsers for AI agents. If you are evaluating whether a hosted browser is right for your use case, the remote browser online guide covers the practical differences between local and hosted setups.

Pricing is metered per browser-hour, with no subscription required. Current rates and plan details are available on the pricing page.

Conclusion

Browser remote control is the infrastructure layer that makes production browser automation possible. It decouples the browser from the machine that drives it, enabling persistent sessions, horizontal scaling, and team-wide visibility. For AI agents, this is not optional—it is the difference between a demo that works on your laptop and a system that runs reliably in production.

The protocol is mature. Playwright's connectOverCDP and raw CDP both give you full control over a remote browser. The challenge is not the protocol; it is the infrastructure. You need a browser that stays alive, a network path that does not get blocked, and tooling that lets you see what the browser is doing.

Remote Browser provides that infrastructure. Connect to a hosted Chromium session, run your automation, and keep the session alive for as long as you need it. The browser is in the cloud, but the control is yours.