Browser As A Service: The Production Runtime for AI Agents

# Browser As A Service: The Production Runtime for AI Agents

Browser as a service is the model of running real Chromium instances in the cloud, exposed via APIs like CDP or WebSocket, rather than managing your own browser infrastructure. For AI agents, browser automation frameworks, and QA pipelines, this approach solves a persistent problem: local browsers are ephemeral, unscalable, and hard to keep alive across distributed workers. This guide explains what browser as a service actually means in production, how it differs from self-hosted setups, and how to connect your Playwright or Puppeteer code to a remote browser session.

Why Browser As A Service Matters

The core value of browser as a service is not just "running a browser in the cloud." It's about treating the browser as a managed runtime with guarantees around uptime, session persistence, and network quality. When you run Playwright locally, you are responsible for the Chromium binary, the system dependencies, the network egress IP, and the session lifecycle. In a distributed system—where your AI agent runs on multiple cloud workers—this becomes a coordination nightmare.

A browser as a service API abstracts away the infrastructure. You get a URL, a session ID, and a way to connect. The service handles the browser lifecycle, keeps the session alive across your worker restarts, and provides a consistent environment. This is particularly important for AI agents that need to maintain state, cookies, or logged-in sessions while the underlying compute scales up and down.

The Production Criteria for Browser As A Service

Not all browser-as-a-service offerings are equal. When evaluating a provider, or when building your own internal service, you need to consider these production criteria:

1. Session Persistence and Liveness

The most common failure mode in browser automation is a session that dies when the worker dies. In a serverless or containerized environment, your code can be terminated at any time. If your browser session is tied to that process, you lose all state.

A proper browser as a service decouples the browser process from your application process. The browser runs in a separate container or VM. Your code connects to it via CDP. If your worker crashes, the browser session remains alive, and you can reconnect from a new worker. This is the difference between "running a browser in a container" and "browser as a service."

2. Network Egress and IP Quality

When your browser runs on your laptop, it uses your home IP. When it runs in a cloud worker, it uses the cloud provider's IP range. Many websites block or challenge these IP ranges. A browser as a service should offer configurable browser settings for proxies or network egress, allowing you to route traffic through specific IPs or regions.

3. Observability and Debugging

You cannot debug a browser you cannot see. A production browser service needs a live viewer or a way to record sessions. This is non-negotiable for AI agents that make mistakes. You need to see what the agent saw, replay the session, and understand why it failed.

4. API Compatibility

Your code should not care whether the browser is local or remote. The service should expose a standard protocol—CDP is the universal language. If you are using Playwright, you should be able to use connectOverCDP with minimal code changes. If you are using Puppeteer, you should be able to connect via puppeteer.connect.

How to Connect: Playwright and CDP

The most common way to connect to a browser as a service is via the Chrome DevTools Protocol (CDP). Playwright has first-class support for this via chromium.connectOverCDP. Here is a concrete TypeScript example:

import { chromium } from 'playwright';

async function main() {
  // The CDP URL is provided by the browser-as-a-service API.
  // It typically looks like: wss://remote-browser.dev/cdp/session/abc123
  const cdpUrl = process.env.REMOTE_BROWSER_CDP_URL;

  if (!cdpUrl) {
    throw new Error('REMOTE_BROWSER_CDP_URL is not set');
  }

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

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

  // Use the page as you normally would.
  const page = await context.newPage();
  await page.goto('https://example.com');
  const title = await page.title();
  console.log(`Title: ${title}`);

  // Do NOT close the browser. Closing it will terminate the remote session.
  // Instead, just disconnect from it.
  await browser.close();
}

main().catch(console.error);

Important: When connecting to a remote browser, you should not call browser.close() if you want to keep the session alive. browser.close() in Playwright will close the browser process. Instead, you should just let the script exit, which will close the WebSocket connection but leave the remote browser running. The service will keep the session alive until a timeout or until you explicitly terminate it via the API.

Browser As A Service vs. Self-Hosted Playwright Infra

Many teams start by self-hosting Playwright. They run a few containers, maybe use xvfb for headless mode, and call it a day. This works for small test suites. It breaks down for AI agents and large-scale automation.

The trade-off is clear: self-hosting gives you control but consumes engineering time. Browser as a service gives you a managed runtime but requires you to trust the provider's API and uptime. For production AI agents, the managed approach is usually the right call because the cost of a session dying mid-task is higher than the cost of the service itself.

Keeping Sessions Alive Across Cloud Workers

A common question is: "How do I keep a browser session alive across multiple cloud workers?" The answer is to use a browser as a service that separates the browser process from the worker process.

Here is the pattern:

1. Worker A starts a task. It requests a new browser session from the service.
2. The service creates a Chromium instance and returns a CDP URL.
3. Worker A connects, does some work, and then crashes or finishes its slice of the task.
4. Worker B picks up the next slice. It receives the same CDP URL (stored in a task queue or database).
5. Worker B connects to the same session. The cookies, local storage, and DOM state are all preserved.

