Website Cloud: The Runtime Layer for AI Browser Agents

A website cloud is a hosted browser runtime that lets code and AI agents drive real websites without running Chrome on your own machine or CI box. Instead of installing Chromium, managing display servers, and babysitting zombie processes, you request a session from an API, connect to it over the Chrome DevTools Protocol (CDP), and let the provider handle the browser lifecycle. For teams building AI browser agents, the website cloud is the piece that turns a local prototype into something that runs in production.

This guide covers what a website cloud actually provides, how it differs from a local Playwright setup, how to connect an agent to a hosted session, and the criteria that separate a runtime you can ship on from one that falls over at concurrency.

What a website cloud actually is

The term is loose, so pin it down. A website cloud is not a website builder or a CDN. It is browser infrastructure delivered as a service: real Chromium instances running on remote servers, reachable over a network protocol, with the surrounding plumbing — session isolation, persistent profiles, proxies, live viewing, and usage metering — handled for you.

The core components are consistent across providers:

• Hosted Chromium sessions. Each session is a real browser process, not a headless shim. You get a CDP endpoint you can attach Playwright, Puppeteer, Selenium, or a browser-use style agent to.
• CDP access. The Chrome DevTools Protocol is the control plane. Anything that speaks CDP — including most agent frameworks — can drive the session. See the Chrome DevTools Protocol documentation for the underlying model.
• Session isolation. One agent's cookies, storage, and tabs should not leak into another's. Isolation is what makes concurrency safe.
• Persistent profiles. Saved logins and storage state that survive across sessions, so an agent does not re-authenticate on every run.
• Configurable browser settings. Proxy routing, timezone, locale, and other environment knobs you can set per session.
• A live viewer. A way to watch a session in real time for debugging, which matters enormously when an agent fails on step 14 of a 20-step task.
• Usage controls. Metering and limits so you know what a workload costs before it runs away.

If you have read our remote browser guide for AI agents, this is the same layer viewed from the website-automation angle: the website cloud is the substrate, and the agent is the workload on top.

Why agents need a website cloud instead of local Chrome

Running Playwright locally works fine for a test suite that runs once on a developer laptop. It breaks down the moment you have many agents, long-running tasks, or untrusted web content.

The practical problems with local browser automation at scale:

1. Resource contention. Each Chromium instance is memory-hungry. Ten parallel agents on one machine will thrash. A website cloud lets you request sessions independently of your own hardware.
2. Environment drift. Browser versions, fonts, and OS libraries differ between your laptop and your server. Hosted Chromium gives you a consistent target.
3. State management. Persistent logins, cookies, and storage are painful to manage across ephemeral CI workers. Profiles as a service solve this.
4. Debugging blind spots. When an agent fails remotely, you need to see what it saw. A live viewer and session recordings are not nice-to-haves; they are how you fix failures.
5. Network identity. Some sites behave differently based on IP and geography. Configurable proxy settings let you control that deliberately rather than hoping.

None of this is exotic. It is the same set of concerns that pushed CI systems and test infrastructure to hosted runners years ago. Browser agents are just the latest workload to hit the wall.

How a website cloud fits an AI browser agent stack

An AI browser agent is a loop: observe the page, decide on an action, execute it, repeat. The website cloud owns the "observe" and "execute" halves by providing a real browser the agent can read from and act on.

The division of responsibility looks like this:

This split is why the website cloud is useful rather than promotional: it removes an entire category of operational work from your team without changing how the agent is written. Your agent still speaks CDP or Playwright; it just points at a different endpoint.

Connecting Playwright to a hosted session over CDP

The most common integration is Playwright's connectOverCDP. You request a session from the provider's API, get back a WebSocket endpoint, and attach. The agent code does not need to know the browser is remote.

import { chromium, Browser, Page } from "playwright";

interface SessionInfo {
  cdpUrl: string;
  sessionId: string;
}

// Request a hosted session from your provider's API.
// Endpoint shape varies by provider; this is illustrative.
async function createSession(): Promise<SessionInfo> {
  const res = await fetch("https://api.example-browser-cloud.dev/sessions", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      Authorization: `Bearer ${process.env.BROWSER_API_KEY}`,
    },
    body: JSON.stringify({
      // Configurable browser settings, not guarantees:
      proxy: "residential-us",
      timezone: "America/New_York",
      locale: "en-US",
    }),
  });
  if (!res.ok) throw new Error(`session create failed: ${res.status}`);
  return res.json();
}

async function runAgentTask(url: string) {
  const { cdpUrl, sessionId } = await createSession();
  let browser: Browser | undefined;

  try {
    browser = await chromium.connectOverCDP(cdpUrl);
    const context = browser.contexts()[0] ?? (await browser.newContext());
    const page: Page = context.pages()[0] ?? (await context.newPage());

    await page.goto(url, { waitUntil: "domcontentloaded" });

    // Hand the page to your agent loop. The agent reads the DOM,
    // decides an action, and calls page.click / page.fill / etc.
    const title = await page.title();
    console.log(`session ${sessionId} loaded: ${title}`);

    // ... agent loop here ...
  } finally {
    // Always release the session; metered runtimes bill by time.
    await browser?.close();
  }
}

