Hosted Browsers: The Production Runtime for AI Agents and Automation

# Hosted Browsers: The Production Runtime for AI Agents and Automation

Running browser automation locally works until it doesn't. Your laptop sleeps, the network drops, or the session state vanishes mid-task. Hosted browsers solve this by moving the entire Chromium runtime into the cloud, giving AI agents and test harnesses a persistent, reachable, and scalable execution environment. This post explains what hosted browsers are, why they matter for production workloads, and how to connect to them using standard protocols like CDP and Playwright.

What Are Hosted Browsers?

A hosted browser is a full Chromium instance running on remote infrastructure, exposed via an API. Instead of launching a browser on your local machine, you request a session from a service like Remote Browser. The service provisions a dedicated browser instance, returns a connection endpoint, and keeps it alive until you explicitly close it.

This model is fundamentally different from server-side rendering or headless scraping libraries. You get a real browser engine with JavaScript execution, DOM rendering, and network access. The difference is where that engine runs and how you control it.

For AI agents, hosted browsers are the missing runtime layer. An agent needs to navigate, click, fill forms, and extract data. If that browser lives in the cloud, the agent can run anywhere—a serverless function, a Kubernetes pod, or a CI pipeline—without worrying about local browser dependencies.

Why Local Browsers Fail in Production

Local browser automation has three structural problems:

1. State volatility. A browser session tied to a local process dies when the process dies. If your agent crashes or the machine reboots, you lose cookies, local storage, and navigation history.
2. Resource contention. Chromium is memory-hungry. Running multiple concurrent sessions on a developer laptop or a small CI runner causes OOM kills and flaky tests.
3. Network restrictions. Corporate networks, VPNs, and geo-blocking interfere with browser automation. A hosted browser with configurable proxy settings can route traffic through a clean IP.

These issues are manageable for a single script. They become critical when you scale to dozens of concurrent agents or run a 24/7 monitoring workload.

How Hosted Browsers Work

Remote Browser exposes a straightforward API. You create a session, receive a WebSocket endpoint, and connect using your preferred automation library.

The core flow:

1. Create a session. Call the API to provision a new browser instance.
2. Connect via CDP. The response includes a WebSocket URL for the Chrome DevTools Protocol.
3. Drive the browser. Use Playwright, Puppeteer, or raw CDP commands to control the page.
4. Persist or discard. Keep the session alive for hours or days, or close it when done.

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

import { chromium } from 'playwright-core';

