Playwright Remote Browser Online: Run Chromium in the Cloud

# Playwright Remote Browser Online: Run Chromium in the Cloud

Running a Playwright remote browser online means your automation code connects to a Chromium instance that lives on someone else's infrastructure instead of your laptop. You keep writing Playwright scripts. You just stop installing browsers, managing versions, and babysitting a headless process on your own machine. This guide covers how the connection actually works, what you gain and give up, and the concrete steps to get a remote session running today.

If you have ever run npx playwright install on a CI runner and watched it pull a large browser bundle before a single test executed, you already understand the appeal. A hosted runtime moves that cost off your machine and onto a service built for it.

What "Playwright Remote Browser Online" Actually Means

Playwright is a browser automation library. It normally launches a browser process locally through its own driver. A remote browser changes one thing: instead of launching Chromium on your machine, Playwright connects to a Chromium instance already running elsewhere, usually over the Chrome DevTools Protocol (CDP).

There are two connection paths in Playwright:

• browserType.launch() — starts a local browser process.
• browserType.connectOverCDP(endpointURL) — attaches to a remote browser that exposes a CDP endpoint.

The second path is what makes a "remote browser online" possible. Your script runs locally (or in your own cloud), but every page, click, and network request executes inside the hosted browser. The Chrome DevTools Protocol is the wire format that carries those commands.

This matters because it decouples two things people usually conflate: the automation logic and the browser runtime. Your logic can live in a serverless function, a container, or your laptop. The browser lives wherever the CDP endpoint is.

Why Teams Move Playwright to a Hosted Runtime

Local Playwright works fine for a single developer running a handful of tests. It gets awkward at scale. The friction shows up in predictable places.

Install and version drift. Every machine and CI runner needs the right browser binaries. playwright install browsers downloads them; keeping those in sync across environments is ongoing work. A hosted runtime removes that step entirely — the browser is already there.

Resource contention. Headless Chromium is memory-hungry. Running ten parallel sessions on a 4 GB CI runner is a recipe for flaky timeouts. Hosted sessions run on infrastructure sized for the job.

Environment reproducibility. A test that passes locally and fails in CI is often a browser-version or OS difference. When both connect to the same hosted Chromium build, that class of failure shrinks.

Access from anywhere. If your automation runs on a remote VM, a serverless function, or a teammate's machine, a hosted browser endpoint is reachable from all of them without exposing your local Chrome.

None of this is free. You trade local control for managed infrastructure, and you need a network round trip to the browser. For latency-sensitive, high-frequency interactions, that round trip is real. For most agent and test workloads, it is negligible compared to page load time.

How the Connection Works: CDP in Practice

The core mechanic is a WebSocket endpoint. A hosted browser exposes something like wss://.../cdp and you point Playwright at it. Here is a minimal TypeScript example using connectOverCDP:

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

async function runOnRemoteBrowser(cdpEndpoint: string): Promise<void> {
  // Attach to a hosted Chromium instance over CDP.
  const browser: Browser = await chromium.connectOverCDP(cdpEndpoint);

  // A remote browser usually starts with one context already open.
  const context = browser.contexts()[0] ?? (await browser.newContext());
  const page: Page = context.pages()[0] ?? (await context.newPage());

  await page.goto('https://example.com', { waitUntil: 'domcontentloaded' });
  const title = await page.title();
  console.log('Remote page title:', title);

  // Close the connection, not necessarily the remote browser.
  await browser.close();
}

runOnRemoteBrowser(process.env.CDP_ENDPOINT!);

A few details that trip people up:

• `connectOverCDP` is Chromium-only. Playwright's CDP connection targets Chromium-based browsers. Firefox and WebKit do not expose a compatible CDP endpoint, so a "remote Firefox over CDP" is not a supported path. If you need cross-browser remote testing, that is a different architecture.
• Contexts may already exist. A hosted browser often comes with a default context and page. Reuse them rather than assuming a blank slate.
• `browser.close()` closes the connection. Whether it tears down the remote browser depends on the provider. Check the session lifecycle semantics before relying on it.

For the full API surface, see the Playwright docs on `browserType.connectOverCDP`.

Local Playwright vs. Playwright Remote Browser Online

