Cloud Browser API: The Production Runtime for AI Agents

# Cloud Browser API: The Production Runtime for AI Agents

A cloud browser API is the missing infrastructure layer between your AI agent's intent and a real, working browser session. When your agent needs to log into a portal, scrape a dynamic page, or fill out a multi-step form, it needs more than a prompt—it needs a Chromium instance that can run JavaScript, maintain cookies, and render complex layouts. The Remote Browser API provides exactly that: hosted Chromium sessions accessible over HTTP, WebSocket, and the Chrome DevTools Protocol (CDP), with Playwright and Puppeteer compatibility built in.

This guide explains what a cloud browser API actually does, how to connect to it from your code, and the production considerations that determine whether your automation succeeds or fails.

Why a Cloud Browser API Beats Local Browser Setup

Running browsers locally works for development. It fails in production for three concrete reasons:

1. Resource contention. A single Chromium instance consumes 300–800 MB of RAM. Running ten concurrent sessions on a small VM will exhaust memory and cause crashes.
2. Network egress. Your local machine's IP address is shared, flagged, or geographically wrong for the target site. Cloud browsers can use configurable proxy settings to route traffic appropriately.
3. Session persistence. When your local machine sleeps, reboots, or loses network, all browser state disappears. A cloud browser API keeps sessions alive independently of your development environment.

The Remote Browser API solves these by running Chromium in isolated containers. Each session gets its own browser process, its own profile directory, and its own network egress. You connect over the network, not by spawning a process on your machine.

How the Cloud Browser API Works

The Remote Browser API exposes three primary interfaces:

The core workflow is straightforward:

1. Create a session via the REST API or the SDK.
2. Connect to the session using Playwright, Puppeteer, or raw CDP.
3. Execute your automation logic.
4. Persist or terminate the session based on your workflow.

Here's a minimal TypeScript example using Playwright to connect to a remote browser session:

import { chromium } from 'playwright';

// The CDP endpoint returned when you create a session
// via the Remote Browser API
const cdpUrl = 'wss://remote-browser.dev/cdp/session_abc123';

async function main() {
  // Connect to the hosted Chromium instance
  const browser = await chromium.connectOverCDP(cdpUrl);
  
  // Get the default context (persistent profile is available)
  const context = browser.contexts()[0];
  const page = await context.newPage();
  
  // Navigate and interact
  await page.goto('https://example.com');
  await page.click('button[data-testid="login"]');
  await page.fill('input[name="email"]', 'agent@example.com');
  
  // Take a screenshot for debugging
  await page.screenshot({ path: 'debug.png' });
  
  // Keep the session alive for the next task
  // Do NOT close the browser if you want to reuse it
  // await browser.close();
}

main().catch(console.error);

The key detail: you are not launching a browser. You are connecting to one that already exists in the cloud. This distinction matters for session persistence.

Keeping Browser Sessions Alive Across Multiple Cloud Workers

One of the most common questions we hear is: *how do I keep a browser session alive when my worker or serverless function terminates?*

The answer is architectural. In a serverless environment, your function's lifecycle is short. The browser session, however, lives in the Remote Browser infrastructure, independent of your function. Here's the pattern:

1. Create the session in one function invocation.
2. Store the session ID in your database or state store.
3. Reconnect in subsequent invocations using the same session ID.

The session remains alive because it is not tied to your worker's process. It runs on our infrastructure until you explicitly terminate it or it hits your configured idle timeout.

// Worker 1: Create session and store ID
const session = await remoteBrowser.createSession({
  profileId: 'persistent-profile-1',
  proxy: { country: 'US' }
});
await db.set('active-session', session.id);

// Worker 2 (later): Reconnect to the same session
const sessionId = await db.get('active-session');
const browser = await chromium.connectOverCDP(
  `wss://remote-browser.dev/cdp/${sessionId}`
);

This pattern enables long-running workflows that span multiple serverless invocations, cron jobs, or distributed worker pools.

Playwright Connect to Remote Browser: A Practical Guide

The connectOverCDP method is the most reliable way to connect Playwright to a remote browser. It works because CDP is the native protocol Chromium speaks. Here's what you need to know:

• Version compatibility. Playwright's CDP support works with any Chromium version, not just the one bundled with Playwright. This means you can use the latest Playwright features against our hosted Chromium.
• Context handling. When you connect over CDP, the browser may already have a default context. Use browser.contexts()[0] to access it, or create new contexts as needed.
• Session reuse. You can disconnect and reconnect to the same browser session. The browser keeps running in the cloud, so your cookies, localStorage, and in-memory state persist.

For Selenium users, the Remote Browser API also supports the WebDriver protocol. You can point your existing Selenium tests at our remote WebDriver endpoint without rewriting your test suite.

Remote Browser Data: Profiles, Cookies, and Persistent State

A cloud browser API is only useful if it can maintain state across sessions. The Remote Browser API provides two levels of persistence:

1. Session-level persistence. As long as the session is alive, all cookies, localStorage, and IndexedDB data persist. This is sufficient for most multi-step tasks.
2. Profile-level persistence. For workflows that span multiple sessions (e.g., a daily login task), you can attach a persistent profile. The profile stores cookies, browser extensions, and site data, and is reattached when you create a new session.

