DEV Community: RemoteBrowser

Playwright Remote: Run Browser Automation in the Cloud

RemoteBrowser — Tue, 01 Sep 2026 04:22:06 +0000

Playwright Remote: Run Browser Automation in the Cloud

Running Playwright against a remote browser is the difference between a script that works on your laptop and an automation pipeline that survives production. When you connect Playwright to a hosted Chromium instance over the Chrome DevTools Protocol (CDP), you get persistent sessions, clean IP reputation, and the ability to scale across workers without managing browser infrastructure yourself.

This guide covers what Playwright remote execution actually means, how to connect to a hosted browser over CDP, and the production criteria that matter when you move from local scripts to cloud-hosted sessions.

Why "Playwright Remote" Is More Than a Hostname Change

Playwright's connect_over_cdp() method lets you attach to an already-running browser. Locally, that's useful for debugging. In production, it's the foundation for a different architecture: the browser lives in the cloud, your code connects to it, and the session persists independently of your worker process.

This matters for three reasons:

Session persistence — A browser that survives worker restarts keeps cookies, localStorage, and login states intact.
IP consistency — The browser's egress IP stays stable, which matters for sites that flag automation traffic.
Resource isolation — Your Playwright script runs in a lightweight worker while the heavy browser process runs elsewhere.

The common alternative — launching a browser inside your worker — couples browser lifecycle to code lifecycle. If your worker dies, the browser dies. If you need to retry a task, you start from zero.

How to Connect Playwright to a Remote Browser

Remote Browser exposes hosted Chromium sessions via CDP. Your Playwright script connects using connect_over_cdp(). Here's a minimal TypeScript example:

import { chromium } from 'playwright';

async function main() {
  // Connect to a hosted Chromium session via CDP
  const browser = await chromium.connectOverCDP(
    'wss://remote-browser.dev/cdp/your-session-id'
  );

  // The default context is the browser's persistent context
  const context = browser.contexts()[0];
  const page = await context.newPage();

  await page.goto('https://example.com');
  console.log(await page.title());

  // The browser stays alive after your script exits
  await browser.close();
}

main().catch(console.error);

The key detail: browser.close() disconnects your client but doesn't terminate the hosted browser. That's the semantic shift from local Playwright. You're a client, not the owner.

CDP vs. Playwright's WebSocket Protocol

Playwright has two remote connection modes:

Mode	Method	Use Case
CDP	`connectOverCDP()`	Attach to existing Chrome/Chromium, persistent sessions, cross-language control
Playwright Protocol	`connect()`	Connect to a Playwright server, full control over browser lifecycle

For AI agents and long-running automation, CDP is usually the right choice. It lets you attach to a browser that someone else manages, and it's the standard protocol for browser tooling. Playwright's own documentation covers CDP connection details if you need the full API reference.

Production Criteria for Playwright Remote Setups

Not all remote browser services are equal. When evaluating a Playwright remote setup, check these criteria:

1. Session Lifecycle Control

Your browser session should outlive any single script execution. Look for:

Sessions that persist until explicitly terminated
Ability to reconnect after network drops
Snapshot or restore capabilities for long-running tasks

2. Live Debugging and Visibility

When a Playwright script fails in production, you need to see what happened. A live viewer or session replay is not a luxury — it's how you debug flaky selectors and unexpected popups.

3. Proxy and IP Management

Sites increasingly block datacenter IPs. A remote browser service should let you configure proxy settings per session, so you can route traffic through residential or clean IPs when needed.

4. Profile Persistence

Cookies, localStorage, and browser profiles should survive across connections. This is what makes "login once, use many times" workflows possible.

5. Compatibility Layer

Your existing Playwright code should work without rewrites. If you need to switch from launch() to connectOverCDP(), that's fine. If you need to rewrite your entire automation logic, that's a red flag.

Playwright Remote vs. Local Browser Management

Here's a practical comparison:

Aspect	Local Playwright	Playwright Remote (Hosted Chromium)
Setup time	Minutes	Minutes (API key + session ID)
Session persistence	Tied to process	Independent of process
Scaling	Manual, per-machine	Add workers, reuse sessions
IP reputation	Your IP, your problem	Configurable egress IPs
Resource usage	Browser + script compete	Browser isolated in cloud
Debugging	Local DevTools	Live viewer, session logs
Cost	Hardware + maintenance	Metered browser hours

The trade-off is straightforward: local Playwright is fine for development and small test suites. Once you need reliability, persistence, or scale, remote execution wins.

Keeping Browser Sessions Alive Across Cloud Workers

A common pattern: you have multiple cloud workers (Lambda, Cloudflare Workers, Fly Machines) that need to share browser state. With Playwright remote, each worker connects to the same hosted browser session.

// worker-a.ts — logs in and stores state
import { chromium } from 'playwright';

const browser = await chromium.connectOverCDP(process.env.CDP_URL!);
const context = browser.contexts()[0];
const page = await context.newPage();

await page.goto('https://app.example.com/login');
await page.fill('#email', process.env.EMAIL!);
await page.fill('#password', process.env.PASSWORD!);
await page.click('button[type="submit"]');
await page.waitForURL('https://app.example.com/dashboard');

// Session state is now persisted in the hosted browser
await browser.close();

// worker-b.ts — reuses the session
import { chromium } from 'playwright';

const browser = await chromium.connectOverCDP(process.env.CDP_URL!);
const context = browser.contexts()[0];
const page = await context.newPage();

// Already authenticated
await page.goto('https://app.example.com/dashboard');
const data = await page.locator('.data-table').innerText();
console.log(data);

await browser.close();

This pattern eliminates re-login overhead and keeps state consistent across your fleet.

Playwright Remote for AI Agents

AI agents that browse the web have different requirements than test suites. They need:

Long-lived sessions — Agents can run for hours, not minutes
Human-like behavior — Configurable browser settings to avoid detection
Observability — See what the agent is doing in real time
Isolation — Separate sessions for separate tasks or users

Remote Browser's hosted Chromium is built for this. The remote browser for AI agents post covers the runtime layer in more detail, but the core idea is: your agent code connects to a browser that's already running, does its work, and disconnects — without killing the session.

The "Agent Browser" Confusion

You might see "agent browser" in your task manager or in product names. That's usually a browser process spawned by an automation tool. The term is overloaded — it can mean:

A browser controlled by an AI agent
A browser that runs agent tasks (like Remote Browser)
A browser process in Chrome's task manager (often just a renderer process)

For production AI workloads, what matters is whether the browser runtime supports the patterns above: persistence, CDP access, and live debugging.

Selenium and Puppeteer: The Same Remote Pattern

Playwright isn't the only automation library that benefits from remote browsers. Selenium's WebDriver protocol and Puppeteer's CDP support both work with hosted Chromium. The pattern is identical:

Start (or connect to) a hosted browser session
Get the connection endpoint (WebSocket URL for CDP, or a remote WebDriver URL)
Point your automation library at that endpoint
Run your script, disconnect, keep the browser alive

If you're standardizing on Playwright but have legacy Selenium tests, a remote browser service that supports both protocols lets you migrate incrementally.

Common Pitfalls with Playwright Remote

Pitfall 1: Assuming `browser.close()` Terminates the Session

In local Playwright, browser.close() kills the browser. With connectOverCDP(), it disconnects your client. The hosted browser keeps running. This is usually what you want, but it means you need explicit session termination for cleanup.

Pitfall 2: Ignoring Context Isolation

A hosted browser may have multiple contexts. Make sure you're operating in the right one. browser.contexts()[0] is the default, but if you create new contexts, track them explicitly.

Pitfall 3: Not Handling Reconnects

Network connections drop. Your Playwright client should handle disconnected events and reconnect to the same session. The browser state persists; your client connection doesn't have to.

Pitfall 4: Forgetting About Browser Version

Hosted browsers are managed by the service provider. If your Playwright version expects a specific Chromium version, check compatibility. Most services run recent stable Chromium, but pinning your Playwright version to match is safer.

When Not to Use Playwright Remote

Remote execution isn't always the answer. Consider local Playwright if:

You're running a small test suite with no persistence needs
You need to test browser extensions that require local installation
You have strict data residency requirements that prevent cloud browser usage
Your automation is short-lived and stateless

The decision hinges on whether you need persistence, scale, or IP management. If none of those apply, local is simpler.

Getting Started with Remote Browser

Remote Browser provides hosted Chromium sessions with CDP access, Playwright compatibility, and the production features discussed above. The documentation covers API details, and the pricing page has current rates for browser hours.

For a deeper dive into specific use cases:

Remote browser online — running Chromium without local setup
Remote web browser — the practical runtime for browser automation
Remote control browser — when code and agents need to drive the web

The Bottom Line on Playwright Remote

Playwright remote execution via CDP is the production pattern for browser automation that needs to survive beyond a single script run. It decouples browser lifecycle from code lifecycle, enables session persistence across workers, and gives you the observability you need to debug real-world automation.

The shift from chromium.launch() to chromium.connectOverCDP() is small in code but significant in architecture. You stop managing browsers and start using them as a service. For AI agents, multi-worker pipelines, and anything that needs consistent browser state, that's the right trade.

Start with a hosted Chromium session, connect your existing Playwright code, and see how much of your infrastructure overhead disappears.

What Is Agent Browser in Task Manager: A Practical Guide

RemoteBrowser — Tue, 01 Sep 2026 04:22:05 +0000

What Is Agent Browser in Task Manager: A Practical Guide

If you've opened Task Manager and spotted a process labeled "agent browser" or a similar browser-related entry, you're likely running an automation tool, an AI web agent, or a remote browser session. What is agent browser in task manager? In short, it's a browser instance—usually Chromium—that's being controlled programmatically rather than by a human clicking through tabs. These processes appear when tools like Playwright, Puppeteer, or Selenium launch a browser for automated tasks, or when an AI agent connects to a hosted browser runtime.

This guide explains what an agent browser is, why it shows up in your process list, how it differs from a regular browser, and what to do when you need to manage or debug these processes in production.

The Short Answer: It's a Programmatic Browser Process

An agent browser is a browser process that runs under the control of an external program—not a human user. When you see it in Task Manager, it's typically one of these:

A local Chromium or Chrome instance launched by a test framework (Playwright, Puppeteer, Selenium).
A remote browser session running on a cloud server, accessed via the Chrome DevTools Protocol (CDP).
A headless browser process that's part of an AI agent's runtime environment.

The process name might be chrome, chromium, headless_shell, or something custom like agent-browser. The key identifier is that it's being driven by code, not by mouse clicks.

Why Do Agent Browsers Appear in Task Manager?

Agent browsers appear in Task Manager for the same reason any browser does: they're running processes that consume CPU, memory, and network resources. The difference is that they're spawned and controlled by automation scripts or AI agents.

Here's a typical scenario:

You run a Playwright script that calls chromium.launch().
Playwright spawns a Chromium process on your machine.
That process appears in Task Manager as a browser process.
The script drives it via the DevTools Protocol, navigating pages, clicking elements, and extracting data.

When you're running a remote browser automation setup, the process might not be on your local machine at all. Instead, it's running on a cloud server, and you connect to it via CDP or WebSocket. In that case, you won't see it in your local Task Manager—but you will see it in the cloud provider's process monitoring tools.

Agent Browser vs. Regular Browser: Key Differences

Aspect	Regular Browser	Agent Browser
User input	Human clicks, types, scrolls	Programmatic commands via CDP, Playwright, or Selenium
Visibility	Visible window (usually)	Often headless, no UI
Session persistence	Tied to user profile	Can be ephemeral or persistent, depending on configuration
Lifecycle	Managed by user	Managed by automation script or AI agent
Process name	`chrome.exe`, `firefox.exe`	`chrome`, `chromium`, `headless_shell`, or custom names
Resource usage	Variable, user-dependent	Predictable, driven by script workload

The core difference is control. A regular browser responds to human input; an agent browser responds to code.

How AI Agents Use Browser Processes

AI agents—like those built on browser-use frameworks or custom LLM pipelines—need a browser to interact with the web. They use it to:

Navigate to pages and extract content.
Fill forms and submit data.
Click through multi-step workflows.
Scrape structured data.
Test web applications.

The agent sends commands to the browser via a protocol. The most common is the Chrome DevTools Protocol (CDP), which exposes browser internals for automation. Playwright and Puppeteer both use CDP under the hood.

Here's a minimal TypeScript example showing how to connect to an existing browser via CDP:

import { chromium } from 'playwright';

async function connectToAgentBrowser() {
  // Connect to an existing browser instance via CDP
  const browser = await chromium.connectOverCDP('http://localhost:9222');

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

  // Drive the browser programmatically
  await page.goto('https://example.com');
  const title = await page.title();
  console.log(`Page title: ${title}`);

  // Don't forget to close the connection
  await browser.close();
}

connectToAgentBrowser();

This is exactly what happens when you see an agent browser in Task Manager—something is connecting to a browser process and driving it programmatically.

Local vs. Remote Agent Browsers

There are two ways to run agent browsers:

Local Agent Browsers

You launch a browser on your own machine and control it with a script. This is common for development, testing, and small-scale automation.

Pros:

No network latency.
Easy to debug with DevTools.
No additional infrastructure costs.

Cons:

Tied to your machine's resources.
Not scalable for production workloads.
Sessions die when your machine sleeps or restarts.

Remote Agent Browsers

You run the browser on a cloud server and connect to it over the network. This is what services like Remote Browser provide—hosted Chromium instances that you control via API or CDP.

Pros:

Runs 24/7, independent of your local machine.
Scales horizontally across multiple workers.
Persistent sessions and profiles.
Better IP reputation for scraping and automation.

Cons:

Requires network connectivity.
Adds latency (mitigated by good infrastructure).
Costs money (though often cheaper than self-hosting).

For production AI agents, remote browsers are usually the right choice. They decouple the browser lifecycle from your application's lifecycle, which is critical for reliability.

How to Keep Browser Sessions Alive Across Multiple Cloud Workers

One of the most common questions about agent browsers is how to maintain session state across multiple workers. If you're running a distributed automation system, each worker might need to share cookies, localStorage, or login state.

The answer is persistent browser profiles. Instead of launching a fresh browser for each task, you connect to a browser that maintains a persistent profile. This profile stores cookies, local storage, and other session data.

With Remote Browser, you can create a persistent profile that survives across sessions. Multiple workers can connect to the same browser instance (or a pool of instances) and share state. This is how you keep sessions alive across cloud workers.

Here's what to look for in a remote browser solution:

Persistent profiles: The ability to save and restore browser state.
Session isolation: Each task gets a clean or shared context as needed.
Live debugging: The ability to watch what the browser is doing in real time.
CDP support: Standard protocol for connecting from any automation framework.

Playwright connect_over_cdp: Firefox Support and Limitations

If you're using Playwright's connect_over_cdp method, you might wonder about browser support. The official Playwright documentation states that connect_over_cdp works with Chromium-based browsers. Firefox support is limited—Playwright's Firefox implementation doesn't fully support CDP connections.