async function connectToHostedBrowser() {
  // 1. Create a session via the Remote Browser API
  const response = await fetch('https://api.remote-browser.dev/v1/sessions', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${process.env.REMOTE_BROWSER_API_KEY}`,
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({
      // Persistent profile keeps cookies and storage across connections
      profileId: 'my-agent-profile',
      // Configure proxy or other browser settings as needed
      proxy: { enabled: true }
    })
  });

  const session = await response.json();
  // session.connectUrl contains the CDP WebSocket endpoint

  // 2. Connect Playwright to the hosted browser
  const browser = await chromium.connectOverCDP(session.connectUrl);
  const context = browser.contexts()[0];
  const page = await context.newPage();

  // 3. Run your automation
  await page.goto('https://example.com');
  const title = await page.title();
  console.log(`Page title: ${title}`);

  // 4. Keep the session alive for reuse, or close it
  // await browser.close();
}

connectToHostedBrowser();

The connectOverCDP method is the key. It tells Playwright to attach to an existing browser rather than launching a new one. This is the same mechanism used for Chrome DevTools remote debugging, but pointed at a cloud instance.

Key Features of a Production Hosted Browser

Not all hosted browser services are equal. Here's what to look for when evaluating options:

The comparison table above highlights the production criteria. A hosted browser for AI agents needs persistent profiles because agents often require logged-in states. Live debugging is essential for troubleshooting agent failures. CDP compatibility ensures you aren't locked into a proprietary API.

Hosted Browsers vs. Browser Automation APIs

There's a distinction between a hosted browser and a browser automation API. Some services offer a high-level API that abstracts away the browser entirely—you send a URL, get back HTML. Others, like Remote Browser, give you direct access to a real browser instance.

The trade-off is control versus convenience:

• High-level APIs are simpler but limited. You can't easily handle complex interactions, multi-step flows, or dynamic content that requires waiting for network requests.
• Hosted browsers give you full control. You can execute JavaScript, intercept network requests, and manipulate the DOM. This is necessary for AI agents that need to reason about page structure.

For AI agents, the hosted browser approach is usually the right call. Agents need to see the page, make decisions, and act. A high-level API that returns static HTML strips away the interactivity that makes browser automation powerful.

How to Keep Browser Sessions Alive Across Multiple Cloud Workers

One of the most common questions about hosted browsers is session persistence. If you're running an AI agent across multiple serverless functions or cloud workers, you need the browser session to survive between invocations.

The answer is to decouple the browser from the worker. With a hosted browser, the session lives in the cloud. Each worker connects to the same session via CDP, performs its portion of the task, and disconnects. The browser state—cookies, DOM, navigation history—persists.

Here's a practical pattern:

1. Create a session once with a persistent profile.
2. Store the session ID in a shared store (Redis, DynamoDB, etc.).
3. Each worker connects to the session using the stored ID.
4. The session stays alive until explicitly closed or a timeout is reached.

This pattern works because the hosted browser is independent of any single worker. It's infrastructure, not a process tied to a specific machine.

Playwright Remote Browser: Connecting to Hosted Chromium

Playwright is the most popular automation library for AI agents, and it works seamlessly with hosted browsers. The connectOverCDP method is the bridge.

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

Once connected, you use the standard Playwright API. The only difference is that the browser isn't local. This means:

• No browser installation required on your machine or CI runner.
• Consistent environment across all executions.
• Scalable concurrency without local resource limits.

For teams running Playwright test suites, hosted browsers eliminate the flakiness caused by local browser versions and resource contention. You get a clean, isolated browser for each test run.

Chrome Remote Desktop Typing Fix and Other Browser Quirks

When moving from local to hosted browsers, you'll encounter quirks that don't exist in a local setup. One common issue is typing speed and input events. In some remote browser configurations, keystrokes can be dropped or delayed.

This is often caused by the CDP connection latency. The fix is to use Playwright's built-in input methods (page.type() or page.fill()) rather than raw CDP Input.dispatchKeyEvent calls. Playwright handles the timing and retries automatically.

Another quirk is viewport size. A hosted browser might have a different default viewport than your local Chrome. Always set the viewport explicitly:

await page.setViewportSize({ width: 1280, height: 720 });

These small adjustments make the difference between a flaky hosted browser setup and a reliable one.

Browser Automation with Selenium and Puppeteer

While Playwright is popular, hosted browsers also work with Selenium and Puppeteer. The key is CDP compatibility.

• Puppeteer connects via puppeteer.connect({ browserWSEndpoint }).
• Selenium uses the WebDriver BiDi protocol, which some hosted browser services support.

Remote Browser focuses on CDP, which covers Playwright and Puppeteer. For Selenium, check if the service supports WebDriver BiDi or provides a Selenium-compatible endpoint.

Virtual Browser API Integration

A hosted browser service is essentially a virtual browser API. You integrate it into your application the same way you'd integrate any external API:

1. Authenticate with an API key.
2. Create resources (browser sessions).
3. Interact via WebSocket or HTTP endpoints.
4. Monitor usage and session status.

The integration pattern is straightforward. The challenge is choosing the right abstraction level. Do you want to manage sessions directly, or do you want a higher-level orchestration layer?

For most teams, direct session management is the right starting point. It gives you full control and avoids vendor lock-in. You can always build an abstraction layer on top later.

How to Give Your AI Agent Browser Access in Production

Giving an AI agent browser access in production requires more than just a browser instance. You need:

1. Reliable connectivity. The agent must be able to reach the browser at any time.
2. Session persistence. The agent's state must survive across retries and restarts.
3. Observability. You need to see what the agent is doing to debug failures.
4. Security. The browser must be isolated from other workloads.

A hosted browser service addresses all four. The browser is always reachable via a stable endpoint. Persistent profiles maintain state. Live viewing gives you real-time visibility. Session isolation prevents cross-contamination.

The alternative—running your own browser farm—requires significant infrastructure expertise. You'd need to manage Chromium processes, handle networking, implement session persistence, and build observability tooling. For most teams, this is a distraction from the core product.

Pricing Considerations for Hosted Browsers

Pricing for hosted browsers varies widely. Some services charge per browser-hour, others per API call, and others use a subscription model. The right choice depends on your workload:

• Per browser-hour is predictable for long-running sessions.
• Per API call is better for short, bursty workloads.
• Subscription makes sense for continuous usage.

Remote Browser uses a browser-hour model. This aligns with the actual resource consumption—you pay for the time the browser is running, not for the number of actions you perform. For detailed pricing, check the pricing page.

When evaluating pricing, consider the total cost of ownership. A cheaper per-hour rate might be offset by higher integration costs or less reliable infrastructure. Factor in engineering time, debugging time, and infrastructure maintenance.

Hosted Browsers for Testing and QA

Beyond AI agents, hosted browsers are valuable for testing and QA. Teams use them for:

• Cross-browser testing without maintaining a device lab.
• CI/CD integration with consistent browser versions.
• Load testing with many concurrent browser sessions.
• Visual regression testing with consistent rendering environments.

The key advantage is consistency. Every test run uses the same browser version, the same viewport, and the same network conditions. This eliminates the "works on my machine" problem.

Security and Compliance

Hosted browsers raise security considerations. Your automation code runs in a cloud environment, and the browser has access to whatever websites you visit. Key concerns:

• Data privacy. Ensure the service provider doesn't log or inspect your traffic.
• Session isolation. Verify that your sessions are isolated from other customers.
• Network security. Use HTTPS for all API communication.
• Credential management. Store API keys securely, not in code.

Remote Browser provides session isolation and configurable browser settings to address these concerns. For compliance-sensitive workloads, you can route traffic through your own proxy infrastructure.

Getting Started with Hosted Browsers

The fastest way to evaluate hosted browsers is to run a simple test. Create a session, connect with Playwright, and navigate to a website. This takes less than five minutes and gives you a feel for the latency and reliability.

Here's a checklist for your evaluation:

1. Session creation latency. How long from API call to ready-to-use browser?
2. Connection stability. Does the CDP connection drop under load?
3. State persistence. Do cookies and localStorage survive reconnects?
4. Debugging experience. Can you see what the browser is doing?
5. Pricing transparency. Are there hidden costs for bandwidth or storage?

For a deeper dive into the architecture, read our post on remote browsers for AI agents. If you're specifically interested in the online access model, see remote browser online.

Conclusion

Hosted browsers are the production runtime for AI agents and browser automation. They solve the fundamental problems of local browsers—state volatility, resource contention, and network restrictions—by moving the browser to the cloud and exposing it via standard protocols.

The key features to look for are persistent profiles, CDP compatibility, live debugging, and session isolation. These determine whether the service can handle real workloads or just demos.

Remote Browser provides all of these features with a straightforward API. Whether you're building an AI agent, running Playwright tests, or automating a complex workflow, hosted browsers give you a reliable foundation.

Start with a simple session, test the connection, and see how it handles your workload. The transition from local to hosted is easier than you think, and the reliability gains are immediate. For more details on the API and capabilities, check the documentation or explore the remote web browser guide.

For the technical foundation, refer to the Chrome DevTools Protocol documentation to understand the underlying protocol that makes hosted browser connections possible.