APIs for Browser Automation Without Managing Playwright Infra Manually

# APIs for Browser Automation Without Managing Playwright Infra Manually

If you build AI agents or web automation pipelines, you know the pain: installing Playwright, keeping Chromium versions in sync, managing browser pools, and debugging flaky sessions across multiple cloud workers. The alternative is an API for browser automation that lets you connect to a hosted Chromium instance over the network. This post explains how to use Remote Browser to run Playwright scripts without managing a single browser process locally.

The Core Problem: Playwright Infra Is Not Your Product

Playwright is a great library. It gives you a clean API for navigation, clicking, form filling, and network interception. But the moment you move from a local script to a production service, you inherit a stack of operational concerns:

• Browser lifecycle: Chromium crashes, OOMs, and zombie processes.
• Version drift: Your local Playwright version may not match the browser binary on the server.
• Concurrency: Each worker needs its own browser instance, which eats memory and CPU.
• Session persistence: Keeping a logged-in session alive across requests requires sticky routing and state serialization.
• Network egress: Cloud workers often have restricted or rotating IPs, which triggers bot detection.

You can solve all of these by running your own browser farm. But that's a full-time job. The faster path is to use a hosted browser API that exposes a remote Chromium instance over CDP (Chrome DevTools Protocol). Your Playwright code connects to that remote browser, and the infrastructure—process management, scaling, session persistence—is handled for you.

What Is a Browser Automation API?

A browser automation API is a network endpoint that gives you control over a real Chromium browser. Instead of launching a browser with playwright.chromium.launch(), you connect to a remote browser using a WebSocket URL. The API handles the browser process, the underlying VM, and the network stack.

Remote Browser provides exactly this. It exposes hosted Chromium sessions that are compatible with Playwright, Puppeteer, and Selenium. You get a WebSocket endpoint, and you use the standard Playwright connectOverCDP method to attach to it.

Here's the mental model:

How to Connect Playwright to a Remote Browser

The integration is straightforward. You create a browser session via the Remote Browser API, get a WebSocket endpoint, and then connect to it with Playwright. Here's a TypeScript example:

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

async function main() {
  // 1. Create a hosted browser session via the API
  const client = new RemoteBrowserClient({
    apiKey: process.env.REMOTE_BROWSER_API_KEY,
  });

  const session = await client.sessions.create({
    // Optional: use a persistent profile for logged-in state
    profileId: 'my-existing-profile',
    // Optional: route traffic through a specific proxy
    proxy: { country: 'US' },
  });

  // 2. Connect Playwright to the remote browser over CDP
  const browser = await chromium.connectOverCDP(session.webSocketUrl);

  // 3. Use Playwright as usual
  const page = await browser.newPage();
  await page.goto('https://example.com');
  const title = await page.title();
  console.log(title);

  // 4. Keep the session alive for reuse, or close it
  await browser.close();
  // session is still alive on the server; you can reconnect later
}

main().catch(console.error);

The key difference from local Playwright: connectOverCDP does not launch a browser. It attaches to an existing Chromium process running in the cloud. That process can outlive your script, which is the foundation for persistent sessions.

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 across multiple cloud workers?* The answer is that you don't keep it alive in your worker—you keep it alive in the hosted runtime.

With Remote Browser, a session is a server-side resource. It has a unique ID and a WebSocket endpoint. Any worker that knows the session ID can connect to it. This solves the "sticky session" problem that plagues serverless deployments.

Consider a typical flow:

1. Worker A creates a session, logs into a service, and saves the session ID.
2. Worker A finishes its task and terminates. The browser session remains active on the Remote Browser infrastructure.
3. Worker B picks up the next task, looks up the session ID from your database, and connects to the same browser.
4. Worker B sees the logged-in state because the session was never destroyed.

This pattern works because the browser is not tied to the worker's lifecycle. It's a separate resource, like a database connection or a Redis cache. You can also use persistent profiles, which store cookies, local storage, and other state across sessions. This is useful for long-running automation where you want to avoid re-authenticating on every task.

Why Not Just Use Playwright's Built-In Browser Server?

Playwright has a browserServer mode that lets you launch a browser in one process and connect to it from another. This works on a single machine, but it doesn't solve the distributed problem. You still need to:

• Run the browser server on a machine that is always on.
• Ensure that machine has enough resources for concurrent sessions.
• Handle network security if the browser server is exposed to the internet.
• Manage browser crashes and restarts.

Remote Browser does all of this for you. It runs the browser server in a managed environment with monitoring, auto-restart, and resource isolation. You get the same connectOverCDP API, but the infrastructure is someone else's problem.