This pattern is essential for long-running tasks like form submissions, multi-step checkouts, or AI agents that need to maintain context. Without a persistent session, you would have to replay all previous steps on every new worker, which is slow and error-prone.

Browser As A Service for AI Agents

AI agents—especially those built on frameworks like browser-use or LangChain—need a browser to interact with the web. The challenge is that these agents are often stateless. They run in a serverless function, make a decision, and call a tool. If the browser is local to that function, the agent loses all context between calls.

Browser as a service solves this by providing a persistent browser that the agent can connect to across multiple invocations. The agent can:

• Maintain a logged-in session (e.g., Gmail, LinkedIn, or a SaaS dashboard).
• Keep a shopping cart or form state intact.
• Reuse the same browser profile to avoid CAPTCHAs and bot detection.

For example, an agent that monitors a dashboard every 5 minutes can connect to the same browser session each time. It does not need to re-authenticate or re-navigate to the dashboard. It just checks the current state and makes a decision.

Firefox and CDP: A Note on Compatibility

Most browser-as-a-service offerings are built on Chromium because of its robust CDP support. Firefox has a CDP implementation, but it is less complete and less stable than Chromium's. If you need Firefox, you should check whether the service supports it and what limitations exist.

Playwright's connectOverCDP is primarily designed for Chromium. While there is experimental support for Firefox, it is not recommended for production. If you need Firefox-specific testing, you are better off using Playwright's native Firefox support with a remote browser that exposes a WebSocket endpoint, rather than relying on CDP.

Virtual Browser with API: The Implementation Details

When you use a browser as a service, you are essentially getting a virtual browser with an API. The API typically includes:

• Session Management: Create, list, and terminate browser sessions.
• Connection Details: Get the CDP URL or WebSocket endpoint for a session.
• Profile Management: Create persistent profiles that store cookies and local storage.
• Live Viewer: A web-based view of the browser screen for debugging.
• Usage Controls: Limits on concurrent sessions, timeouts, and idle shutdown.

Here is a typical API flow:

1. POST /sessions to create a new session. The response includes a sessionId and a cdpUrl.
2. GET /sessions/{id} to check the status or get the current CDP URL.
3. POST /sessions/{id}/terminate to kill the session.

The CDP URL is the key piece. It is a WebSocket endpoint that your Playwright or Puppeteer client connects to. The URL is stable for the lifetime of the session, allowing you to reconnect from any worker.

Security and Isolation

A browser is a powerful tool. It can access internal networks, read files, and execute JavaScript. When you run a browser as a service, you need to ensure that sessions are isolated from each other and from the underlying host.

Look for these security features:

• Session Isolation: Each session should run in its own container or VM. A malicious website in one session should not be able to access another session.
• Network Restrictions: The browser should not have access to the service's internal network unless explicitly configured.
• Credential Handling: API keys and CDP URLs should be treated as secrets. They should be short-lived and revocable.

When Not to Use Browser As A Service

Browser as a service is not always the right answer. If you are running a small, local test suite that runs once a day, self-hosting is simpler and cheaper. If you need to test against a localhost server, a remote browser cannot access it unless you expose it via a tunnel.

Browser as a service is most valuable when:

• You have multiple workers or serverless functions that need to share browser state.
• You need a stable, non-cloud IP address to avoid bot detection.
• You need to scale browser instances up and down quickly.
• You need a live view or recording for debugging AI agent behavior.

Getting Started with Remote Browser

Remote Browser provides a browser as a service designed for AI agents and browser-use workflows. It offers hosted Chromium sessions with CDP access, Playwright/Puppeteer/Selenium compatibility, a live viewer, persistent profiles, and configurable browser settings for proxies and stealth.

To get started:

1. Create a session via the API or dashboard.
2. Get the CDP URL for the session.
3. Connect using Playwright's connectOverCDP or Puppeteer's connect.
4. Keep the session alive across your workers by storing the CDP URL in your task queue.

For more details on the API, see the documentation. For current pricing and usage limits, check the pricing page.

If you are building an AI agent, you may also want to read about remote browsers for AI agents and how to keep sessions alive across cloud workers.

Conclusion

Browser as a service is the missing runtime layer for production web automation. It decouples the browser from your application code, enabling persistent sessions, scalable concurrency, and reliable network egress. For AI agents that need to maintain context across multiple invocations, it is not a nice-to-have—it is a requirement.

The key is to choose a service that provides a stable CDP endpoint, session persistence, and observability. Connect with Playwright's connectOverCDP, treat the CDP URL as a durable resource, and design your workers to reconnect to the same session. This pattern will save you hours of debugging and make your automation truly production-ready.

For a deeper dive into the technical details of connecting to remote browsers, refer to the official Playwright CDP documentation.