This is critical for AI agents that need to maintain authenticated state. Instead of re-authenticating on every task, your agent can reuse a profile with valid session cookies.

Remote Browser Test: Running QA Suites in the Cloud

Beyond AI agents, a cloud browser API is a powerful tool for QA automation. Running tests in the cloud offers several advantages:

• Parallel execution. Spin up multiple sessions to run tests concurrently without local resource limits.
• Consistent environment. Every test runs on the same Chromium version and OS, eliminating "works on my machine" issues.
• Geographic targeting. Use proxy settings to test how your site behaves from different regions.

Here's a comparison of running tests locally versus using a cloud browser API:

For teams running nightly regression suites, the cloud approach eliminates the flakiness caused by local environment drift.

Remote Browser Pricing: What You Pay For

The Remote Browser API uses a browser-hour pricing model. You pay for the time a browser session is active, not for the number of requests or pages loaded. This aligns cost with actual resource consumption.

Key pricing considerations:

• Idle time counts. If you keep a session alive but unused, you still pay for the browser-hour. Terminate sessions you no longer need.
• Profiles add overhead. Persistent profiles consume storage and may incur additional costs. Check the pricing page for current rates.
• Concurrency is configurable. You can set limits on how many sessions run simultaneously to control costs.

For current pricing details, refer to the pricing page. We do not require long-term commitments; you pay for what you use.

How to Give Your AI Agent Browser Access in Production

The most common production pattern for AI agents is the tool-calling loop. Your agent receives a task, decides which tools to call, and the browser tool executes the action. Here's how to integrate the Remote Browser API into this loop:

1. Define a browser tool. Create a function that takes a task description and returns the result of executing that task in the browser.
2. Use a persistent session. Maintain a session across multiple tool calls to preserve context and authentication.
3. Handle errors gracefully. If a page times out or an element is not found, return a structured error to the agent so it can adjust its strategy.

// Example tool definition for an AI agent
const browserTool = {
  name: 'browser_action',
  description: 'Execute a browser action on the current page',
  parameters: {
    type: 'object',
    properties: {
      action: { type: 'string', enum: ['click', 'type', 'navigate', 'extract'] },
      selector: { type: 'string' },
      value: { type: 'string' }
    }
  },
  execute: async (params) => {
    // Connect to the persistent session
    const browser = await chromium.connectOverCDP(sessionUrl);
    const page = browser.contexts()[0].pages()[0];
    
    switch (params.action) {
      case 'click':
        await page.click(params.selector);
        break;
      case 'type':
        await page.fill(params.selector, params.value);
        break;
      case 'navigate':
        await page.goto(params.value);
        break;
      case 'extract':
        return await page.textContent(params.selector);
    }
    
    return { success: true };
  }
};

This pattern gives your agent real browser access without requiring it to manage browser lifecycle.

Remote Browser Core: What's Under the Hood

The Remote Browser API is built on a core of hosted Chromium instances. Each session is an isolated browser process with:

• Dedicated resources. CPU and memory are allocated per session, preventing noisy neighbors.
• Configurable browser settings. You can adjust viewport size, user agent, and other browser parameters via the API.
• Live debugging. The live viewer lets you watch a session in real time, which is invaluable for debugging agent behavior.

The infrastructure handles the operational burden: keeping Chromium updated, managing container lifecycle, and ensuring network reliability.

Production Criteria for Choosing a Cloud Browser API

When evaluating a cloud browser API, consider these criteria:

1. Protocol support. Does it support CDP, Playwright, and Selenium? You don't want to rewrite your automation stack.
2. Session persistence. Can you keep sessions alive across worker restarts? This is non-negotiable for AI agents.
3. Profile management. Can you store and reuse browser profiles for authenticated tasks?
4. Observability. Can you watch sessions live and capture logs for debugging?
5. Pricing transparency. Is the pricing model predictable? Browser-hour pricing is the industry standard for a reason.

The Remote Browser API meets all of these criteria. For a deeper dive into the architecture, read our post on remote browsers for AI agents.

Getting Started with the Remote Browser API

To start using the cloud browser API:

1. Create an account and get your API key.
2. Create a session using the REST API or SDK.
3. Connect using Playwright, Puppeteer, or raw CDP.
4. Run your automation and monitor it via the live viewer.

The documentation includes quickstart guides, API references, and code samples for all supported languages.

For a broader overview of what a remote browser can do, see our guide on remote browser online and the remote web browser runtime.

Conclusion

A cloud browser API is not a luxury—it is the production runtime for any serious browser automation workload. Whether you are building an AI agent that browses the web, running a QA suite that needs parallel execution, or maintaining a scraping pipeline that requires persistent sessions, the Remote Browser API gives you the infrastructure to do it reliably.

The key takeaway: stop managing browsers locally. Connect to hosted Chromium sessions over CDP, keep them alive across workers, and let the infrastructure handle the operational complexity. Your code—and your agents—will be more reliable for it.

For implementation details, refer to the Chrome DevTools Protocol documentation to understand the underlying protocol. Then start building with the Remote Browser API.