Production Criteria for a Browser Automation API

When evaluating a browser automation API, don't just look at the SDK. Look at the operational characteristics that matter in production.

Session Isolation

If you run multiple automation tasks in parallel, you need each task to have its own browser context. Remote Browser provides session isolation by default. Each session is a separate Chromium instance, so a crash in one session doesn't affect others. This is critical for reliability.

Persistent Profiles

Some tasks require a logged-in state. You could re-authenticate on every run, but that's slow and fragile. Persistent profiles let you save the browser state (cookies, localStorage, IndexedDB) and reuse it across sessions. This is the difference between a script that works once and a service that works reliably.

Live Debugging

When something goes wrong, you need to see what the browser is doing. Remote Browser includes a live viewer that streams the browser screen in real time. You can watch your agent navigate, click, and fill forms. This is invaluable for debugging AI agents that make unexpected decisions.

Configurable Network Settings

Bot detection is a real problem. Many sites block traffic from cloud IP ranges. Remote Browser lets you configure proxy settings per session, so you can route traffic through residential or specific geographic IPs. This is a configurable setting, not a magic bullet, but it solves a common failure mode.

Usage Controls

If you're running a fleet of agents, you need to control costs. Remote Browser provides usage controls that let you set limits on session duration, concurrent sessions, and total browser hours. This prevents runaway agents from racking up unexpected charges.

Comparison: Local Playwright vs. Hosted Browser API

Here's a practical comparison for teams deciding between managing their own Playwright infrastructure and using a hosted API:

When You Should Still Run Your Own Playwright

A hosted browser API is not always the right choice. If you have a small, stable workload that runs on a single machine, local Playwright is simpler. You don't need the network overhead, and you have full control over the environment.

You should also consider running your own infrastructure if you have strict data residency requirements that a hosted provider cannot meet, or if you need to run a heavily customized Chromium build. But for most teams—especially those building AI agents or scaling web automation—the operational cost of managing browsers is higher than the API cost.

The Playwright CDP Connection: Under the Hood

When you call chromium.connectOverCDP(), Playwright speaks the Chrome DevTools Protocol over a WebSocket. This is the same protocol that Chrome DevTools uses. The remote browser exposes a WebSocket endpoint, and Playwright sends commands like Page.navigate, Runtime.evaluate, and Input.dispatchMouseEvent.

The beauty of CDP is that it is language-agnostic and version-tolerant. You can connect to a Chromium instance that was launched by a different tool, as long as it exposes a CDP endpoint. This is why Remote Browser can support Playwright, Puppeteer, and Selenium with the same underlying infrastructure.

If you want to understand the protocol in more detail, the official Chrome DevTools Protocol documentation is the authoritative reference. Playwright's own documentation also covers connecting to a browser over CDP.

Practical Tips for Using a Hosted Browser API

Based on our experience with production workloads, here are some tips for getting the most out of a hosted browser API:

1. Use persistent profiles for anything that requires login. Re-authenticating on every session is slow and increases the chance of being blocked. Save the profile after the first successful login.

1. Set explicit timeouts on all Playwright operations. A remote browser has network latency. Don't rely on default timeouts. Set page.setDefaultTimeout() and page.setDefaultNavigationTimeout() to values that match your workload.

1. Handle WebSocket disconnects gracefully. Your worker might lose connectivity. The browser session will stay alive on the server, but your Playwright client will throw an error. Catch it, reconnect, and resume from a known state.

1. Use session IDs as your source of truth. Store the session ID in your database or queue. When a worker picks up a task, it should look up the session ID and connect to it, rather than creating a new session every time.

1. Monitor browser hours. Hosted browsers are metered. If you have a long-running agent, make sure it's not idling. Use the usage controls to set a maximum session duration.

Conclusion: Focus on Your Automation, Not Browser Infra

The value of a browser automation API is not the API itself—it's the time you get back. You stop debugging Chromium crashes, stop writing Dockerfiles for browser images, and stop fighting with session state. You write Playwright code, connect to a remote browser, and move on.

Remote Browser gives you a production-grade runtime for Playwright and other browser automation tools. It handles the infrastructure so you can focus on the logic that matters: your AI agent's decision-making, your scraping pipeline's reliability, or your test suite's coverage.

If you're ready to stop managing Playwright infrastructure manually, check out the Remote Browser documentation to get started. For details on session limits and pricing, see the pricing page. And if you're building AI agents specifically, read about remote browsers for AI agents or our guide to remote browser online for a broader overview.