This matters because many AI agents are built on Chromium-based automation. If you need Firefox support, you'll need a different approach, such as Playwright's native Firefox automation (which doesn't use CDP) or a custom WebDriver setup.

For most agent browser workloads, Chromium is the pragmatic choice. It has the best CDP support, the largest ecosystem of automation tools, and the most consistent behavior across environments.

Agent Control Browser: What It Means for Production

"Agent control browser" is a term you'll see in some documentation. It refers to the browser instance that an AI agent controls—the one that executes the agent's commands. This is distinct from the agent's own runtime environment (the code that makes decisions) and the orchestration layer (the system that manages tasks).

In production, the agent control browser needs to be:

Reliable: It should not crash or hang under load.
Observable: You need to see what it's doing, ideally in real time.
Isolated: Each task should run in a clean or appropriately scoped context.
Scalable: You should be able to spin up multiple instances as needed.

This is where hosted browser runtimes shine. They handle the infrastructure so you can focus on the agent logic.

How to Give Your AI Agent Browser Access in Production

If you're building an AI agent that needs browser access in production, here's a practical checklist:

Choose a browser runtime: Decide between self-hosted Chromium and a hosted service. For production, hosted is usually better for reliability and scale.
Set up CDP connectivity: Your agent should connect to the browser via CDP or a higher-level library like Playwright.
Configure persistent profiles: If your agent needs to maintain login state, use persistent profiles.
Implement error handling: Browsers crash, networks fail, pages time out. Build retry logic into your agent.
Monitor resource usage: Track CPU, memory, and network usage per browser session.
Use session isolation: Don't let one task's state leak into another unless you intend to share it.

For a deeper dive, check out our guide on remote browsers for AI agents.

Debugging Agent Browsers: Live Viewer and CDP

When something goes wrong with an agent browser, you need visibility. Here's what to look for:

Live viewer: A real-time view of what the browser is rendering. This is invaluable for debugging navigation issues or form-filling errors.
CDP logs: Protocol-level logs showing every command sent to the browser.
Screenshot capture: Programmatic screenshots at key points in the workflow.
Console output: Browser console logs, including JavaScript errors.

Remote Browser provides a live viewer and CDP access, so you can watch your agent browser in action and debug issues as they happen.

Common Issues and Fixes

Issue: Chrome Remote Desktop Typing Fix

If you're using Chrome Remote Desktop and seeing typing issues, that's a different problem from agent browsers. Chrome Remote Desktop is for human remote access, not automation. Typing issues there are usually related to keyboard layout or input method conflicts.

For agent browsers, typing issues usually mean the automation script is sending keystrokes too fast or to the wrong element. Use Playwright's fill() method instead of type() for form inputs, and add explicit waits where needed.

Issue: Browser Sessions Not Persisting

If your agent browser loses session state between tasks, you're likely using ephemeral browser contexts. Switch to persistent profiles that save cookies and storage.

Issue: Too Many Browser Processes

If you see dozens of browser processes in Task Manager, your automation might be leaking sessions. Make sure you're closing browsers properly with browser.close() in a finally block.

When to Use a Hosted Agent Browser

You don't always need a hosted browser. For local development, a local Chromium instance is fine. But for production workloads, consider a hosted solution when:

You need 24/7 availability.
You're running multiple concurrent tasks.
You need persistent sessions across workers.
You want to avoid managing browser infrastructure yourself.

Remote Browser offers hosted Chromium sessions with CDP access, Playwright compatibility, and persistent profiles. It's designed for exactly this use case. Check our pricing page for current rates.

The Bottom Line

An agent browser in Task Manager is simply a browser process controlled by code rather than a human. It's the workhorse of web automation, AI agents, and browser testing. Understanding how it works—and how to manage it in production—is essential for anyone building browser-based automation.

Whether you run it locally or in the cloud, the key is to treat the browser as infrastructure: reliable, observable, and scalable. With the right setup, your agent browser will handle the web while you focus on the logic.

For more context on how remote browsers fit into your stack, read about remote browser online or explore the remote web browser approach. And if you're building an AI agent, our guide on remote control browser covers the practical details.

Agent Browser Record: How to Log and Replay AI Browser Sessions

RemoteBrowser — Mon, 31 Aug 2026 04:38:36 +0000

Agent Browser Record: How to Log and Replay AI Browser Sessions

When you run an AI agent that browses the web, you need more than a screenshot at the end. You need a full agent browser record—a replayable trace of every navigation, click, input, and network request. This is the difference between debugging a flaky agent in minutes versus hours.

In this guide, we'll cover what an agent browser record actually is, why it matters for production AI workloads, and how to implement it using hosted Chromium, CDP, and Playwright. We'll also compare the recording approaches and show you a concrete TypeScript example.

What Is an Agent Browser Record?

An agent browser record is a structured log of everything that happens inside a browser session driven by an AI agent. Unlike a simple video capture, a record includes:

DOM snapshots at each step
Network requests and responses (URLs, status codes, payloads)
Console logs and errors
Mouse and keyboard events (or their CDP equivalents)
Screenshots at configurable intervals
Agent decisions (the prompt, the tool call, the result)

The record is not just for post-mortem debugging. It's the foundation for:

Replaying a session to reproduce a bug
Evaluating agent performance against a benchmark
Auditing what an agent did (compliance, safety)
Training better agents with real interaction data

The term "agent browser record" is often conflated with "session recording" or "video replay." But for AI agents, the record must be machine-readable, not just human-viewable. You need to query it, diff it, and feed it back into your evaluation pipeline.

Why a Local Browser Record Isn't Enough

You can record a browser session locally with Playwright's built-in tracing or Chrome DevTools Protocol (CDP) methods. For a single script, that works. But in production, AI agents run across multiple cloud workers, often in ephemeral environments. Here's where local recording breaks down:

Concern	Local Browser	Hosted Chromium (Remote Browser)
Session persistence	Lost when the worker dies	Survives across workers via persistent profiles
Record storage	On the local disk, hard to share	Centralized, accessible via API
Live debugging	Requires port forwarding or VNC	Live viewer built into the runtime
Network visibility	Limited to local devtools	Full request/response logging at the proxy level
Scaling	One browser per machine	Many isolated sessions on demand
Replay fidelity	Depends on local environment	Deterministic in a controlled runtime

If you're running browser automations with Selenium or Playwright across a fleet of workers, you need the record to be a first-class artifact, not an afterthought.

How to Record an Agent Browser Session with CDP

The Chrome DevTools Protocol is the lowest-level interface for recording browser activity. Every Chromium-based browser exposes it. When you connect to a hosted browser via CDP, you can subscribe to events and build your own record.

Here's a minimal TypeScript example that connects to a Remote Browser session and captures network and console events:

import CDP from 'chrome-remote-interface';
import { RemoteBrowser } from '@remote-browser/sdk';

async function recordAgentSession() {
  // 1. Create a hosted browser session
  const browser = await RemoteBrowser.create({
    apiKey: process.env.REMOTE_BROWSER_API_KEY,
    // Persistent profile keeps cookies and state across sessions
    profileId: 'my-agent-profile',
  });

  // 2. Get the CDP websocket endpoint
  const cdpUrl = await browser.getCdpUrl();
  const client = await CDP({ target: cdpUrl });

  const { Network, Page, Runtime, Log } = client;

  // 3. Enable the domains we want to record
  await Network.enable();
  await Page.enable();
  await Runtime.enable();
  await Log.enable();

  // 4. Collect events into a structured record
  const record: any[] = [];

  Network.requestWillBeSent((params) => {
    record.push({
      type: 'network',
      timestamp: Date.now(),
      url: params.request.url,
      method: params.request.method,
      status: params.response?.status,
    });
  });

  Log.entryAdded((params) => {
    record.push({
      type: 'console',
      timestamp: Date.now(),
      level: params.entry.level,
      text: params.entry.text,
    });
  });

  Runtime.consoleAPICalled((params) => {
    record.push({
      type: 'console-api',
      timestamp: Date.now(),
      type: params.type,
      args: params.args.map((arg) => arg.value),
    });
  });

  // 5. Navigate and let the agent work
  await Page.navigate({ url: 'https://example.com' });
  await Page.loadEventFired();

  // 6. Save the record for later replay
  await browser.saveRecord(record, { format: 'jsonl' });

  // 7. Close the session or keep it alive for the next task
  await browser.close();
}

This gives you a raw event stream. For most production use cases, you'll want to enrich it with DOM snapshots and screenshots at key decision points.

Using Playwright Tracing for a Higher-Level Record

If you're already using Playwright, you don't need to hand-roll CDP event capture. Playwright's built-in tracing is a solid agent browser record format. It captures screenshots, DOM snapshots, network, and console in a single .zip file that you can open in the Playwright Trace Viewer.

Here's how to enable it on a hosted browser:

import { chromium } from 'playwright-core';
import { RemoteBrowser } from '@remote-browser/sdk';

async function recordWithPlaywright() {
  const browser = await RemoteBrowser.connect({
    apiKey: process.env.REMOTE_BROWSER_API_KEY,
    // Use the CDP endpoint to attach Playwright
    cdpUrl: await RemoteBrowser.getCdpUrl(),
  });

  const context = await browser.newContext({
    recordVideo: { dir: 'videos/' },
    trace: 'on', // Capture trace for every action
  });

  const page = await context.newPage();

  // Your agent loop here
  await page.goto('https://example.com');
  await page.click('text=Get Started');

  // Save the trace
  await context.tracing.stop({ path: 'agent-trace.zip' });

  // The trace file contains the full agent browser record
  await browser.uploadArtifact('agent-trace.zip');

  await browser.close();
}

The Playwright trace is excellent for debugging. But it's not ideal for feeding back into an LLM evaluation loop because it's a binary format. For that, you'll want a JSONL record of decisions and outcomes.

What to Record for AI Agent Evaluation

A raw event log is not an evaluation dataset. To actually measure agent performance, your record should include the agent's reasoning and tool calls alongside the browser events.

Here's a practical schema for an agent browser record:

{
  "session_id": "abc-123",
  "timestamp": "2026-08-27T10:00:00Z",
  "steps": [
    {
      "step": 1,
      "agent_prompt": "Find the pricing page and extract the monthly cost",
      "tool_call": "browser_navigate",
      "tool_input": { "url": "https://remote-browser.dev/pricing" },
      "tool_output": { "status": 200, "title": "Pricing - Remote Browser" },
      "dom_snapshot": "<html>...</html>",
      "screenshot_path": "s3://records/abc-123/step1.png",
      "network_requests": [
        { "url": "https://remote-browser.dev/pricing", "status": 200 }
      ],
      "latency_ms": 1200
    }
  ]
}

This structure lets you:

Replay the exact sequence of tool calls
Diff two runs to see where behavior diverged
Score whether the agent achieved the goal
Filter for failure patterns (e.g., repeated 404s, timeouts)

Keeping Sessions Alive Across Cloud Workers

One of the hardest problems in production browser automation is session persistence. If your agent runs on a serverless worker, the browser context dies when the function ends. The next invocation starts from scratch—losing cookies, local storage, and the navigation history.

The solution is a persistent browser profile. With Remote Browser, you create a profile once and attach it to any new session. The profile stores cookies, localStorage, and other state. This means your agent can pick up where it left off, even across different cloud workers.

Here's the pattern:

// Worker 1: Start the task
const session1 = await RemoteBrowser.create({
  profileId: 'user-42-profile',
});

// ... agent works, session ends

// Worker 2: Continue the task
const session2 = await RemoteBrowser.create({
  profileId: 'user-42-profile', // Same profile, new session
});

// session2 has the same cookies and state as session1

This is critical for long-running tasks like form submissions, multi-page checkouts, or any workflow that requires authentication.

Live Debugging: The Missing Piece

A record is useful after the fact, but you also need to see what the agent is doing right now. That's where a live viewer comes in. Remote Browser provides a live viewer that streams the browser viewport in real time. You can watch the agent navigate, click, and type—and intervene if it goes off track.

For debugging, combine the live viewer with the record:

Watch live to see the current state.
Pause the agent if it's stuck.
Inspect the record to see the exact sequence of events that led to the failure.
Replay the record in a fresh session to test a fix.

This workflow is far more efficient than reading logs or watching a video after the fact.

Comparison: Recording Approaches

Approach	Granularity	Replay	LLM-Friendly	Setup Effort
CDP raw events	High (network, console, DOM)	Manual	Yes (JSONL)	High
Playwright Trace	Medium (screenshots, DOM, network)	Built-in viewer	No (binary)	Low
Custom agent record	High (agent + browser)	Custom	Yes (JSON)	Medium
Video only	Low (visual)	Manual	No	Low

For production AI agents, we recommend a hybrid: use Playwright tracing for debugging, and a custom JSONL record for evaluation and replay.

Production Criteria for Agent Browser Recording

Before you adopt any recording approach, verify these criteria:

Storage: Where does the record live? Can you query it? S3-compatible object storage is a good default.
Retention: How long do you keep records? Define a policy based on compliance needs.
Privacy: If the agent handles PII, the record contains it. Encrypt at rest and in transit.
Cost: Recording every network request can be expensive. Sample or filter based on importance.
Determinism: Can you replay the record in a clean environment and get the same result? If not, your record is incomplete.

Getting Started with Remote Browser

Remote Browser is a hosted Chromium runtime designed for AI agents and browser automation. It gives you:

CDP access for low-level control
Playwright and Puppeteer compatibility via the standard APIs
Persistent profiles for session continuity
Live viewer for real-time debugging
Configurable browser settings for proxy and stealth-related needs

To start recording agent browser sessions in production, see the documentation for API details, or check the pricing page for current limits and rates.

If you're new to hosted browsers, read our guide on remote browsers for AI agents to understand the runtime layer. For a deeper dive into the practical setup, see remote web browser and remote control browser.

Conclusion

An agent browser record is not a nice-to-have; it's a requirement for any serious AI web automation workload. It enables debugging, evaluation, and compliance. The best approach combines CDP-level event capture with a structured agent log, stored centrally and replayable on demand.

Hosted Chromium makes this practical. You get persistent sessions, centralized records, and live debugging without managing browser infrastructure yourself. Start with Playwright tracing for quick wins, then build a custom JSONL record for evaluation. Your future self—and your agents—will thank you.

For the technical details on connecting via CDP, refer to the Chrome DevTools Protocol documentation. For Playwright-specific tracing, see the Playwright trace viewer docs.

Best Infra Setup for Running a Bunch of Browser Automations

RemoteBrowser — Mon, 31 Aug 2026 04:38:35 +0000

Best Infra Setup for Running a Bunch of Browser Automations

If you're running a bunch of browser automations in production—whether they're Playwright test suites, Selenium grids, or AI agents that need to click through the web—the infrastructure you choose determines everything: reliability, cost, and how much of your engineering time gets eaten by flaky sessions. The best infra setup for running a bunch of browser automations is not a local Chrome instance or a single EC2 box with a cron job. It's a hosted Chromium runtime that gives you isolated sessions, persistent profiles, and CDP access without forcing you to babysit the browser process.

This post walks through the concrete infrastructure decisions you need to make when scaling browser automation: where the browser runs, how sessions stay alive, how you connect to it, and what to watch out for when you move from a single script to a fleet of concurrent automations.

Why Local Browser Setup Breaks at Scale

The default approach—install Playwright or Selenium locally, write a script, run it—works fine for a handful of jobs. It falls apart when you need to run many automations concurrently or keep them running for hours.

Here's what happens when you try to scale a local setup:

Resource contention: Each Chromium instance eats 300–800 MB of RAM. Ten concurrent sessions on a single machine will exhaust memory and cause crashes.
Session loss: If your script dies, the browser dies with it. There's no way to reattach to a session that was running in a worker that got recycled.
IP blocking: Running many automations from the same IP address triggers bot detection on target sites. You need to manage IP diversity, which is painful to handle locally.
No live debugging: When a test fails at 2 AM, you want to see what the browser was looking at. Local setups don't give you a replayable session.

The solution is to treat the browser as a service: a hosted Chromium instance that you connect to over the network, rather than a process you spawn on your own machine.

The Core Components of a Production Browser Automation Stack

A production-grade setup for running many browser automations has five components:

Browser runtime: Hosted Chromium instances that are isolated from each other.
Connection layer: CDP (Chrome DevTools Protocol) or WebDriver endpoints that let your code attach to a running browser.
Session persistence: The ability to keep a browser session alive across multiple requests, workers, or even days.
Profile management: Persistent cookies, localStorage, and browser fingerprints that survive restarts.
Scaling and orchestration: The ability to spin up and tear down browsers on demand, without manual provisioning.

Let's look at each one in detail.

Browser Runtime: Hosted Chromium vs. Self-Managed

The first decision is where the browser actually runs. You have two options: manage your own browser fleet or use a hosted browser service.

Consideration	Self-Managed (EC2, Kubernetes)	Hosted Chromium (Remote Browser)
Setup time	Days to weeks: install, configure, secure	Minutes: API key, connect, run
Scaling	Manual or custom autoscaling logic	Automatic, on-demand sessions
Session persistence	Requires custom state management	Built-in persistent profiles
Live debugging	Requires VNC or custom tooling	Built-in live viewer
IP management	Manual integration	Configurable per-session
Maintenance	You own all Chromium updates and patches	Managed by the provider
Cost predictability	Variable, depends on idle capacity	Metered per browser-hour

Self-managed infrastructure gives you control, but it costs engineering time. Every Chromium update, every security patch, every flaky session that needs debugging is on you. Hosted Chromium removes that overhead, which is why it's the better choice when you're running a bunch of automations and want to focus on the automation logic, not the browser plumbing.

How to Connect: CDP, Playwright, and Selenium

Once the browser is hosted, you need a way to connect to it. The most flexible approach is CDP—the protocol that Chrome DevTools uses. CDP gives you low-level control over the browser: you can navigate, click, extract DOM, capture screenshots, and even emulate network conditions.

Playwright and Puppeteer both support connecting to an existing browser over CDP. Here's a TypeScript example using Playwright to connect to a hosted Chromium session:

import { chromium } from 'playwright';

// Connect to a hosted Chromium session via CDP
const browser = await chromium.connectOverCDP('wss://remote-browser.dev/cdp/v1/session_abc123');

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

// Navigate and interact
await page.goto('https://example.com');
await page.fill('#search', 'browser automation');
await page.click('button[type="submit"]');

// Wait for results
await page.waitForSelector('.results');
const results = await page.$$eval('.result-title', els => els.map(e => e.textContent));

console.log(results);

// The session stays alive even after this script exits
await browser.close();

The key difference from a local setup: connectOverCDP attaches to an already-running browser. If your script crashes, the browser session survives. You can reconnect from a different worker, inspect the current state, and continue where you left off.

For Selenium users, the equivalent is a WebDriver endpoint that points to a hosted browser. The connection string changes, but the pattern is the same: your test code talks to a remote browser, not a local one.

Keeping Browser Sessions Alive Across Cloud Workers

One of the hardest problems in browser automation is session persistence. In a typical cloud deployment, workers are ephemeral—they get created, do a job, and get destroyed. If your browser session lives inside a worker, it dies with the worker.

The fix is to decouple the browser session from the worker. The browser runs in a hosted environment, and your worker connects to it over CDP. This gives you three important capabilities:

Reconnection: If a worker dies, a new worker can connect to the same browser session and pick up where the old one left off.
Long-running tasks: A browser can stay open for hours or days, even if no worker is actively connected to it.
State preservation: Cookies, localStorage, and session data persist in the browser profile, so you don't lose login state between runs.

This is especially important for AI agents that need to maintain context across multiple steps. An agent that's booking a flight, filling out a form, or scraping a paginated site needs the browser to stay alive between LLM calls. With a hosted session, the agent can make a call, wait for the LLM response, then reconnect to the same browser and continue.

Persistent Profiles: The Key to Realistic Automation

When you run many browser automations, you'll quickly discover that sites treat fresh browser profiles with suspicion. A brand-new Chromium instance with no cookies, no history, and a datacenter IP looks like a bot.

Persistent profiles solve this. Instead of starting from scratch every time, you can:

Reuse login sessions: Store cookies and localStorage so you don't have to log in repeatedly.
Maintain consistent fingerprints: Keep the same user agent, screen resolution, and other browser attributes across sessions.
Isolate profiles per task: Use different profiles for different tasks, so a ban on one profile doesn't affect others.

Remote Browser supports persistent profiles that you can attach to any session. You create a profile once, and every session that uses that profile starts with the same state. This is a game-changer for scraping, testing authenticated flows, and running AI agents that need to maintain a consistent identity.

Configurable Browser Settings for Anti-Bot Resistance

When you're running a bunch of automations, you will hit bot detection. Sites use a combination of IP reputation, browser fingerprinting, and behavioral analysis to block automated traffic.

A hosted browser runtime should give you control over the settings that matter for anti-bot resistance:

IP configuration: Route traffic through residential or mobile IPs to avoid datacenter IP blocks.
Geolocation: Set a specific location for the browser, which is useful for testing geo-restricted content.
User agent and viewport: Customize these to match a real device profile.
WebRTC and timezone: Align these with your IP location to avoid mismatches that trigger detection.

The key word here is "configurable." You don't want a service that hardcodes stealth settings—you want the ability to tune the browser to match the specific site you're targeting. Remote Browser exposes these settings per session, so you can run different automations with different configurations without spinning up separate infrastructure.

Scaling Patterns for Concurrent Automations

Once you have a hosted browser runtime, the next question is how to scale. Here are three patterns that work well:

1. One Session Per Task

The simplest pattern: each automation task gets its own browser session. The task connects, does its work, and disconnects. The session can be terminated immediately or kept alive for a grace period.

This works well for test suites, where each test should run in isolation. It also works for scraping jobs that are independent of each other.

2. Shared Session with Sequential Tasks

For tasks that need to maintain state—like a multi-step checkout or a login-then-scrape workflow—you can share a single session across multiple workers. Worker A logs in, Worker B uses the authenticated session to scrape data, Worker C verifies the results.

This pattern reduces the number of browser instances you need, which lowers cost. It also avoids the overhead of repeated logins.

3. Session Pool with Dynamic Allocation

For high-throughput workloads, you can maintain a pool of pre-warmed sessions. Each session has a persistent profile and is ready to accept work. When a task comes in, you allocate it to an available session. When the task finishes, the session returns to the pool.

This is the most complex pattern, but it gives you the lowest latency and the highest throughput. It's the right choice when you're running hundreds or thousands of automations per hour.

What to Look for in a Browser Automation Infrastructure

When you're evaluating infrastructure for running a bunch of browser automations, here's a checklist:

CDP support: Can you connect with Playwright, Puppeteer, or raw CDP? This determines your flexibility.
Session persistence: Can you reconnect to a session after a worker crash? Can you keep a session alive for days?
Profile management: Can you create and reuse persistent profiles? Do profiles include cookies, localStorage, and browser settings?
Live debugging: Can you watch a session in real time? This is essential for debugging AI agents and complex workflows.
IP management: Can you route sessions through different IPs? This is critical for avoiding blocks.
Usage controls: Can you set limits on session duration, concurrent sessions, or spending? This prevents runaway costs.
API simplicity: Can you start a session with one API call? The simpler the API, the less code you have to maintain.

The Bottom Line

The best infra setup for running a bunch of browser automations is a hosted Chromium runtime that you connect to over CDP. It gives you session persistence, profile management, and scaling without the operational overhead of managing your own browser fleet.

If you're already using Playwright or Selenium, the migration path is straightforward: change your connection string from a local browser to a remote CDP endpoint. Your existing code works, but now it runs on infrastructure that's designed for production scale.

For AI agents, the hosted runtime is even more critical. Agents need to maintain context across LLM calls, and that requires a browser session that stays alive between requests. A hosted session gives you that persistence, plus the ability to inspect what the agent is doing in real time.

Start with a single session to validate the approach, then scale up as you gain confidence. The infrastructure is the boring part—get it right, and you can focus on the automations that actually create value.

Related reading: Remote Browser for AI Agents, Remote Browser Online, Remote Web Browser. For API details, see the documentation. For current pricing, see /pricing.

Agent Bowser: The Production Runtime for AI Web Automation

RemoteBrowser — Sun, 30 Aug 2026 03:59:57 +0000

Agent Bowser: The Production Runtime for AI Web Automation

If you've searched for "agent bowser" expecting a typo, you're not alone. The term is often used interchangeably with "agent browser"—the runtime layer that gives AI agents real, controllable access to the web. But there's a practical distinction worth making: an agent bowser isn't just a headless Chrome instance you spin up locally. It's a managed, hosted Chromium session that your AI agent can attach to, drive, and debug—without you managing browser infrastructure.

This guide explains what an agent bowser actually is, why local browser setups fail in production, and how to connect your AI agent to a hosted Chromium runtime using Playwright and CDP. You'll also see a concrete comparison of local vs. hosted browser runtimes, and a working TypeScript example you can adapt today.

What Is an Agent Bowser?

An agent bowser (or agent browser) is a browser session designed to be controlled programmatically by an AI agent or automation script. Unlike a standard browser you open manually, an agent bowser exposes a control surface—typically via the Chrome DevTools Protocol (CDP) or a high-level library like Playwright—so your code can navigate, click, type, extract data, and observe page state.

The term gained traction as AI agents moved from simple API calls to tasks that require reading web pages, filling forms, and interacting with dynamic content. A browser is the only universal interface to the web, and an agent bowser is the mechanism that makes that interface accessible to code.

Why "Bowser" and Not "Browser"?

The misspelling "bowser" appears frequently in search queries and internal notes. It's likely a typo that stuck. But it also highlights a common confusion: people searching for "agent bowser" often want to know how to give their AI agent browser access in production. They're not looking for a consumer product—they're looking for infrastructure.

That's the gap Remote Browser fills. It provides hosted Chromium sessions that your agent can connect to over CDP or WebSocket, with persistent profiles, proxy settings, and live debugging tools.

The Production Problem: Local Browsers Don't Scale

Running a browser locally for a quick script is fine. Running 50 concurrent sessions across multiple cloud workers is not. Here's why local setups break down:

Session persistence: Local browser sessions die when your worker restarts. If your agent is mid-task and the process crashes, you lose all state.
Resource contention: Each Chromium instance consumes significant CPU and memory. Running multiple on a single worker degrades performance.
Network restrictions: Local browsers use your machine's IP, which may be blocked by target sites or rate-limited.
Debugging: When an agent fails, you need to see what happened. Local sessions don't give you a replayable video or a live view.
Scaling: Adding workers means duplicating browser setup. You end up managing browser versions, dependencies, and cleanup logic.

An agent bowser runtime solves these by decoupling the browser from your compute. Your agent runs anywhere—a serverless function, a Kubernetes pod, a local dev machine—and connects to a hosted Chromium session over the network.

How to Give Your AI Agent Browser Access in Production

The standard pattern is to connect your agent to a remote browser using Playwright's connectOverCDP method. This gives you a live CDP connection to a hosted Chromium instance, which you control with the familiar Playwright API.

Here's a minimal TypeScript example:

import { chromium } from 'playwright';

// Connect to a hosted Chromium session via CDP
const browser = await chromium.connectOverCDP('wss://remote-browser.dev/cdp/your-session-id');

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

// Navigate and interact
await page.goto('https://example.com');
await page.fill('#search', 'agent bowser');
await page.click('button[type="submit"]');

// Wait for results and extract data
await page.waitForSelector('.result');
const results = await page.$$eval('.result', els => els.map(el => el.textContent));

console.log(results);

// Keep the session alive for other workers or close it
await browser.close();

This pattern works because connectOverCDP doesn't launch a browser—it attaches to an existing one. Your agent code becomes stateless and portable. If a worker dies, another can reconnect to the same session.

Playwright Remote vs. connectOverCDP

Playwright offers two ways to connect to a remote browser:

Method	Use Case	Pros	Cons
`playwright.connect()`	Connecting to a Playwright server	Full Playwright API, automatic protocol handling	Requires a Playwright server running
`playwright.connectOverCDP()`	Connecting to any CDP-compatible browser	Works with Chrome, Edge, and hosted runtimes	Lower-level, you manage contexts and pages manually

For an agent bowser, connectOverCDP is usually the right choice. It's the same protocol Chrome DevTools uses, so you can attach to a hosted Chromium instance without extra server software. The trade-off is that you need to handle contexts and pages yourself—but that's a small price for flexibility.

Note: Firefox support for connectOverCDP is limited. If you need Firefox, use playwright.connect() with a Playwright server or check the Playwright CDP docs for current compatibility.

Keeping Browser Sessions Alive Across Cloud Workers

One of the most common questions is how to keep a browser session alive when your worker scales to zero or restarts. The answer is to separate the browser from the worker.

With Remote Browser, each session is a hosted Chromium instance that persists independently of your compute. Your worker connects, does work, and disconnects. The session stays alive until you explicitly close it or it hits a timeout.

This enables patterns like:

Queue-based processing: A worker picks up a task, connects to a session, performs actions, and disconnects. The next worker can pick up where the last one left off.
Long-running agents: An agent that needs to monitor a page for hours can keep the session alive while the worker sleeps.
Collaborative debugging: Multiple developers can attach to the same session to see what the agent is doing in real time.

The key is to treat the browser session as a stateful resource, not a transient process. Your agent code should be written to reconnect and resume, not to assume a fresh browser every time.

What Is Agent Browser in Task Manager?

If you've seen "agent browser" in your task manager, it's likely a process from a browser automation tool or an AI agent framework. Some tools name their background processes "agent browser" or similar. It's not malware by default, but you should verify which application spawned it.

In the context of this guide, an agent bowser is a hosted service, so you won't see it in your local task manager. Instead, you'll see your agent's process (e.g., a Node.js or Python script) that connects to the remote browser.

Cloud-Based Browsercore: What It Means for Your Agent

"Browsercore" is a term used to describe the core browser engine that powers automation. In a cloud-based setup, the browsercore runs on a remote server, and your agent interacts with it via an API or protocol.

Remote Browser provides a cloud-based browsercore with these features:

Hosted Chromium: Each session runs a real Chromium instance, not a simulation or a headless shell.
CDP access: Full Chrome DevTools Protocol support, so you can use any CDP-compatible tool.
Playwright/Puppeteer/Selenium compatibility: Connect with the library you already use.
Persistent profiles: Save cookies, local storage, and session state between connections.
Proxy and stealth settings: Configurable browser settings to manage IP reputation and bot detection.
Live viewer: Watch your agent's browser in real time from a web dashboard.

This is different from a "browser as a service" that just renders pages. An agent bowser gives you a two-way control channel—your agent sends commands, the browser executes them, and you get back the results.

Comparison: Local Browser vs. Hosted Agent Bowser

Criterion	Local Browser	Hosted Agent Bowser (Remote Browser)
Session persistence	Lost on process exit	Survives worker restarts
Scaling	Limited by local resources	Scales horizontally with your compute
IP reputation	Your machine's IP	Configurable proxy settings
Debugging	DevTools on your machine	Live viewer, session recording
Setup time	Install browser, manage versions	API key, connect over CDP
Cost	Free (but hidden infra costs)	Metered per browser-hour
Concurrency	Limited by RAM/CPU	Managed by the runtime

The trade-off is clear: local browsers are fine for development, but production agents need a hosted runtime.

Production Criteria for an Agent Bowser

When evaluating an agent bowser runtime, look for these capabilities:

Reliable connections: The CDP endpoint should be stable and support reconnection.
Session isolation: Each agent should get its own browser context, not shared state.
Observability: You need to see what the agent is doing—live viewer, screenshots, or video.
Profile persistence: The ability to save and restore browser state is critical for multi-step tasks.
Proxy support: If your agent needs to access geo-restricted content or avoid rate limits, proxy configuration is essential.
Usage controls: Set limits on session duration, concurrency, and spending.

Remote Browser implements all of these. You can create a session, connect your agent, and monitor it from the dashboard. For current pricing and limits, check the pricing page.

Getting Started with Remote Browser

Here's a practical workflow to move from a local script to a hosted agent bowser:

Create a session: Use the Remote Browser API or dashboard to create a new browser session. You'll get a CDP endpoint URL.
Connect your agent: Use connectOverCDP in Playwright (or the equivalent in Puppeteer/Selenium) to attach to the session.
Run your task: Execute your automation logic. The browser runs in the cloud, so your local machine stays free.
Debug if needed: Open the live viewer to watch the agent in action. If something fails, you can see exactly what happened.
Close or persist: Close the session when done, or keep it alive for the next task.

For a deeper dive into the architecture, read our post on remote browsers for AI agents. If you're comparing options, our remote browser online guide covers the practical differences between local and hosted setups.

Common Pitfalls and How to Avoid Them

1. Assuming the Browser Is Stateless

An agent bowser is stateful. If you close the connection, the session may still be alive. Always explicitly close sessions you're done with to avoid leaking resources.

2. Ignoring Context Isolation

When you connect over CDP, you get access to all contexts in the browser. Make sure your agent creates a new context for each task to avoid cross-task contamination.

3. Not Handling Reconnections

Network issues happen. Your agent should be able to reconnect to the same session and resume from where it left off. Design your task logic to be idempotent where possible.

4. Overlooking Proxy Configuration

If your agent is scraping or accessing geo-restricted content, a proxy is often necessary. Remote Browser lets you configure proxy settings per session. See our remote web browser guide for details.

5. Forgetting About Debugging

When an agent fails, you need evidence. Use the live viewer and session recording features to capture what happened. This is invaluable for iterating on your agent's behavior.

The Bottom Line

An agent bowser is not a luxury—it's a requirement for production AI web automation. Local browsers can't handle the scale, persistence, and observability demands of real-world agents. By moving to a hosted Chromium runtime, you decouple your agent from your infrastructure and gain the reliability you need.

Remote Browser provides that runtime with CDP access, Playwright compatibility, persistent profiles, and live debugging. Whether you're building a web agent, a scraper, or a QA harness, the pattern is the same: connect your code to a hosted browser, run your task, and scale without managing browser infrastructure.

For implementation details, check the documentation. For pricing, see the pricing page. And if you're coming from a browser-use workflow, our remote control browser guide shows how to adapt your existing scripts.

Cloud Based Browsercore: The Hosted Chromium Runtime for AI Agents

RemoteBrowser — Sun, 30 Aug 2026 03:59:57 +0000

Cloud Based Browsercore: The Hosted Chromium Runtime for AI Agents

A cloud based browsercore is the missing runtime layer between your AI agent's code and the live web. Instead of launching a local Chrome instance that dies with your process, you connect to a hosted Chromium session that persists, scales, and exposes the same debugging protocols you already use. This post explains what a browsercore actually is, how to connect to one with Playwright or raw CDP, and why production AI agents need more than a local browser.

What Is a Cloud Based Browsercore?

A browsercore is the underlying browser engine—typically Chromium—that executes web pages, runs JavaScript, and renders DOM. When you move that core to the cloud, you get a browser that lives on remote infrastructure rather than on your laptop or a single worker.

Remote Browser provides exactly this: hosted Chromium sessions accessible via a simple API. You get a real browser process, not a simulation or a headless wrapper. The browser runs in a data center, and your code connects to it over the network.

This matters for AI agents because the browser is the agent's eyes and hands on the web. If the browser crashes, the agent fails. If the browser is blocked by anti-bot measures, the agent returns garbage. If the browser session resets between steps, the agent loses context.

A cloud based browsercore solves these problems by decoupling the browser lifecycle from your application lifecycle.

Why Local Browsers Fail in Production

Local browser automation works fine for a demo. You install Playwright, launch Chromium, navigate to a page, and extract data. But production AI agents run into three hard walls.

1. Session Death

When your Python script or Node.js process exits, the browser dies with it. If your agent runs on a serverless function or a short-lived container, the browser session is gone. Any cookies, localStorage, or logged-in state vanish.

2. Resource Contention

A full Chromium instance consumes a significant amount of RAM—often several hundred megabytes. Running multiple concurrent agents on one machine means either over-provisioning or crashing. You end up managing process pools, memory limits, and zombie browsers instead of writing agent logic.

3. Blocking and Fingerprinting

Data centers and cloud IPs are heavily flagged. Sites like Google, LinkedIn, and Amazon apply stricter checks to traffic from cloud providers. A local browser on a residential IP might pass, but a cloud-hosted browser on a datacenter IP often gets challenged or blocked.

How Remote Browser Solves the Browsercore Problem

Remote Browser's cloud based browsercore addresses all three issues directly.

Persistent sessions: The browser lives in the cloud, not in your process. Your agent connects, does work, disconnects, and reconnects later. The session state—cookies, profiles, local storage—persists between connections.

Isolation: Each session runs in its own container. One agent's crash doesn't take down another's browser. You can run many concurrent sessions without managing a single Chromium process locally.

Configurable browser settings: Remote Browser supports proxy configuration and other browser settings that help with site compatibility. You can route traffic through different IPs or configure the browser to match your use case.

Connecting to a Cloud Browsercore with Playwright

The most common way to connect to Remote Browser is through Playwright's connect_over_cdp method. CDP (Chrome DevTools Protocol) is the standard protocol for controlling Chromium, and Playwright speaks it natively.

Here's a minimal TypeScript example:

import { chromium } from 'playwright';

async function main() {
  // Connect to a Remote Browser session via CDP
  const browser = await chromium.connectOverCDP(
    'wss://remote-browser.dev/cdp/session-id-here'
  );

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

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

  // Do agent work...
  await page.click('button.submit');
  await page.waitForSelector('.result');

  // Don't close the browser — it stays alive in the cloud
  // await browser.close();
}

main().catch(console.error);

Notice what's missing: no chromium.launch(), no executable path, no --headless flag. The browser is already running in the cloud. You're attaching to it.

This is the core difference between local automation and a cloud based browsercore. You don't manage the browser process; you connect to it.

Playwright Remote vs. Raw CDP

Playwright's connect_over_cdp is the easiest entry point, but it's not the only option. You can also use raw CDP directly, or use Puppeteer's connect method.

Feature	Playwright connectOverCDP	Raw CDP (WebSocket)	Puppeteer connect
Protocol	CDP over WebSocket	CDP over WebSocket	CDP over WebSocket
API abstraction	High-level (selectors, auto-wait)	Low-level (DOM, Runtime, Network)	Medium-level
Session management	Automatic contexts/pages	Manual targets	Manual targets
Best for	AI agents, E2E tests	Custom tooling, debugging	Puppeteer codebases
Learning curve	Low	High	Medium
Browser support	Chromium (Firefox via CDP is limited)	Chromium	Chromium

For most AI agent workloads, Playwright's connectOverCDP is the right choice. It gives you high-level APIs for clicking, typing, and extracting data without managing raw protocol messages.

Raw CDP makes sense when you need fine-grained control—for example, intercepting network requests, modifying responses, or implementing custom automation logic that Playwright doesn't expose.

Keeping Sessions Alive Across Cloud Workers

One of the most common questions from AI agent developers is: "How do I keep a browser session alive across multiple workers?"

The answer is simple: don't put the browser in the worker. Put it in the cloud.

With Remote Browser, each session has a stable ID. Any worker—whether it's a serverless function, a container, or a long-running process—can connect to that session ID at any time.

Here's the pattern:

Create a session when the agent starts a task.
Store the session ID in your database or state store.
Connect from any worker using that session ID.
Disconnect when the worker finishes its chunk of work.
Reconnect from the next worker to continue where the last one left off.

This works because the browser process runs independently of your application code. It doesn't matter which worker connects, as long as it has the session ID and valid authentication.

Browser Automation for AI Agents: Selenium and Beyond

Playwright isn't the only option. Remote Browser also supports Selenium, which is useful if you're migrating an existing Selenium suite or working in a language where Selenium has better bindings.

The connection pattern is similar: you point your Selenium WebDriver at the remote browser's WebDriver endpoint instead of launching a local driver.

from selenium import webdriver
from selenium.webdriver.chrome.options import Options

options = Options()
options.add_argument("--remote-debugging-port=9222")
# Connect to Remote Browser's WebDriver endpoint
driver = webdriver.Remote(
    command_executor="https://remote-browser.dev/wd/hub",
    options=options
)

driver.get("https://example.com")
print(driver.title)
driver.quit()

The key insight is that the browser core is the same—Chromium—regardless of which automation library you use. The cloud based browsercore abstracts away the infrastructure, and your existing code works with minimal changes.

What About Firefox and WebKit?

Playwright supports three browser engines: Chromium, Firefox, and WebKit. Remote Browser currently focuses on Chromium, which is the right choice for most AI agent workloads.

Chromium has the best CDP support, the largest ecosystem of automation tools, and the most consistent rendering behavior. Firefox's CDP implementation is incomplete, and WebKit doesn't support CDP at all (it uses a different protocol).

If you need Firefox or WebKit, you're better off running those browsers locally or on your own infrastructure. For production AI agents, Chromium is the pragmatic default.

Production Criteria for a Cloud Browsercore

Not all cloud browser services are equal. Here's what to evaluate when choosing a cloud based browsercore for production:

Session Persistence

Can you disconnect and reconnect to the same session? Does the browser state (cookies, localStorage, profiles) survive across connections? This is non-negotiable for AI agents that work in steps.

Live Debugging

Can you watch the browser in real time? A live viewer is essential for debugging agent behavior. You need to see what the agent sees, not just read logs.

Proxy Support

Can you route traffic through different IPs? This is critical for sites that block datacenter IPs or for geo-specific testing.

Usage Controls

Can you set limits on session duration, concurrent sessions, or spending? Without usage controls, a runaway agent can burn through your budget in minutes.

API Compatibility

Does the service support Playwright, Puppeteer, and Selenium? Or are you locked into a proprietary API? Standard protocols mean you can switch providers without rewriting your code.

Remote Browser vs. Self-Hosted Chromium

You could run your own Chromium cluster. It's not impossible—it's just a lot of work.

Criterion	Self-Hosted Chromium	Remote Browser (Cloud Browsercore)
Setup time	Days to weeks	Minutes
Session persistence	You build it	Built-in
Live viewer	You build it	Built-in
Proxy management	You build it	Configurable
Scaling	Manual (K8s, Docker)	Automatic
Maintenance	Ongoing (updates, security)	Managed
Cost	High upfront, variable	Usage-based
Protocol support	Full control	CDP, Playwright, Selenium

Self-hosting gives you full control, but it also gives you full responsibility. You're on the hook for browser updates, security patches, capacity planning, and debugging infrastructure issues.

For most teams, the trade-off favors a managed cloud based browsercore. You pay for browser-hours and get back engineering time.

Use Cases for a Cloud Browsercore

AI Web Agents

The primary use case. Agents that browse the web, fill forms, extract data, and make decisions need a reliable browser runtime. A cloud based browsercore gives them persistent sessions and consistent behavior.

Browser Automation at Scale

Running many browser sessions for scraping, monitoring, or testing. A cloud browsercore handles the concurrency without you managing infrastructure.

QA and E2E Testing

Running Playwright or Selenium tests against a real browser in the cloud. Useful for CI/CD pipelines where you don't want to maintain browser binaries.

Remote Browser Control

When you need to control a browser from anywhere—a mobile app, a desktop tool, or a web dashboard. The browser runs in the cloud, and your client connects over the network.

Getting Started with Remote Browser

To start using Remote Browser's cloud based browsercore:

Create an account at remote-browser.dev.
Get your API key from the dashboard.
Create a session via the API or the dashboard.
Connect using Playwright, Puppeteer, or Selenium.
Build your agent on top of the persistent session.

The documentation covers the full API, including session management, proxy configuration, and live debugging.

For pricing details, check the pricing page for current rates and session limits.

External Resources

For a deeper dive into the Chrome DevTools Protocol, see the official CDP documentation. It's the protocol that makes cloud based browsercore connections possible.

The Bottom Line

A cloud based browsercore is the production runtime for AI web automation. It decouples the browser from your application, provides persistent sessions, and scales horizontally without you managing infrastructure.

Whether you're building an AI agent, running browser automation at scale, or migrating from local Playwright, Remote Browser gives you a hosted Chromium runtime that speaks the protocols you already know.

The browser is the hard part. Let the cloud handle it.

Playwright connect_over_cdp Firefox Supported Docs: A Practical Guide

RemoteBrowser — Sat, 29 Aug 2026 03:38:10 +0000

Playwright connect_over_cdp Firefox Supported Docs: A Practical Guide

If you've searched for playwright connect_over_cdp firefox supported docs, you're likely trying to connect Playwright to a remote Firefox instance over the Chrome DevTools Protocol (CDP). The short answer: yes, Playwright supports connect_over_cdp for Firefox, but the implementation has specific constraints, and production use requires more than a local browser process. This guide explains exactly how it works, where it breaks down, and how to run Firefox-based automation reliably in the cloud.

What connect_over_cdp Actually Does

Playwright's connect_over_cdp method attaches to an existing browser instance via CDP rather than launching a new one. This is useful when you need to control a browser that's already running—perhaps in a remote environment, a container, or a session managed by another tool.

For Chromium-based browsers, this works seamlessly. For Firefox, the story is more nuanced. Firefox supports CDP through its remote debugging protocol, but it's not a full implementation of the Chrome DevTools Protocol. Playwright's documentation notes that Firefox's CDP support is partial, and some operations behave differently compared to Chromium.

Here's a minimal TypeScript example that connects to a remote Firefox instance:

import { chromium } from 'playwright';

// Note: Playwright uses the 'chromium' export for CDP connections,
// even when connecting to Firefox over CDP.
async function connectToFirefox() {
  const browser = await chromium.connectOverCDP(
    'http://localhost:9222'
  );

  const context = browser.contexts()[0];
  const page = context.pages()[0];

  await page.goto('https://example.com');
  console.log(await page.title());

  await browser.close();
}

connectToFirefox().catch(console.error);

The key takeaway: you use the chromium API surface because CDP is a Chromium-originated protocol. Firefox implements a subset of it, so you're effectively speaking CDP to a Firefox process.

Firefox CDP Support: What's Documented and What's Not

The Playwright docs are clear about Firefox CDP limitations. According to the official Playwright documentation, Firefox's CDP support is experimental and incomplete. Some features that work in Chromium over CDP—like certain network interception methods, performance metrics, and specific DOM APIs—may not behave identically in Firefox.

What works reliably in Firefox over CDP:

Basic navigation and page loading
DOM querying and manipulation
Clicking, typing, and form submission
Screenshot and PDF generation
Basic network request observation

What's less reliable or unsupported:

Full network interception with request/response modification
Some emulation features (device metrics, geolocation)
Performance timeline APIs
Certain CDP domains that Firefox hasn't implemented

This matters for production automation. If your workflow depends on network mocking or advanced emulation, Firefox over CDP may not be the right choice. If you need basic browser automation with Firefox's rendering engine, it can work.

Why Local Firefox CDP Fails in Production

Connecting to a local Firefox instance via CDP works fine for development. But production browser automation has different requirements:

Session persistence. A local Firefox process dies when your machine restarts, when the process crashes, or when your CI runner is recycled. For AI agents that need to maintain state across multiple steps or retries, this is a non-starter.

Concurrency. Running multiple Firefox instances locally means managing multiple processes, ports, and profiles. This gets messy quickly, especially if you're orchestrating dozens of parallel tasks.

Infrastructure overhead. You need to install Firefox, configure the remote debugging port, manage the process lifecycle, and handle crashes. That's a lot of moving parts for what should be a simple API call.

Network and IP considerations. If your automation needs to appear as a real user from a specific geographic location or avoid bot detection, a local browser on a datacenter IP is a liability.

The Production Alternative: Hosted Firefox via CDP

Remote Browser provides hosted Chromium sessions with CDP access, and the same infrastructure supports Firefox-based automation workflows. Instead of managing a local Firefox process, you connect to a remote browser session over CDP—the same way you'd connect to a local one, but without the infrastructure burden.

Here's how the architecture changes:

Aspect	Local Firefox + CDP	Hosted Browser + CDP
Session persistence	Dies with the process	Persistent across connections
Concurrency	Manual process management	Managed by the platform
Infrastructure	You install and maintain Firefox	Zero setup, API-only
IP quality	Datacenter IP	Configurable proxy settings
Live debugging	Local only	Web-based live viewer
Scaling	Limited by local resources	Horizontal scaling

The connection code is nearly identical. You're still using connect_over_cdp, but the endpoint points to a hosted session rather than localhost.

Keeping Browser Sessions Alive Across Cloud Workers

One of the most common questions we hear: "How do I keep browser sessions alive across multiple cloud workers?" This is a real problem when you're using serverless functions or ephemeral compute.

The issue is that a browser session is stateful. If worker A opens a page, logs in, and then worker B tries to continue that session, worker B needs access to the same browser context. With local browsers, this is impossible—each worker has its own isolated environment.

With hosted browsers, the session lives in the cloud, not on your worker. Any worker can connect to the same session via CDP, pick up where the previous worker left off, and continue the task. This is how you build multi-step AI agents that survive infrastructure failures and scale horizontally.

The pattern looks like this:

Worker A connects to a hosted browser session via CDP
Worker A performs steps 1-3 of a task, then exits
Worker B connects to the same session via CDP
Worker B sees the state left by Worker A and continues

This is the foundation for reliable AI web agents. The browser is the persistent state layer; your workers are stateless compute that attach and detach as needed.

How to Give Your AI Agent Browser Access in Production

If you're building an AI agent that needs to browse the web, you have a few options:

Option 1: Local browser automation. Install Playwright or Puppeteer on your agent's machine, launch a browser, and control it directly. This works for prototypes but fails in production due to the infrastructure and persistence issues discussed above.

Option 2: Browser-use style frameworks. Tools like browser-use provide a higher-level interface for AI agents. They handle the browser control logic, but you still need a browser runtime underneath.

Option 3: Hosted browser runtime. Connect your agent to a hosted browser via CDP. Your agent gets a real browser session with persistent state, configurable proxy settings, and live debugging—without managing any infrastructure.

The third option is what Remote Browser provides. Your AI agent connects to a hosted session, performs its tasks, and disconnects. The session persists, so the agent can reconnect later or a different agent can continue the work.

Practical Considerations for Firefox over CDP

If you're committed to Firefox over CDP, here are the production criteria to evaluate:

Session isolation. Can you isolate sessions so different tasks don't interfere with each other? With hosted browsers, each session is isolated by default.

Proxy and IP configuration. Can you route traffic through specific proxies or IPs? This is critical for tasks that need to appear from specific locations or avoid rate limiting.

Live debugging. Can you watch what the browser is doing in real time? A live viewer is invaluable for debugging AI agent behavior.

Usage controls. Can you set limits on session duration, concurrent sessions, or spending? This prevents runaway costs from misbehaving agents.

API stability. Does the CDP endpoint remain stable across reconnects? Your agent should be able to disconnect and reconnect without losing state.

When to Use Firefox vs. Chromium

Firefox over CDP is a niche use case. Most automation workloads are better served by Chromium, which has full CDP support and broader compatibility with automation libraries. But there are legitimate reasons to use Firefox:

Testing Firefox-specific behavior. If your product needs to work in Firefox, you need to test in Firefox.
Rendering differences. Firefox's rendering engine differs from Chromium, and some sites behave differently.
Privacy preferences. Some users prefer Firefox for privacy reasons, and your automation may need to match that.

For everything else, Chromium is the safer choice. It has complete CDP support, better Playwright integration, and a larger ecosystem of tools and libraries.

Getting Started with Hosted Browser Sessions

To connect to a hosted browser session via CDP, you'll need an API endpoint and authentication. The Remote Browser API provides this out of the box. You create a session, get a CDP endpoint, and connect with Playwright or any other CDP-compatible client.

The workflow is straightforward:

Create a browser session via the API
Retrieve the CDP endpoint URL
Connect using connect_over_cdp or your preferred client
Run your automation
Disconnect when done (the session persists)

For detailed setup instructions, see the Remote Browser documentation. For pricing details, check the pricing page.

The Bottom Line

Playwright's connect_over_cdp for Firefox is supported, but it's not a drop-in replacement for Chromium. The protocol support is partial, and production use requires infrastructure that local browsers can't provide.

For reliable browser automation—whether you're running tests, powering AI agents, or scraping data—a hosted browser runtime solves the persistence, concurrency, and infrastructure problems that plague local setups. The connection code is the same; the difference is where the browser runs.

If you're building AI agents that need browser access, start with a hosted runtime. Your agents will be more reliable, your infrastructure simpler, and your debugging easier. For more on how hosted browsers fit into AI agent workflows, read about remote browsers for AI agents or explore remote browser online for a practical overview.

For the authoritative reference on CDP, see the Chrome DevTools Protocol documentation. For Playwright-specific details, the Playwright CDP documentation is the canonical source.

Playwright Connect: How to Connect to Remote Browsers

RemoteBrowser — Sat, 29 Aug 2026 03:38:09 +0000

Playwright Connect: How to Connect to Remote Browsers

If you've searched for "playwright connect," you're likely trying to attach a Playwright script to a browser that isn't running on your local machine. This is a common requirement for AI agents, distributed test suites, and production automation. The core challenge is that Playwright's default chromium.launch() starts a browser process locally. To connect to a remote browser, you need a different approach—one that uses the Chrome DevTools Protocol (CDP) or Playwright's built-in remote connection methods.

This guide explains how Playwright connect works, the trade-offs between connectOverCDP and connect, and why a hosted browser runtime simplifies production deployments. We'll cover concrete code examples, session persistence, and the operational details that matter when you move from local scripts to cloud infrastructure.

What Does "Playwright Connect" Mean?

Playwright provides two primary methods for connecting to browsers that are not launched by your script:

playwright.chromium.connectOverCDP(endpoint): Connects to an existing browser instance via its CDP endpoint. This is the most flexible method because it works with any browser that exposes CDP, including Chrome, Edge, and hosted browser services.
playwright.chromium.connect(wsEndpoint): Connects to a browser that was launched with --remote-debugging-pipe or exposes a WebSocket endpoint. This is less common but useful for specific setups.

The key difference is that connectOverCDP treats the browser as a server, while connect treats it as a WebSocket client. For most remote browser scenarios, connectOverCDP is the right choice because it aligns with how hosted browser services expose their sessions.

Why Connect to a Remote Browser?

Local browser automation works fine for development. But production workloads—especially AI agents that need to run 24/7—require a different architecture. Here's why:

Session persistence: A local browser dies when your script exits or your machine sleeps. A remote browser can stay alive across multiple workers, API calls, or agent steps.
Scalability: You can't spin up 50 local Chrome instances on a laptop. Hosted browsers scale horizontally.
Network conditions: Remote browsers run in data centers with stable IPs and bandwidth. This matters for sites that throttle or block traffic from residential IPs.
Resource isolation: Your automation doesn't compete with local memory or CPU for other tasks.

The trade-off is latency. Every CDP command travels over the network, so round-trip times are higher than local execution. For most automation tasks, this is negligible. For high-frequency interactions, it can add up.

Playwright Connect Over CDP: The Code

Here's a minimal TypeScript example that connects to a remote browser via CDP:

import { chromium } from 'playwright';

async function main() {
  // Replace with your remote browser's CDP endpoint
  const cdpUrl = 'wss://remote-browser.dev/cdp/your-session-id';

  // Connect to the existing browser
  const browser = await chromium.connectOverCDP(cdpUrl);

  // Get the default context or create a new one
  const context = browser.contexts()[0] || await browser.newContext();

  // Create a page and navigate
  const page = await context.newPage();
  await page.goto('https://example.com');

  // Interact with the page
  const title = await page.title();
  console.log(`Page title: ${title}`);

  // Don't close the browser if you want to keep the session alive
  // await browser.close();
}

main().catch(console.error);

The critical detail is that connectOverCDP does not launch a browser. It attaches to an existing one. This means the browser session can outlive your script. If you close the browser, you lose the session. If you don't, the session remains available for the next worker.

Keeping Browser Sessions Alive Across Cloud Workers

One of the most common questions we see is: How do I keep browser sessions alive across multiple cloud workers? This is a real problem when you have a queue of tasks that need to share the same authenticated session or browser state.

With a hosted browser runtime, the answer is straightforward: the browser lives in the cloud, not in your worker. Your worker connects via CDP, performs its task, and disconnects. The browser stays alive. The next worker connects to the same session and continues where the previous one left off.

Here's how this works in practice:

Create a session: Your first worker requests a new browser session from the remote browser API.
Connect via CDP: The worker uses connectOverCDP to attach to the session.
Perform work: The worker navigates, fills forms, extracts data, etc.
Disconnect: The worker closes its connection but leaves the browser running.
Reconnect: The next worker connects to the same session ID and continues.

This pattern is essential for AI agents that need to maintain context across multiple steps or for long-running workflows that span multiple function invocations.

Playwright Connect vs. Selenium: What's the Difference?

Selenium has a similar concept with its Remote WebDriver. The key differences are architectural:

Feature	Playwright Connect	Selenium Remote WebDriver
Protocol	CDP (Chrome DevTools Protocol)	W3C WebDriver
Browser support	Chromium, Firefox, WebKit	Chrome, Firefox, Safari, Edge
Performance	Faster, lower overhead	Slower, more verbose
Session control	Fine-grained via CDP	Coarse-grained via WebDriver
Debugging	Rich CDP tools	Limited to WebDriver commands
Cloud compatibility	Works with any CDP endpoint	Requires a Selenium Grid or cloud provider

For AI agents and modern automation, Playwright's CDP-based approach is generally preferred because it gives you direct access to browser internals—network interception, performance metrics, and DOM manipulation—without the WebDriver abstraction layer.

Firefox Support for connectOverCDP

A common question is whether connectOverCDP works with Firefox. The short answer is: it's complicated.

Playwright's connectOverCDP is designed for Chromium-based browsers. Firefox uses a different debugging protocol (Remote Protocol), which is not fully compatible with CDP. While Playwright can launch Firefox locally, connecting to a remote Firefox instance via CDP is not officially supported.

If you need Firefox support, your options are:

Use Playwright's firefox.launch() for local execution.
Use a hosted browser service that exposes Firefox via a compatible protocol.
Stick with Chromium for remote connections.

For production automation, Chromium is the safest choice because it has the most mature CDP implementation and the broadest ecosystem support.

What Is an Agent Browser?

You may have seen the term "agent browser" in task manager or in the context of AI automation. An agent browser is simply a browser instance that is controlled by an AI agent rather than a human. The agent uses the browser to navigate websites, extract information, and perform actions—just like a human would, but programmatically.

The term has gained traction because AI agents need a dedicated browser runtime that supports:

Session persistence: The agent can pause and resume work without losing state.
Remote access: The agent runs in the cloud, not on a local machine.
Observability: Developers can watch the agent's actions in real time via a live viewer.
Isolation: Each agent gets its own browser profile, preventing cross-contamination.

This is where hosted browser runtimes come in. They provide the infrastructure that makes agent browsers practical for production use.

How to Give Your AI Agent Browser Access in Production

If you're building an AI agent that needs to browse the web, you have three main options:

Run a local browser: Simple but limited. The agent dies with the process.
Use a headless browser library: Puppeteer or Playwright locally. Still tied to your infrastructure.
Use a hosted browser runtime: The agent connects to a remote browser via CDP. This is the production-grade approach.

The third option is what we recommend for anything beyond a prototype. Here's why:

Reliability: Hosted browsers are monitored and restarted if they crash.
Scalability: You can spin up dozens of sessions without provisioning hardware.
Security: Browser sessions are isolated from your application code.
Compliance: You can control which sites the agent visits and what data it can access.

Playwright Remote: The Production Checklist

When you move from local Playwright to a remote browser setup, use this checklist:

Use connectOverCDP: It's the most compatible method for remote browsers.
Handle disconnects gracefully: Your code should reconnect if the CDP connection drops.
Persist session state: Use cookies, localStorage, or profiles to maintain state across connections.
Set timeouts: Network latency means you need longer timeouts for navigation and waits.
Monitor resource usage: Remote browsers consume memory and CPU. Track usage to avoid runaway sessions.
Implement retry logic: Transient network errors are inevitable. Build retries into your automation.

The Remote Browser Approach

Remote Browser provides a hosted Chromium runtime that works with Playwright's connectOverCDP. Instead of managing your own browser infrastructure, you get:

CDP endpoints: Each session exposes a WebSocket URL that Playwright can connect to.
Persistent profiles: Sessions can be configured to persist cookies, localStorage, and other state.
Live viewer: Watch your agent's actions in real time from a web dashboard.
Configurable browser settings: Adjust proxy settings, user agents, and other parameters to match your use case.
Session isolation: Each session runs in its own container, preventing cross-session interference.

The workflow is simple:

Create a session via the API or dashboard.
Connect with connectOverCDP.
Run your automation.
Disconnect and keep the session alive for later use.

This approach eliminates the operational overhead of running your own browser fleet. You don't need to worry about Chrome versions, system dependencies, or memory leaks. The runtime handles that for you.

Comparing Hosted Browser Runtimes

Not all hosted browser services are the same. Here's a comparison of what to look for:

Feature	Remote Browser	Self-Hosted	BrowserStack/Sauce Labs
CDP support	Native	Manual setup	Limited
Session persistence	Built-in	Requires custom code	Limited
Live debugging	Included	Requires VNC	Included
Pricing model	Per browser-hour	Infrastructure costs	Per-minute
AI agent focus	Yes	No	No
API simplicity	REST + WebSocket	Complex	Complex

For AI agent workloads, a service that natively supports CDP and session persistence is a significant advantage. You can focus on your agent's logic instead of browser infrastructure.

Playwright Connect: Common Pitfalls

Even with a hosted runtime, you'll encounter issues. Here are the most common ones and how to solve them:

1. Connection Timeouts

Problem: connectOverCDP hangs or times out.

Solution: Check that the CDP endpoint is reachable from your network. If you're behind a firewall, you may need to allow WebSocket connections. Also, ensure the session is still active—hosted browsers may shut down after inactivity.

2. Session State Loss

Problem: Cookies or localStorage disappear between connections.

Solution: Use a persistent profile. In Remote Browser, you can configure sessions to save state. Alternatively, manually save and restore cookies in your code.

3. Browser Crashes

Problem: The remote browser crashes mid-task.

Solution: Implement retry logic. If the CDP connection drops, reconnect and resume from the last known state. For critical tasks, use session recording to replay what happened.

4. Performance Degradation

Problem: Interactions feel slow.

Solution: Optimize your selectors and avoid unnecessary waits. Use Playwright's built-in auto-waiting features. If latency is a concern, consider a hosted runtime in the same region as your application.

The Future of Browser Automation

Browser automation is moving from test tooling to production infrastructure. AI agents need reliable, scalable browser access, and that requires a runtime designed for automation—not a desktop browser repurposed for scripts.

Playwright connect is the bridge between your code and the browser. Whether you're running a single test or a fleet of AI agents, understanding how to connect to remote browsers is essential.

If you're ready to move beyond local automation, Remote Browser provides the hosted Chromium runtime you need. Start with a free session and see how easy it is to connect Playwright to a cloud browser.

Next Steps

Read our guide on remote browser sessions for a deeper dive into session management.
Explore the Remote Browser API for programmatic session creation.
Learn about remote web browser architectures for production workloads.

The Playwright connect pattern is straightforward once you understand the underlying protocol. With a hosted runtime, you get the benefits of remote browsers without the operational burden. Your agents can browse the web reliably, at scale, without you managing a single Chrome instance.

Browser Agent: The Production Runtime for AI Web Automation

RemoteBrowser — Fri, 28 Aug 2026 05:02:32 +0000

Browser Agent: The Production Runtime for AI Web Automation

A browser agent is only as reliable as the browser runtime it drives. When your AI agent needs to navigate the web, fill forms, extract data, or interact with dynamic JavaScript-heavy pages, the underlying browser infrastructure determines whether your task succeeds or fails silently. This post explains what production-grade browser agent infrastructure looks like, why hosted Chromium beats local browser setups, and how to connect your agent to a remote browser using CDP and Playwright.

The Browser Agent Problem: Local Browsers Don't Scale

Most AI agent frameworks start with a local browser instance. You install Playwright or Puppeteer, launch Chromium on your machine, and your agent begins clicking around. This works for demos. It breaks in production.

Here's what happens when you run a browser agent locally:

Session loss: Cloud workers are ephemeral. When a worker restarts, your browser session disappears. The agent loses cookies, localStorage, and login state.
Resource contention: Each Chromium instance consumes 300-500MB of RAM. Running multiple agents on one machine causes memory pressure and crashes.
Network restrictions: Local browsers use your machine's IP. If you're behind a corporate firewall or geo-restricted network, your agent can't reach the sites it needs.
No isolation: A single misbehaving script can corrupt the browser profile, affecting all subsequent agent runs.

The solution is a hosted browser runtime designed specifically for AI agents. Remote Browser provides exactly that: cloud-hosted Chromium sessions accessible via API, with persistent profiles, live debugging, and CDP compatibility.

What Makes a Browser Agent Runtime Production-Ready?

Before evaluating any browser agent infrastructure, check these five criteria:

Criterion	Local Browser	Hosted Runtime (Remote Browser)
Session persistence	Lost on restart	Persistent profiles across sessions
Concurrency	Limited by local RAM	Isolated sessions per agent
Network flexibility	Tied to local IP	Configurable proxy settings
Debugging	DevTools on localhost	Live viewer and CDP access
Scaling	Manual setup per machine	API-driven provisioning

1. Session Persistence

Your browser agent often needs to maintain state across multiple steps. A login flow, for instance, requires the session cookie to persist from the authentication step to the data extraction step.

Remote Browser keeps sessions alive across cloud workers. You create a browser session, run your agent, and when the worker restarts, you reconnect to the same session. The profile—cookies, localStorage, IndexedDB—remains intact.

2. CDP Compatibility

The Chrome DevTools Protocol (CDP) is the foundation of modern browser automation. It's what Playwright and Puppeteer use under the hood to control Chromium.

Remote Browser exposes CDP endpoints for every session. This means you can:

Attach any CDP-compatible client to a running session
Use Playwright's connectOverCDP method
Send raw CDP commands for fine-grained control
Capture network traffic, console logs, and performance metrics

3. Live Debugging

When your browser agent fails, you need to see what happened. Remote Browser provides a live viewer that streams the browser viewport in real time. You can watch your agent navigate, identify where it gets stuck, and intervene if necessary.

This is critical for debugging complex workflows. A text-based log tells you the agent clicked a button. The live viewer shows you whether the click actually registered.

4. Persistent Profiles

Different agents need different browser contexts. A shopping agent needs a profile with payment information. A scraping agent needs a clean profile with no tracking cookies. A testing agent needs a fresh profile for every run.

Remote Browser supports persistent profiles that you can create, save, and reuse. Each profile is isolated from others, preventing cross-contamination between agents.

5. Configurable Network Settings

Some sites block traffic from data center IPs. Others require a specific geographic location. Remote Browser lets you configure proxy settings per session, so your agent can appear to come from the right place.

Connecting Your Browser Agent to Remote Browser

Let's walk through a concrete implementation. You'll connect a Playwright-based agent to a hosted Chromium session using CDP.

First, create a browser session via the Remote Browser API:

import { RemoteBrowser } from '@remote-browser/sdk';

const client = new RemoteBrowser({
  apiKey: process.env.REMOTE_BROWSER_API_KEY,
});

// Create a new browser session
const session = await client.sessions.create({
  profileId: 'shopping-agent-profile',
  proxy: {
    country: 'US',
  },
});

console.log(`Session ID: ${session.id}`);
console.log(`CDP Endpoint: ${session.cdpEndpoint}`);

Now connect Playwright to that session:

import { chromium } from 'playwright';

// Connect to the remote browser via CDP
const browser = await chromium.connectOverCDP(session.cdpEndpoint);
const context = browser.contexts()[0];
const page = await context.newPage();

// Your agent logic here
await page.goto('https://example.com/login');
await page.fill('#username', 'agent-user');
await page.fill('#password', process.env.AGENT_PASSWORD);
await page.click('#submit');

// Wait for navigation and extract data
await page.waitForSelector('.dashboard');
const data = await page.evaluate(() => {
  return document.querySelector('.dashboard').textContent;
});

console.log('Extracted:', data);

// Don't close the browser - keep the session alive for the next step
// await browser.close();

The key difference from local Playwright: you don't launch a browser. You connect to an existing one. This means:

The session survives worker restarts
Multiple agents can share the same session (with proper coordination)
You can debug the session live while the agent runs

Browser Agent vs. Traditional Browser Automation

Browser agents differ from traditional automation scripts in one fundamental way: they make decisions at runtime. A Selenium test follows a predefined script. A browser agent observes the page, decides what to do next, and executes.

This difference has infrastructure implications:

Aspect	Traditional Automation	Browser Agent
Decision point	Compile time	Runtime
Session length	Minutes	Hours to days
Error recovery	Scripted retries	Adaptive behavior
Resource usage	Predictable	Variable
Debugging	Step-by-step replay	Live observation

Because browser agents run longer and adapt dynamically, they need a runtime that supports long-lived sessions, live debugging, and graceful recovery from failures.

Common Browser Agent Failure Modes

Understanding why browser agents fail helps you choose the right infrastructure. Here are the most common failure modes we see:

1. Session Timeout

Many sites expire sessions after a period of inactivity. If your agent takes too long between actions, the session dies. Remote Browser keeps the underlying Chromium session alive, so the browser itself doesn't time out. The site's session may still expire, but you can detect and handle that programmatically.

2. Element Not Found

Dynamic pages load content asynchronously. Your agent looks for an element that hasn't rendered yet. The fix is proper waiting strategies:

// Bad: immediate lookup
const button = await page.locator('#submit').click();

// Good: wait for the element to be actionable
await page.locator('#submit').waitFor({ state: 'visible' });
await page.locator('#submit').click();

3. Pop-ups and Modals

Unexpected dialogs can block your agent's progress. A production runtime should let you handle these gracefully:

page.on('dialog', async (dialog) => {
  console.log(`Dialog message: ${dialog.message()}`);
  await dialog.accept();
});

4. Network Flakiness

Requests fail, connections drop, servers return 500 errors. Your agent needs retry logic:

async function retryNavigation(page, url, maxRetries = 3) {
  for (let attempt = 1; attempt <= maxRetries; attempt++) {
    try {
      await page.goto(url, { waitUntil: 'networkidle' });
      return;
    } catch (error) {
      console.log(`Attempt ${attempt} failed: ${error.message}`);
      if (attempt === maxRetries) throw error;
      await page.waitForTimeout(2000 * attempt);
    }
  }
}

Browser Agent Benchmarks: What to Measure

When evaluating browser agent infrastructure, don't rely on marketing claims. Measure these metrics yourself:

Task completion rate: What percentage of agent tasks complete successfully?
Time per task: How long does the average task take?
Session stability: How often does the browser session crash or become unresponsive?
Resource efficiency: How much memory and CPU does each session consume?
Network reliability: What's the error rate for page loads and API calls?

Remote Browser provides usage controls that let you monitor these metrics. You can set limits on session duration, concurrent sessions, and data transfer to keep costs predictable.

Browser Agent Security Considerations

Giving an AI agent browser access introduces security risks. Here's how to mitigate them:

1. Credential Management

Never hardcode credentials in your agent code. Use environment variables or a secrets manager:

const credentials = {
  username: process.env.AGENT_USERNAME,
  password: process.env.AGENT_PASSWORD,
};

2. Session Isolation

Each agent should run in its own browser session. This prevents one agent's actions from affecting another's state. Remote Browser provides session isolation by default.

3. Network Restrictions

Limit which domains your agent can access. You can configure this at the proxy level or implement domain allowlisting in your agent logic:

const allowedDomains = ['example.com', 'api.example.com'];

page.on('request', (request) => {
  const url = new URL(request.url());
  if (!allowedDomains.includes(url.hostname)) {
    request.abort();
  }
});

4. Audit Logging

Track what your agent does. Remote Browser records session activity, and you can export logs for analysis.

When Not to Use a Browser Agent

Browser agents aren't the right tool for every web automation task. Consider alternatives:

APIs: If the site offers a REST API, use it instead of browser automation. It's faster, more reliable, and less likely to break.
Static scraping: For simple data extraction, use HTTP requests with a library like axios or fetch.
Headless browsers without AI: If your workflow is deterministic, a traditional Playwright script is simpler and cheaper.

Browser agents shine when the task requires understanding page context, making decisions, and adapting to unexpected page states. If your task is a fixed sequence of steps, you don't need an agent.

Getting Started with Remote Browser

To start building your browser agent on Remote Browser:

Create an account and get your API key
Create a browser session via the API or dashboard
Connect your agent using Playwright, Puppeteer, or raw CDP
Monitor and debug using the live viewer and session logs

The documentation covers the full API surface, including session management, profile configuration, and proxy settings. For pricing details, see the pricing page.

If you're new to hosted browsers, start with our guide on remote browsers for AI agents. For a deeper dive into the runtime architecture, read about remote web browsers and remote control browser capabilities.

Conclusion

A browser agent is only as good as its runtime. Local browsers fail in production due to session loss, resource constraints, and network limitations. Hosted Chromium runtimes like Remote Browser solve these problems with persistent sessions, CDP compatibility, live debugging, and configurable network settings.

The shift from local to hosted browser infrastructure is similar to the shift from on-premise servers to cloud computing. It's not about where the browser runs—it's about the operational capabilities that hosting enables. Session persistence, isolation, scaling, and observability are the features that make browser agents production-ready.

Start small: connect a single agent to a hosted session, measure task completion rates, and compare against your local setup. The infrastructure differences become obvious within the first hour of real usage.

For the technical details on CDP integration, refer to the Chrome DevTools Protocol documentation. It's the foundation that makes all of this work.

Browser-As-A-Service vs Self-Hosted Playwright Infra

RemoteBrowser — Fri, 28 Aug 2026 05:02:32 +0000

Browser-As-A-Service vs Self-Hosted Playwright Infra

When your automation workload moves past a handful of scripts, the infrastructure decision becomes unavoidable: browser-as-a-service vs self-hosted Playwright infra. The choice affects your latency, your operational overhead, and how reliably your AI agents can complete tasks. This guide breaks down the real trade-offs so you can pick the right runtime for your production workloads.

Why This Decision Matters Now

Browser automation has shifted from CI/CD test suites to AI agents that browse, extract, and act on the web. These agents have different infrastructure requirements than a nightly test run. They need persistent sessions, live debugging, and the ability to survive network blips without losing state.

Self-hosting Playwright gives you control. Browser-as-a-service (BaaS) gives you managed infrastructure. Neither is universally better—the right answer depends on your team size, traffic patterns, and tolerance for operational work.

What Self-Hosted Playwright Actually Costs

The obvious cost of self-hosting is compute. Each Chromium instance consumes roughly 300–500 MB of RAM. If you run 50 concurrent sessions, that's 15–25 GB of RAM just for browsers, before your application code.

But the hidden costs are bigger:

Session management: Keeping browser sessions alive across multiple cloud workers requires a shared state layer. You'll build or integrate a session store, handle reconnection logic, and manage cleanup.
Scaling infrastructure: Auto-scaling groups, load balancers, and queue systems for browser requests. Each component needs monitoring and alerting.
Network and IP reputation: Residential or clean IPs for sites that block datacenter traffic. This is a rabbit hole of proxy management and IP rotation.
Debugging tooling: Live viewing, session recording, and step-by-step replay are non-trivial to build. Most teams end up with console.log statements and screenshots.
Maintenance: Chromium updates, Playwright version bumps, and security patches. Every update risks breaking your automation.

For a small team, this is a full-time infrastructure engineer's job. For a larger team, it's a dedicated platform group.

What Browser-As-A-Service Provides

A browser-as-a-service platform like Remote Browser abstracts the infrastructure layer. You get hosted Chromium sessions accessible via CDP, Playwright, or Puppeteer. The platform handles session persistence, scaling, and network configuration.

The practical benefits:

Instant scale: Spin up 100 sessions without provisioning anything.
Persistent sessions: Browser state survives across cloud workers and API calls.
Live debugging: Watch sessions in real time via a live viewer.
Managed profiles: Persistent profiles for logged-in states, cookies, and local storage.
Configurable browser settings: Proxy settings, viewport, user agent, and other stealth-related options.

The trade-off is less control over the underlying infrastructure. You can't tweak kernel parameters or customize the Chromium build. For most automation workloads, this doesn't matter.

Comparison Table: BaaS vs Self-Hosted

Criterion	Browser-As-A-Service	Self-Hosted Playwright
Setup time	Minutes (API key + connect)	Days to weeks (infra + config)
Scaling	Automatic, on-demand	Manual or custom auto-scaling
Session persistence	Built-in, survives worker restarts	Requires custom state management
Live debugging	Included (live viewer, session logs)	Build it yourself or use third-party tools
IP/network management	Platform handles proxy config	You manage proxies, IP rotation, reputation
Maintenance	Platform handles Chromium updates	You handle version bumps and security patches
Cost model	Per browser-hour, no idle cost	Fixed compute cost, idle or not
Control	Limited to platform APIs	Full control over environment
Best for	AI agents, production automation, teams without infra resources	Teams with strong infra expertise, custom browser needs

When Self-Hosting Still Makes Sense

Self-hosting isn't obsolete. It's the right choice when:

You need custom Chromium builds: Modified browser binaries for specific fingerprinting or rendering needs.
You have strict data residency requirements: Browsers must run in your VPC or on-premises.
You already have the infrastructure: Your team runs Kubernetes and manages stateful services daily.
Your workload is predictable and steady: A fixed number of sessions running 24/7. The cost of idle compute is acceptable.

If you're running 10–20 concurrent sessions with a stable workload and you have the operational capacity, self-hosting can be cost-effective.

When Browser-As-A-Service Wins

BaaS wins for most AI agent workloads:

Bursty traffic: Your agent usage spikes during business hours or after a product launch. You don't want to provision for peak load.
Distributed workers: Your agents run across multiple cloud functions or workers. Sessions need to be shared and persistent.
Rapid iteration: You're building agents, not infrastructure. Every hour spent on browser infra is an hour not spent on agent logic.
Production reliability: You need session recovery, retry logic, and observability without building it yourself.

The Remote Browser API is designed for this. It gives you a simple HTTP/WebSocket interface to hosted Chromium, with session persistence and live debugging built in.

How to Connect Playwright to a Remote Browser

If you're evaluating BaaS, the integration should be straightforward. Here's a TypeScript example using Playwright's CDP connection:

import { chromium } from 'playwright';
import { RemoteBrowser } from '@remote-browser/sdk';

async function runAgentTask() {
  // Create a new browser session on the remote platform
  const session = await RemoteBrowser.createSession({
    // Persistent profile ID for logged-in state
    profileId: 'user-123',
    // Configurable browser settings
    settings: {
      viewport: { width: 1280, height: 720 },
      userAgent: 'Mozilla/5.0 (Windows NT 10.0; Win64; x64)',
    },
  });

  // Connect Playwright to the remote Chromium instance via CDP
  const browser = await chromium.connectOverCDP(session.cdpUrl);
  const page = await browser.newPage();

  try {
    await page.goto('https://example.com');
    await page.fill('#search', 'browser automation');
    await page.click('button[type="submit"]');

    const results = await page.locator('.result').allTextContents();
    console.log('Results:', results);

    // Session stays alive after this function returns
    // Other workers can pick up where this left off
  } finally {
    // Don't close the browser if you want to persist the session
    // await browser.close();
  }
}

The key point: the session persists on the remote platform. If your worker crashes, another worker can reconnect to the same session and continue. This is critical for long-running agent tasks.

Session Persistence Across Cloud Workers

One of the hardest problems in self-hosted browser automation is keeping sessions alive across multiple cloud workers. A worker dies, the browser dies, and the session state is lost. Your agent has to restart from scratch.

BaaS platforms solve this by decoupling the browser process from the worker. The browser runs on the platform's infrastructure. Workers connect and disconnect as needed. The session state—cookies, localStorage, navigation history—lives on the platform.

This is especially important for AI agents that need to maintain context across multiple steps. An agent that logs into a portal, navigates through several pages, and extracts data needs the session to survive any worker failure.

For a deeper dive on this, see our post on keeping browser sessions alive across cloud workers.

The "Chrome Remote Desktop Typing Fix" Problem

A common pain point in browser automation is typing issues. Characters get dropped, input events fire in the wrong order, or the page doesn't register keystrokes. This is often caused by:

Latency between the worker and the browser: If the browser is on a different machine, input events have network latency.
Event ordering: CDP input events can arrive out of order if not properly sequenced.
Focus issues: The browser tab loses focus, and the page doesn't process input.

In a BaaS setup, the browser and the automation client are on different machines, so latency is a factor. However, modern platforms handle this by batching input events and using CDP's Input.dispatchKeyEvent with proper sequencing.

If you're seeing typing issues in your automation, check:

Use page.type() instead of page.fill() for fields that need keystroke simulation.
Add small delays between keystrokes for pages with heavy JavaScript listeners.
Ensure the page has focus before sending input events.

For production workloads, the platform's network infrastructure matters. A BaaS with low-latency connections to your workers will have fewer input issues.

AI Agent Browser Access in Production

Giving your AI agent browser access in production is different from running a local script. You need:

Reliability: The agent must complete tasks without human intervention.
Observability: You need to see what the agent is doing, step by step.
Safety: The agent should be sandboxed and have limited permissions.
Scalability: Multiple agents running concurrently without interference.

A BaaS platform provides these by default. Sessions are isolated, live viewing shows agent actions in real time, and the API supports programmatic control.

Self-hosting requires you to build all of this. Session isolation is easy with separate browser processes, but observability and safety require significant engineering.

Cost Analysis: Browser-Hour vs Fixed Compute

The pricing models differ fundamentally:

Self-hosted: You pay for compute whether you use it or not. A VM running 24/7 costs the same whether it's running one browser or ten. For steady workloads, this is predictable. For bursty workloads, you over-provision.

BaaS: You pay per browser-hour. Idle time costs nothing. This is ideal for workloads with variable demand. The trade-off is that heavy usage can be more expensive than a fixed VM.

The right model depends on your usage pattern. If you run 100 browsers 24/7, self-hosting might be cheaper. If you run 10 browsers during business hours and 0 at night, BaaS is more cost-effective.

Check the current pricing for details on browser-hour rates.

Operational Considerations

Beyond cost, consider the operational burden:

Task	Self-Hosted	BaaS
Monitoring	Set up Prometheus/Grafana, alerting	Platform provides dashboards and logs
Incident response	You're on call for browser crashes	Platform handles infrastructure incidents
Security patching	You track CVEs and update Chromium	Platform applies patches
Capacity planning	You forecast and provision	Platform scales automatically
Compliance	You control data flow	Platform has compliance certifications

For a small team, the operational burden of self-hosting can be the deciding factor. Every hour spent on infrastructure is an hour not spent on your core product.

Making the Decision

Here's a practical framework:

Count your concurrent sessions: If you need more than 20 concurrent browsers, BaaS becomes more attractive.
Assess your team's infra skills: Can you run stateful services in production? If not, BaaS is the safer choice.
Evaluate your traffic pattern: Bursty or unpredictable? BaaS handles this better.
Check your debugging needs: Do you need live viewing and session replay? BaaS provides this out of the box.
Consider your timeline: If you need to ship in weeks, not months, BaaS wins.

The Hybrid Approach

You don't have to choose one or the other. Many teams run a hybrid:

Self-hosted for stable, predictable workloads with custom requirements.
BaaS for bursty traffic, AI agents, and experiments.

This gives you the best of both worlds. The key is to abstract your browser access behind a common interface so you can switch between runtimes as needed.

Conclusion

The browser-as-a-service vs self-hosted Playwright infra decision comes down to your team's resources and your workload's characteristics. BaaS platforms like Remote Browser eliminate the operational overhead of running browsers at scale, provide session persistence across workers, and offer live debugging for AI agents.

Self-hosting gives you control and potentially lower costs for steady, predictable workloads. But it requires significant infrastructure expertise and ongoing maintenance.

For most AI agent workloads, BaaS is the pragmatic choice. It lets you focus on building your agent, not managing browsers. Start with a remote browser session and see how it fits your workflow.

If you're building AI agents that need reliable browser access, check out our guide on remote web browsers for production automation. And for a deeper look at the runtime layer, see remote control browser for how code and agents drive the web.

For more technical details on the CDP connection, refer to the Chrome DevTools Protocol documentation.

Virtual Browser API Integration: A Practical Guide for AI Agents

RemoteBrowser — Thu, 27 Aug 2026 05:46:26 +0000

Virtual Browser API Integration: A Practical Guide for AI Agents

Virtual browser API integration is the missing layer between your AI agent's code and the live web. When your agent needs to click, type, scrape, or authenticate on a real website, you have two options: run a browser locally on your own machine, or connect to a hosted Chromium instance through a well-defined API. The second approach—virtual browser API integration—is what production AI agents use to avoid the operational overhead of managing browser infrastructure themselves.

This guide explains what a virtual browser API actually provides, how to integrate it with Playwright, Puppeteer, or raw CDP, and what production criteria matter when you're deciding between a hosted browser API and self-hosted infrastructure.

What Is a Virtual Browser API?

A virtual browser API is a programmatic interface to a remote Chromium instance. Instead of launching a browser process on your local machine or inside your application server, you send a request to a hosted service that spins up a browser session in the cloud. Your code connects to that session over WebSocket or HTTP, and then drives it using standard protocols.

The core protocols are:

Chrome DevTools Protocol (CDP): The native protocol that Chromium exposes. Every browser automation tool ultimately speaks CDP under the hood.
Playwright: A higher-level library that wraps CDP and provides a clean API for navigation, clicking, waiting, and assertions.
Puppeteer: Google's Node.js library, also built on CDP, with a slightly different API surface.
Selenium: The older standard, primarily used for testing but still relevant for some automation workloads.

A virtual browser API abstracts away the browser process itself. You don't install Chrome, you don't manage dependencies, you don't worry about memory leaks or zombie processes. You just call an endpoint, get a connection string, and start driving the browser.

Why Virtual Browser API Integration Matters for AI Agents

AI agents that interact with the web have a specific problem: they need a browser that stays alive, maintains state, and can be observed in real time. Local browsers fail on all three counts in production.

Consider what happens when an AI agent runs on a cloud worker (like Cloudflare Workers, AWS Lambda, or a Kubernetes pod). The worker is stateless and short-lived. If the agent needs to log into a site, navigate through a multi-step flow, and then extract data, it needs a browser session that persists beyond the worker's lifetime. A local browser process dies when the worker dies.

Virtual browser API integration solves this by decoupling the browser session from the compute that drives it. The browser runs in a hosted environment, and your agent connects to it from anywhere. If the worker crashes, the browser session survives. If the agent needs to pause and resume, the session is still there.

How to Keep Browser Sessions Alive Across Multiple Cloud Workers

This is the most common production question we hear: "How do I keep a browser session alive when my agent runs on ephemeral infrastructure?"

The answer is that you don't keep the session alive on the worker. You keep it alive in the hosted browser runtime, and you reconnect to it from each worker invocation.

Here's the pattern:

Create a session via the virtual browser API. The API returns a session ID and a WebSocket endpoint.
Store the session ID in your state store (Redis, DynamoDB, or any key-value store).
Reconnect from any worker by passing the session ID to the API and getting a fresh WebSocket connection.

The browser itself never stops running. It's hosted on infrastructure designed for long-lived processes, not ephemeral serverless functions.

import { chromium } from 'playwright';

// Connect to an existing hosted browser session
const browser = await chromium.connectOverCDP(
  'wss://remote-browser.dev/cdp/session_abc123'
);

// The session persists across worker invocations
const page = await browser.newPage();
await page.goto('https://example.com');
console.log(await page.title());

// Do NOT close the browser — just disconnect
await browser.close();

This pattern works because the browser session is infrastructure, not a process tied to your application's lifecycle.

Virtual Browser API vs. Self-Hosted Playwright Infrastructure

The biggest decision you'll make is whether to use a hosted virtual browser API or run your own Playwright infrastructure. Both approaches work, but they have very different operational profiles.

Criterion	Virtual Browser API (Hosted)	Self-Hosted Playwright
Setup time	Minutes — API key and connect	Days — install browsers, manage dependencies
Scaling	Automatic — sessions spin up on demand	Manual — you provision and manage browser instances
Session persistence	Built-in — sessions survive worker restarts	You build it — need a session manager and state store
Live debugging	Included — view the browser in real time	You build it — need a VNC or WebRTC setup
Proxy support	Configurable per session	You manage proxies yourself
Maintenance	None — the provider handles Chromium updates	Ongoing — you patch and upgrade browsers
Cost model	Metered per browser-hour	You pay for the underlying compute regardless of usage
Stealth settings	Configurable browser settings	You implement and maintain them yourself

The trade-off is control versus convenience. Self-hosted Playwright gives you complete control over the browser environment, but you own every operational problem: browser crashes, memory leaks, version drift, proxy management, and session management.

A virtual browser API moves those problems to the provider. You trade some control for a significant reduction in operational complexity.

How to Give Your AI Agent Browser Access in Production

If you're building an AI agent that needs to browse the web, here's the production checklist:

1. Choose Your Protocol

Start with Playwright if you're writing new code. It has the best API for complex interactions and handles waiting and retries well. Use raw CDP if you need low-level control or if you're building a custom agent framework that speaks CDP directly.

2. Connect to the Virtual Browser API

Most virtual browser APIs expose a WebSocket endpoint that's compatible with Playwright's connectOverCDP or Puppeteer's connect methods. You pass the connection URL and start driving the browser.

3. Configure Session Persistence

Make sure your sessions are persistent. If your agent needs to log into a site and then perform actions over time, you need a browser profile that survives disconnects. Look for a virtual browser API that supports persistent profiles.

4. Set Up Live Debugging

When your agent fails, you need to see what happened. A live viewer that shows the browser screen in real time is invaluable for debugging. You can watch the agent's actions, spot where it goes wrong, and fix the prompt or the code.

5. Handle Proxies and IP Quality

Some sites block datacenter IPs. If your agent needs to access sites with strict bot detection, you'll need proxy support. A virtual browser API with configurable proxy settings lets you route traffic through residential or mobile IPs without changing your code.

Browser-as-a-Service vs. Self-Hosted: A Decision Framework

The "browser-as-a-service" (BaaS) category has grown because AI agents need browsers that are reliable, observable, and scalable. But BaaS isn't always the right choice. Here's a framework to decide:

Choose a virtual browser API when:

Your agent runs on serverless or ephemeral infrastructure
You need session persistence across multiple invocations
You want live debugging without building a VNC setup
You need to scale browser sessions up and down quickly
You don't want to maintain browser infrastructure

Choose self-hosted Playwright when:

You have strict data residency requirements
You need a custom browser build or specific Chromium flags
You have a dedicated infrastructure team
Your usage is predictable and high-volume
You need to keep everything inside your VPC

Most teams start with self-hosted Playwright and switch to a virtual browser API when they hit the operational wall: sessions dying, browsers crashing, or the team spending more time on infrastructure than on the actual agent logic.

Chrome Remote Desktop Typing Fix: Why Browser Automation Tools Differ

A common search query is "chrome remote desktop typing fix browser automation selenium playwright." This usually comes from developers who tried to automate a browser through Chrome Remote Desktop and found that keystrokes don't register properly.

The issue is that Chrome Remote Desktop is designed for human interaction, not programmatic control. When you send keystrokes through the remote desktop protocol, they go through an input pipeline that's not the same as CDP. Selenium and Playwright, by contrast, inject events directly into the browser's rendering engine via CDP. That's why automation tools work reliably while remote desktop typing does not.

This is a good example of why virtual browser API integration matters: you get the CDP-level control that automation tools need, without the input-layer issues that plague remote desktop approaches.

Web Browser Agent: The Runtime Requirements

When people search for "web browser agent" or "agent browser," they're usually looking for a way to give their AI model a browser that it can control. The requirements for an agent browser are different from a test browser:

Long-lived sessions: Agents often need to maintain state across multiple steps or even multiple days.
Observability: You need to see what the agent is doing, either in real time or through session replays.
Programmatic control: The agent needs to send commands (click, type, navigate) and receive the resulting DOM or screenshot.
Isolation: Each agent should have its own browser profile to avoid cross-contamination of cookies and sessions.
Error recovery: When the agent fails, you need to be able to inspect the state and resume.

A virtual browser API provides all of these. The hosted Chromium runtime handles session persistence, live viewing, and isolation, while your agent code handles the decision-making.

Implementation: Connecting Playwright to a Virtual Browser API

Here's a complete example of integrating a virtual browser API with Playwright in TypeScript:

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

interface VirtualBrowserSession {
  sessionId: string;
  websocketUrl: string;
}

async function createSession(apiKey: string): Promise<VirtualBrowserSession> {
  const response = await fetch('https://api.remote-browser.dev/v1/sessions', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${apiKey}`,
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({
      persistent: true,  // Keep the session alive
      proxy: { enabled: false }
    })
  });

  if (!response.ok) {
    throw new Error(`Failed to create session: ${response.statusText}`);
  }

  return response.json();
}

async function runAgentTask(apiKey: string): Promise<void> {
  // Create a new session or resume an existing one
  const session = await createSession(apiKey);

  // Connect Playwright to the hosted browser
  const browser: Browser = await chromium.connectOverCDP(session.websocketUrl);

  try {
    const page: Page = await browser.newPage();

    // Navigate and interact
    await page.goto('https://example.com/login');
    await page.fill('#username', 'agent-user');
    await page.fill('#password', 'secure-password');
    await page.click('button[type="submit"]');

    // Wait for navigation and extract data
    await page.waitForSelector('.dashboard');
    const data = await page.evaluate(() => {
      return document.querySelector('.dashboard')?.textContent;
    });

    console.log('Extracted data:', data);

    // The session stays alive — we just disconnect
  } finally {
    await browser.close(); // Disconnects, does NOT terminate the session
  }
}

// Usage
const API_KEY = process.env.REMOTE_BROWSER_API_KEY!;
runAgentTask(API_KEY).catch(console.error);

Notice that browser.close() disconnects the client but does not terminate the hosted session. This is the key difference between a local browser and a virtual browser API: the session is managed by the API, not by your client.

Production Criteria for Virtual Browser API Integration

When you evaluate a virtual browser API, use these criteria:

Session Persistence

Can you create a session, disconnect, and reconnect later? Does the session maintain cookies, localStorage, and other state? This is non-negotiable for AI agents that work over extended periods.

CDP Compatibility

Does the API expose a standard CDP WebSocket endpoint? If it does, you can use Playwright, Puppeteer, or any CDP-compatible client. If it only offers a proprietary API, you're locked in.

Live Debugging

Can you watch the browser in real time? A live viewer is essential for debugging agent behavior. Without it, you're working blind when things go wrong.

Proxy and IP Configuration

Can you route traffic through different IPs? Some sites block datacenter IPs, and your agent will fail if it can't reach them. Look for configurable proxy settings per session.

Usage Controls

Can you set limits on session duration, concurrent sessions, or spending? You don't want an agent that runs away and burns through your budget.

Observability

Does the API provide logs, session replays, or network traces? These are critical for understanding why an agent failed and for improving your prompts or code.

The Chrome DevTools Protocol: Your Integration Point

If you're building a custom agent framework, you'll likely interact with the virtual browser API through raw CDP. The Chrome DevTools Protocol is the native language of Chromium, and it's well-documented at chromedevtools.github.io/devtools-protocol.

CDP gives you access to:

Page domain: Navigate, reload, capture screenshots
Runtime domain: Evaluate JavaScript, inspect DOM
Network domain: Intercept requests, modify headers
Input domain: Simulate mouse and keyboard events
Target domain: Manage tabs and browser contexts

A virtual browser API that exposes CDP gives you full control over the browser, just as if it were running locally. The only difference is that the browser runs elsewhere, and you connect over WebSocket.

Conclusion: Virtual Browser API Integration Is the Production Default

Virtual browser API integration is not a niche technique. It's the standard way to give AI agents reliable browser access in production. The pattern is simple: your agent connects to a hosted Chromium session via CDP or Playwright, the session persists across worker restarts, and you get live debugging and configurable browser settings without managing infrastructure.

The decision between a virtual browser API and self-hosted Playwright comes down to operational complexity. If you have a dedicated infrastructure team and strict requirements, self-hosted might work. For everyone else, a virtual browser API is the faster path to a reliable agent.

To get started, check out the Remote Browser documentation for API details, or see how Remote Browser works for AI agents. If you're comparing options, our pricing page explains the browser-hour model, and you can read about connecting to remote browsers or the practical runtime for browser automation. For a deeper look at browser control patterns, see our guide on remote control browser.

The web is where your agents do their work. Make sure the browser they use is built for production.

Web Browser Agent: The Production Runtime for AI Web Automation

RemoteBrowser — Thu, 27 Aug 2026 05:46:25 +0000

Web Browser Agent: The Production Runtime for AI Web Automation

A web browser agent is only as reliable as the browser runtime it controls. When your AI agent needs to navigate a site, fill a form, extract data, or run a multi-step workflow, the underlying Chromium instance determines whether the task succeeds or fails. Local browsers work for prototypes, but production agents need a hosted runtime that keeps sessions alive, survives worker restarts, and exposes the right debugging tools.

This guide covers what a production-grade web browser agent runtime looks like, how to connect your agent to hosted Chromium via CDP or Playwright, and the operational trade-offs you should evaluate before deploying at scale.

Why Local Browsers Fail for AI Agents

Running a web browser agent from your laptop or a single VM seems straightforward. Install Playwright, launch Chromium, and let the agent drive the page. This works until you hit one of these walls:

Session loss: Cloud workers restart, killing the browser process and all cookies, localStorage, and login state.
Resource contention: Chromium is memory-hungry. A single agent instance can consume 500MB+ RAM, and scaling to dozens of concurrent sessions becomes expensive.
Debugging blind spots: When an agent fails, you need to see what it saw. Local browsers don't give you a replayable session timeline.
IP reputation: Datacenter IPs get blocked by anti-bot systems. Your agent's task fails not because of logic errors but because the browser is flagged.

A hosted runtime solves these problems by decoupling the browser from your application infrastructure. The browser lives in the cloud, your agent connects via API, and the session persists independently of your worker processes.

What a Web Browser Agent Runtime Needs

Not all hosted browsers are equal. When evaluating a runtime for your web browser agent, look for these production criteria:

Capability	Why It Matters	Local Browser	Hosted Runtime
Session persistence	Keeps login state across worker restarts	❌ Lost on process kill	✅ Persistent profiles
CDP access	Lets you attach debugging tools and inspect network traffic	✅ Available but local-only	✅ Remote CDP endpoint
Live debugging	See what the agent sees in real time	❌ Requires VNC setup	✅ Built-in live viewer
Proxy support	Route traffic through residential or datacenter IPs	❌ Manual configuration	✅ Configurable per session
Isolation	Prevents one agent's actions from affecting another	❌ Shared process risks	✅ Dedicated browser instances
Scaling	Spin up browsers on demand without provisioning VMs	❌ Manual capacity planning	✅ API-driven provisioning

The core insight: a web browser agent needs a browser that behaves like infrastructure, not like a desktop application. That means API-driven lifecycle management, persistent state, and remote observability.

Connecting Your Agent to Hosted Chromium

Remote Browser exposes a CDP-compatible endpoint that works with Playwright, Puppeteer, and Selenium. The simplest integration path is Playwright's connectOverCDP method.

Here's a TypeScript example that connects a web browser agent to a hosted session:

import { chromium } from 'playwright';

// Connect to a Remote Browser session via CDP
const browser = await chromium.connectOverCDP(
  'wss://remote-browser.dev/cdp/your-session-id'
);

// The default context contains the persistent profile
const context = browser.contexts()[0];
const page = await context.newPage();

// Your agent logic goes here
await page.goto('https://example.com');
await page.fill('#search', 'web browser agent');
await page.click('button[type="submit"]');

// Wait for results and extract data
await page.waitForSelector('.results');
const results = await page.$$eval('.result-item', (items) =>
  items.map((item) => item.textContent)
);

console.log(results);

// The session stays alive after your script ends
await browser.close();

The key difference from local Playwright: connectOverCDP attaches to an existing browser rather than launching a new one. This means your agent can disconnect and reconnect without losing the session state. If a worker crashes mid-task, the next worker can pick up where the previous one left off.

Keeping Browser Sessions Alive Across Cloud Workers

One of the most common questions we hear: how do I keep browser sessions alive across multiple cloud workers? The answer is to separate the browser lifecycle from the worker lifecycle.

With Remote Browser, each session is an independent resource. Your worker connects to the session, performs work, and disconnects. The browser keeps running. When the next worker picks up the task, it connects to the same session and finds the page exactly where the previous worker left it.

This pattern works because sessions are identified by a stable session ID, not by a process ID. The session ID is the handle your agent uses to reconnect. You can store it in a database, pass it between workers, or include it in a task queue message.

For long-running agents, consider a heartbeat mechanism. Your worker sends a keepalive signal to the session at regular intervals. If the worker dies, the session remains available for a grace period, giving your orchestration layer time to spin up a replacement.

Browser-as-a-Service vs. Self-Hosted Playwright Infrastructure

Teams often debate whether to build their own browser infrastructure or use a managed service. Here's an honest comparison:

Self-hosted Playwright infrastructure gives you full control. You provision VMs, install Chromium, write a session manager, handle scaling, and build a debugging UI. This is viable if you have a dedicated infrastructure team and predictable traffic patterns. The costs are hidden: engineering time for maintenance, capacity planning for peak loads, and the operational burden of keeping browsers patched and stable.

Browser-as-a-service (like Remote Browser) shifts the operational burden to the provider. You get API-driven provisioning, persistent sessions, and built-in debugging tools. The trade-off is less control over the underlying infrastructure and a per-hour cost that scales with usage.

For most teams, the decision comes down to whether browser management is a core competency or a distraction. If your product is an AI agent that happens to use a browser, a managed runtime is usually the right call. If you're building a browser automation platform as your product, self-hosting might make sense.

Giving Your AI Agent Browser Access in Production

When you move from prototype to production, your web browser agent needs more than a CDP connection. Here's a deployment checklist:

Session isolation: Each agent task should get its own browser session. This prevents cross-task contamination and makes debugging easier.
Persistent profiles: Store login state, cookies, and local storage in a profile that survives session restarts. This is essential for authenticated workflows.
Proxy configuration: Route traffic through appropriate IPs to avoid blocks. Remote Browser supports configurable proxy settings per session.
Usage controls: Set timeouts and session limits so a stuck agent doesn't run indefinitely and rack up costs.
Observability: Use the live viewer and session recording to see what the agent did when something goes wrong.

The Remote Browser documentation covers these topics in depth, including API reference and integration examples.

Debugging a Web Browser Agent: The Live Viewer Advantage

When an agent fails, the worst outcome is a black box. You know the task didn't complete, but you can't see why. Local browsers offer some debugging tools, but they require the browser to be running on your machine.

Remote Browser includes a live viewer that streams the browser viewport in real time. You can watch the agent navigate, see where it clicks, and spot the exact moment it goes off the rails. This is invaluable for debugging complex workflows where the agent's behavior depends on page state.

For automated debugging, the CDP endpoint gives you access to network logs, console messages, and DOM snapshots. You can programmatically capture these artifacts when a task fails and attach them to your error tracking system.

Browser Automation with Selenium and Other Tools

While Playwright and Puppeteer are the most common choices for AI agents, Selenium remains relevant for teams with existing test suites. Remote Browser's CDP compatibility means you can connect Selenium WebDriver to a hosted session using the appropriate driver configuration.

The same session persistence benefits apply. A Selenium-based agent can disconnect and reconnect without losing the browser state, which is particularly useful for long-running data collection tasks.

The Cost of Running a Web Browser Agent

Pricing for hosted browser runtimes typically follows a per-browser-hour model. You pay for the time a browser session is active, regardless of whether your agent is actively using it. This means idle sessions still incur costs, so it's worth implementing session timeouts and cleanup logic.

Remote Browser's pricing is designed for AI agent workloads, with metered usage that scales with your traffic. For current rates and plan details, see the pricing page. The key is to estimate your concurrent session needs and average session duration, then compare that against the cost of self-hosting (VMs, bandwidth, and engineering time).

Comparing Remote Browser to Other Options

The browser automation landscape includes several hosted options, each with different strengths. Here's how Remote Browser positions itself:

Feature	Remote Browser	Browserbase	Self-Hosted Playwright
CDP access	✅ Full	✅ Full	✅ Full
Persistent profiles	✅ Built-in	✅ Available	❌ DIY
Live viewer	✅ Included	✅ Included	❌ DIY
Playwright/Puppeteer support	✅ Native	✅ Native	✅ Native
Selenium support	✅ Via CDP	✅ Via CDP	✅ Native
Session isolation	✅ Dedicated instances	✅ Dedicated instances	⚠️ Depends on setup
Setup time	Minutes	Minutes	Days to weeks

The main differentiator is the focus on AI agent workloads. Remote Browser was built with agent patterns in mind—session reconnection, persistent state, and debugging tools that match how agents actually fail.

Practical Tips for Building a Reliable Web Browser Agent

Based on production deployments, here are concrete recommendations:

Use session IDs as your source of truth. Store them in your task queue, not in memory. This lets any worker pick up any task.
Implement retry logic with session reconnection. If a CDP connection drops, reconnect to the same session rather than starting over.
Set explicit timeouts. Agents can loop indefinitely on dynamic pages. A 30-second navigation timeout and a 5-minute session timeout are reasonable starting points.
Capture screenshots on failure. A screenshot at the moment of failure is worth a thousand log lines.
Monitor session health. Track the number of active sessions, average session duration, and failure rates. This tells you when to scale up or investigate issues.

The Chrome DevTools Protocol Connection

The Chrome DevTools Protocol (CDP) is the foundation of modern browser automation. It's the same protocol that powers Chrome's developer tools, and it exposes everything from DOM manipulation to network interception to performance metrics.

When your web browser agent connects via CDP, it gets access to the full protocol surface. This includes:

Network events: Monitor requests, responses, and WebSocket traffic.
DOM snapshots: Capture the page structure at any point.
JavaScript execution: Run arbitrary scripts in the page context.
Input events: Simulate mouse, keyboard, and touch interactions.

For a deeper dive into CDP, the official Chrome DevTools Protocol documentation is the authoritative reference.

Conclusion: Choose the Runtime That Matches Your Agent's Needs

A web browser agent is a powerful tool, but its reliability depends entirely on the browser runtime underneath. Local browsers are fine for development, but production agents need hosted Chromium with persistent sessions, remote debugging, and API-driven scaling.

Remote Browser provides this runtime with a focus on AI agent workflows. Whether you're building a research assistant, a data collection pipeline, or an automated QA system, the hosted runtime handles the browser lifecycle so your agent can focus on the task.

Start with the Remote Browser documentation to understand the API, then explore how remote browsers fit into AI agent architectures. For a broader look at the landscape, see our comparison of remote browser options and the practical guide to remote control browsers.

The bottom line: your agent's success rate is a function of the runtime's reliability. Choose accordingly.

DEV Community: RemoteBrowser

Playwright Remote: Run Browser Automation in the Cloud

Playwright Remote: Run Browser Automation in the Cloud

Why "Playwright Remote" Is More Than a Hostname Change

How to Connect Playwright to a Remote Browser

CDP vs. Playwright's WebSocket Protocol

Production Criteria for Playwright Remote Setups

1. Session Lifecycle Control

2. Live Debugging and Visibility

3. Proxy and IP Management

4. Profile Persistence

5. Compatibility Layer

Playwright Remote vs. Local Browser Management

Keeping Browser Sessions Alive Across Cloud Workers

Playwright Remote for AI Agents

The "Agent Browser" Confusion

Selenium and Puppeteer: The Same Remote Pattern

Common Pitfalls with Playwright Remote

Pitfall 1: Assuming browser.close() Terminates the Session

Pitfall 2: Ignoring Context Isolation

Pitfall 3: Not Handling Reconnects

Pitfall 4: Forgetting About Browser Version

When Not to Use Playwright Remote

Getting Started with Remote Browser

The Bottom Line on Playwright Remote

What Is Agent Browser in Task Manager: A Practical Guide

What Is Agent Browser in Task Manager: A Practical Guide

The Short Answer: It's a Programmatic Browser Process

Why Do Agent Browsers Appear in Task Manager?

Agent Browser vs. Regular Browser: Key Differences

How AI Agents Use Browser Processes

Local vs. Remote Agent Browsers

Local Agent Browsers

Remote Agent Browsers

How to Keep Browser Sessions Alive Across Multiple Cloud Workers

Playwright connect_over_cdp: Firefox Support and Limitations

Agent Control Browser: What It Means for Production

How to Give Your AI Agent Browser Access in Production

Debugging Agent Browsers: Live Viewer and CDP

Common Issues and Fixes

Issue: Chrome Remote Desktop Typing Fix

Issue: Browser Sessions Not Persisting

Issue: Too Many Browser Processes

When to Use a Hosted Agent Browser

The Bottom Line

Agent Browser Record: How to Log and Replay AI Browser Sessions

Agent Browser Record: How to Log and Replay AI Browser Sessions

What Is an Agent Browser Record?

Why a Local Browser Record Isn't Enough

How to Record an Agent Browser Session with CDP

Using Playwright Tracing for a Higher-Level Record

What to Record for AI Agent Evaluation

Keeping Sessions Alive Across Cloud Workers

Live Debugging: The Missing Piece

Comparison: Recording Approaches

Production Criteria for Agent Browser Recording

Getting Started with Remote Browser

Conclusion

Best Infra Setup for Running a Bunch of Browser Automations

Best Infra Setup for Running a Bunch of Browser Automations

Why Local Browser Setup Breaks at Scale

The Core Components of a Production Browser Automation Stack

Browser Runtime: Hosted Chromium vs. Self-Managed

How to Connect: CDP, Playwright, and Selenium

Keeping Browser Sessions Alive Across Cloud Workers

Persistent Profiles: The Key to Realistic Automation

Configurable Browser Settings for Anti-Bot Resistance

Scaling Patterns for Concurrent Automations

1. One Session Per Task

2. Shared Session with Sequential Tasks

3. Session Pool with Dynamic Allocation

What to Look for in a Browser Automation Infrastructure

The Bottom Line

Agent Bowser: The Production Runtime for AI Web Automation

Agent Bowser: The Production Runtime for AI Web Automation

What Is an Agent Bowser?

Why "Bowser" and Not "Browser"?

The Production Problem: Local Browsers Don't Scale

How to Give Your AI Agent Browser Access in Production

Playwright Remote vs. connectOverCDP

Pitfall 1: Assuming `browser.close()` Terminates the Session