runAgentTask("https://example.com").catch(console.error);

A few things worth noting in that snippet:

• `connectOverCDP` returns a `Browser`, and you work with its contexts and pages. You do not call launch().
• The `finally` block matters. Hosted sessions are metered. Leaking sessions is the most common way teams accidentally overspend. See /pricing for how metering works on Remote Browser.
• Configurable settings are passed at session creation, not at connect time. Proxy, timezone, and locale are properties of the session, not the CDP connection.

For the protocol-level details of attaching to an existing browser, the Playwright `connectOverCDP` docs are the authoritative reference.

Website cloud vs local Playwright: a production comparison

The decision is not "cloud good, local bad." It is about which trade-offs fit your workload.

Local wins on cost for small, deterministic test suites and on latency for tight loops. The website cloud wins whenever you have concurrency, long-running tasks, untrusted content, or a team that would rather not own browser ops. Most production teams end up with both: local for fast unit tests, hosted for agent workloads.

What to evaluate before you commit

Not every website cloud is built for agent workloads. These are the criteria that actually predict whether a runtime holds up.

Session lifecycle and isolation

Can you create, reuse, and destroy sessions cleanly? Are sessions isolated by default, or do you have to opt in? Isolation failures show up as flaky agents that pass alone and fail under load — the hardest class of bug to diagnose.

CDP fidelity

Some hosted runtimes expose a limited subset of CDP. If your agent relies on specific domains — Network, Runtime, Page, Input — confirm they are available. A runtime that only supports a screenshot-and-click abstraction will not run a Playwright script unchanged.

Persistent profiles

If your agents log into sites, profile persistence is the difference between a working agent and one that hits a login wall every run. Check how profiles are scoped, whether they can be shared across sessions, and how they are cleaned up.

Observability

A live viewer is table stakes. Session recordings, console logs, and network logs are what let you debug a failure after the fact. If you cannot see what the agent saw, you cannot fix it.

Usage controls and cost predictability

Metered runtimes are cheap when used well and expensive when sessions leak. Look for per-session timeouts, concurrency limits you can set, and clear metering. On Remote Browser, current rates and limits are on /pricing.

Network configuration

Proxy support, geo targeting, and header configuration are configurable browser settings, not magic. Understand what you can set and what you cannot. Avoid providers that promise "undetectable" behavior — no runtime can guarantee that, and claims to the contrary are a red flag.

Common integration patterns

Once you have a working CDP connection, a few patterns recur across teams.

One session per task. The simplest and safest model. Create a session, run the task, close it. Good for short, independent workloads.

Session reuse within a workflow. For multi-step tasks that share login state, keep one session open across steps and close it at the end. This reduces auth overhead but requires careful timeout handling.

Profile-backed sessions. Attach a persistent profile so the agent starts already logged in. Useful for recurring tasks against the same site. See /documentation for how profiles are managed on Remote Browser.

Fan-out with a queue. For batch workloads, put tasks on a queue and let workers pull, create a session, run, and release. This is where usage controls and concurrency limits matter most.

Human-in-the-loop. When an agent hits a CAPTCHA or an ambiguous step, hand the live session to a human via the viewer, then resume. This pattern is why live viewing is not optional for production agents.

Where the website cloud fits in the broader stack

It helps to place the website cloud relative to adjacent concepts:

• A cloud browser is the browser instance; a website cloud is the service that delivers those instances with the surrounding infrastructure.
• A remote browser is the access pattern — you drive a browser that is not on your machine. See our remote browser online guide for the practical setup.
• A browser MCP or browser control layer is how an agent framework talks to the browser. The website cloud is what it talks to.
• Playwright and Selenium are client libraries. They do not care whether the browser is local or hosted, as long as the endpoint speaks CDP or the relevant wire protocol.

If you are wiring an agent framework to a hosted runtime, the remote web browser guide covers the connection patterns in more depth, and remote control browser covers the control-plane side.

Bottom line

A website cloud is the runtime layer that lets AI browser agents operate on real sites at production scale without your team owning browser infrastructure. The value is not the browser itself — Chromium is free — it is the session isolation, persistent profiles, observability, network configuration, and usage controls that make concurrency safe and debugging possible.

Evaluate a website cloud on CDP fidelity, session lifecycle, profile handling, and observability before you evaluate price. A cheap runtime that drops CDP domains or leaks sessions will cost more in engineering time than it saves in metering. Start with a single task, connect over CDP, watch the session in the viewer, and confirm the agent behaves the same remotely as it does locally. If it does, you have a runtime you can build on.