The trade-offs are concrete. Here is how the two approaches compare for common production concerns.

The right column is not universally better. If you are debugging a single flaky selector on your laptop, local is faster. If you are running an agent that needs to browse for twenty minutes unattended, hosted wins.

Setting Up a Remote Session

The workflow is short once you have an endpoint.

1. Provision a hosted browser session. Through the Remote Browser API, you request a session and receive a CDP endpoint plus session metadata.
2. Point Playwright at the endpoint. Use connectOverCDP as shown above. No playwright install step is required on the client.
3. Run your automation. Pages, navigation, and network traffic all execute inside the hosted Chromium.
4. Inspect live if needed. A live viewer lets you watch the session in real time — useful when an agent gets stuck.
5. Tear down. Close the connection and release the session so it stops metering.

If you are wiring this into an AI agent rather than a test suite, the same endpoint works. The agent's tool calls become Playwright actions against the remote browser. See Remote Browser for AI agents for that pattern in depth.

Persistent Profiles and Session Isolation

Two features matter for production:

• Persistent profiles let a session keep cookies, local storage, and login state across runs. This is how you avoid re-authenticating on every task.
• Session isolation ensures one session's state does not leak into another. For multi-tenant agents, this is a correctness requirement, not a nicety.

These are configured at session creation, not in your Playwright code. Your script stays the same; the runtime handles the state.

Common Questions About Remote Playwright

Do I need the Playwright browser extension?

No. The "Playwright browser extension" is a common search, but Playwright does not require a browser extension to connect to a remote browser. The connection is CDP over WebSocket. Extensions are a separate concept, sometimes used for recording or debugging, but they are not part of the remote connection path.

Can I still use playwright install browsers?

Yes, for local work. If you run some tests locally and some remotely, keep the local install for the local path. The remote path skips it. If you want to install browsers manually for a specific version, Playwright supports that too — but it is irrelevant to the hosted connection.

What about playwright browser launch options?

Launch options like headless, args, and channel apply when *you* launch the browser. With connectOverCDP, the browser is already running, so launch options are set by the provider at session creation. You influence them through the session configuration API instead. This is a common source of confusion: passing headless: false to connectOverCDP does nothing.

Which browsers are supported?

Playwright supports Chromium, Firefox, and WebKit for local launches. For remote CDP connections, Chromium is the supported target. Hosted runtimes typically offer Chromium builds with configurable settings for proxies and other browser-level options.

Production Criteria Before You Commit

Before moving a workload to a hosted Playwright browser, check these:

• Endpoint stability. Does the CDP endpoint survive long sessions, or does it rotate? Your reconnect logic depends on this.
• Session lifecycle. When does a session end — on browser.close(), on idle timeout, or on an explicit API call? Know the answer before you build retries.
• Profile persistence. If your task needs login state, confirm persistent profiles are available and how they are scoped.
• Network controls. Proxy configuration and configurable browser settings matter for sites that behave differently by region or IP.
• Observability. A live viewer and session logs turn a black-box failure into a debuggable one.
• Cost model. Metered browser time means idle sessions cost money. See /pricing for current rates and plan accordingly.

If you are comparing hosted options more broadly, Remote Browser online covers the category, and Remote web browser walks through the runtime model.

When a Remote Browser Is the Wrong Choice

Be honest about the cases where local wins:

• Sub-100ms interaction loops. The network hop to a remote browser adds latency that matters for tight, high-frequency control loops.
• Offline or air-gapped environments. If you cannot reach an external endpoint, you cannot use a hosted browser.
• Heavy local debugging. Stepping through a script with a local headed browser is still the fastest way to fix a broken selector.

For everything else — agents that run unattended, test suites that need parallelism, automation that must run from multiple environments — the hosted model removes real operational work.

Getting Started

The fastest path is to provision a session, grab the CDP endpoint, and run the connectOverCDP snippet above. No browser download, no version pinning, no local Chromium process. Your Playwright code is unchanged; only the connection target moves.

Start with the documentation for the session API and endpoint format, then wire it into your existing Playwright or agent code. If you are migrating a test suite, run one spec against the remote endpoint first and compare timing before you move the whole suite. That single comparison will tell you more than any benchmark table.