Browser Use Remote Browser GitHub: Run Agents on Hosted Chromium

# Browser Use Remote Browser GitHub: Run Agents on Hosted Chromium

If you searched for browser use remote browser github, you probably want one of two things: the browser-use repository itself, or a way to point a browser-use agent at a remote browser instead of a local Chrome install. This post covers both, then focuses on the part that actually matters in production — connecting an agent to hosted Chromium over CDP so it survives restarts, scales past one machine, and stays debuggable.

The short version: browser-use is the agent framework. A remote browser is the runtime it drives. GitHub gives you the former; you still need somewhere for the browser to live. That is the gap this post fills, with concrete Playwright/CDP wiring and the criteria to evaluate a hosted runtime.

What "browser use remote browser github" actually refers to

Three distinct things get conflated under this query:

1. The browser-use project on GitHub — the open-source Python library that lets an LLM control a browser to complete tasks.
2. Remote browser tooling on GitHub — projects like vercel-labs/agent-browser, a browser automation CLI for AI agents, plus assorted CDP wrappers.
3. Connecting the two — running a browser-use agent against a browser that is not on your laptop.

The first two are code you clone. The third is an infrastructure decision. Most teams hit the same wall: the agent works locally, then fails in CI or on a server because there is no display, no persistent profile, and no way to watch what went wrong.

A hosted runtime solves that by exposing a CDP endpoint you connect to. Your agent code barely changes. What changes is where the browser runs, how sessions persist, and how you observe failures.

Why local Chrome breaks browser-use agents in production

Local Chrome is fine for a demo. It breaks in predictable ways once you run more than a handful of tasks:

• No display on servers. Headless mode works until a site behaves differently without a real rendering context, or until you need to debug visually.
• Profile state is fragile. Cookies, localStorage, and logged-in sessions live in a directory on one machine. Move the workload and the session is gone.
• Concurrency is bounded by the host. Ten parallel agents on one laptop means ten Chrome processes competing for RAM and CPU.
• No shared observability. When an agent fails at step 14, you have logs but no live view and no replayable session.
• IP and network posture are whatever your host has. Sites that gate on geography or datacenter ranges will treat every run the same way.

None of these are browser-use bugs. They are consequences of treating the browser as a local process rather than a service. For a deeper treatment of that shift, see Remote browsers for AI agents: the missing runtime layer.

How browser-use connects to a remote browser

browser-use drives Chromium through CDP (Chrome DevTools Protocol). That is the same protocol Playwright and Puppeteer use. So the integration path is the same one you would use for any CDP-based automation: get a WebSocket endpoint, connect, and let the framework issue commands.

The Chrome DevTools Protocol is the authoritative reference for what those commands do. Playwright's CDP connection docs cover the client side.

In practice you have two connection styles:

For hosted Chromium, connect_over_cdp is the one you want. It assumes the browser already exists and you are a client of it.

A minimal Playwright + CDP connection

This is the shape of the code you write against a hosted runtime. The endpoint comes from your session provisioning call; everything after that is standard Playwright.

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

type Session = {
  cdpUrl: string; // wss://... from your runtime's session API
  sessionId: string;
};

async function runAgentTask(session: Session): Promise<void> {
  let browser: Browser | undefined;

  try {
    // Attach to the hosted Chromium instance over CDP.
    browser = await chromium.connectOverCDP(session.cdpUrl, {
      timeout: 30_000,
    });

    // A hosted session usually exposes one persistent context.
    const context = browser.contexts()[0] ?? (await browser.newContext());
    const page: Page = context.pages()[0] ?? (await context.newPage());

    await page.goto("https://example.com/login", {
      waitUntil: "domcontentloaded",
    });

    await page.fill("#email", process.env.AGENT_USER!);
    await page.fill("#password", process.env.AGENT_PASS!);
    await page.click("button[type=submit]");

    // Wait on a real signal, not a fixed sleep.
    await page.waitForSelector("[data-testid=dashboard]", {
      timeout: 20_000,
    });

    // Hand control to your agent loop here. The page object is
    // the same one browser-use would drive.
  } finally {
    // Disconnect the client. Whether the session is destroyed
    // depends on your runtime's lifecycle settings.
    await browser?.close();
  }
}

Two details matter more than they look:

• `browser.close()` on a CDP connection disconnects the client. It does not necessarily kill the remote browser. Check your runtime's session lifecycle so you do not leak sessions or, conversely, kill one you meant to keep alive.
• Reuse `contexts()[0]` when it exists. Creating a new context on a persistent session can discard the profile state you paid to keep.

If you are wiring this into a browser-use agent rather than raw Playwright, the same endpoint goes into the agent's browser configuration. The framework handles the command loop; you handle the connection URL and lifecycle.

browser-use vs agent-browser: what the GitHub projects actually are

These two names show up together often enough to cause confusion. They are not competitors in the same category.

Both are clients. Neither ships a browser fleet, persistent profiles, or a live viewer. That is the layer underneath, and it is the layer that determines whether your agent works at 3 a.m. when nobody is watching.

If you want the CLI-oriented view of that runtime, Agent-Browser Agent-Browser: CLI, Runtime, and Production Path covers it. For the framework comparison specifically, Agent Browser vs Browser Use: What Actually Differs goes deeper.

Production criteria for a remote browser behind browser-use

Once you accept that the browser is infrastructure, evaluate runtimes on these axes. They are ordered by how often they cause incidents, not by how they look on a pricing page.

1. Session lifecycle and persistence

Can a session outlive a single agent run? If your workflow logs in once and then performs ten actions over an hour, you need a profile that persists across connections. Ask specifically:

• Does the session survive a client disconnect?
• Can you reconnect to the same session ID later?
• What is the maximum session lifetime, and what happens at the boundary?

Persistent profiles are the difference between an agent that re-authenticates every run and one that behaves like a returning user.

2. CDP fidelity

Some hosted browsers expose a restricted CDP surface. If your agent relies on network interception, Page.captureScreenshot, or Runtime.evaluate, confirm those work before you commit. A runtime that only supports navigation and clicking will fail on real tasks.

3. Observability

A live viewer is not a nice-to-have when an agent fails silently. You want to watch the session in real time, and you want a record you can inspect afterward. Without it, debugging a multi-step agent failure means reading a log and guessing.

4. Network and browser configuration

Configurable browser settings — proxy routing, locale, timezone, user agent — matter for sites that behave differently by region. Be precise about what you need and verify it is supported. "Stealth" is a marketing word; the concrete question is which settings you can control and whether they persist for the session.

5. Isolation

Sessions must not share cookies or storage unless you explicitly want them to. Isolation is what lets you run untrusted or parallel workloads on shared infrastructure without cross-contamination.

6. Usage controls

You need to know what a session costs and be able to cap it. Metered browser time with a hard ceiling beats a surprise invoice. Current rates and limits live on the pricing page — check there rather than trusting a number in a blog post.

7. Client compatibility

If it speaks CDP, it should work with Playwright, Puppeteer, and Selenium. That compatibility is what keeps you from rewriting your automation when you change runtimes.

A practical migration path

You do not have to rewrite your agent to move it off local Chrome. The sequence that works:

1. Run locally first. Get the browser-use task passing on your machine. Confirm the agent logic is correct before changing infrastructure.
2. Extract the connection. Replace the local launch call with a connect_over_cdp call against a configurable endpoint. Keep everything else identical.
3. Provision a hosted session. Get a CDP URL from your runtime, run the same task, and compare behavior. Differences here are usually about profile state or network, not the agent.
4. Add persistence. Once the task passes, decide which sessions should persist and which should be ephemeral. Persist the ones that hold auth; discard the rest.
5. Add observability. Wire the live viewer into your debugging flow before you scale, not after the first production incident.
6. Scale horizontally. Because the browser is remote, adding concurrency is a provisioning question, not a hardware question.

The step people skip is 3. Running the same task against both local and remote browsers surfaces environment assumptions early — timezone, locale, viewport, and network — while the diff is still small.

Common failure modes and what they mean

When a browser-use agent works locally but not remotely, the cause is usually one of these:

• Session expired mid-run. The agent held a reference to a session that was reaped. Check lifetime limits and add reconnection logic.
• Profile not persisted. The agent expected a logged-in state that did not survive. Confirm the session is configured for persistence.
• CDP method unsupported. The agent called something the runtime does not expose. Test the specific methods your agent uses.
• Network egress differs. The site sees a different IP or region and responds differently. This is a configuration question, not a bug.
• Client disconnect treated as session end. Your finally block closed the browser when you meant to keep it. Separate disconnect from destroy in your code.

Each of these is diagnosable in minutes with a live viewer and reproducible in a test harness. Without them, each one is an afternoon.

Where Remote Browser fits

Remote Browser is a browser API and runtime for AI agents and browser-use workflows. It provides hosted Chromium sessions with CDP access, compatibility with Playwright, Puppeteer, and Selenium, a live viewer, persistent profiles, configurable browser and proxy settings, session isolation, and usage controls.

It is not a replacement for browser-use. It is the layer browser-use connects to when the browser needs to outlive your laptop. If you are evaluating the broader category, Remote Browser: The Hosted Runtime for AI Agents and Automation covers the architecture, and Remote Browser Online: Run Real Chromium Without Managing Chrome covers the zero-install path.

Start with the documentation to get a CDP endpoint and run the connection snippet above. If you are still deciding whether hosted is worth it, run your hardest browser-use task against both a local Chrome and a remote session and compare the failure modes. That comparison will tell you more than any benchmark table.

Summary

• The browser use remote browser github query mixes three things: the browser-use library, remote browser CLIs, and the connection between them.
• browser-use and agent-browser are both CDP clients. Neither provides a hosted browser.
• Connecting to a remote browser means connect_over_cdp with a WebSocket endpoint. Your agent code barely changes.
• Production evaluation comes down to session lifecycle, CDP fidelity, observability, network configuration, isolation, and usage controls.
• Migrate incrementally: local first, then extract the connection, then add persistence and observability before scaling.
• Most "it works locally but not remotely" failures trace to session lifetime, profile persistence, or unsupported CDP methods — all diagnosable with a live viewer.