← Blog

BLOG

Install Browser-Use: Run AI Agents with a Hosted Cloud Browser

Learn how to install browser-use and connect it to Remote Browser's hosted cloud browser for scalable, stealth AI agent automation.

July 28, 20266 min readRemote Browser

Why Install Browser-Use with a Hosted Browser?

To install browser-use is the first step toward giving AI agents web navigation abilities. This open‑source framework lets LLMs drive a browser in a structured way. With over 78,000 GitHub stars, it's the most popular tool for building web‑capable AI agents.

But installing browser-use alone isn't enough. Reliable, scalable, and stealthy agent behavior requires a proper browser runtime. A local Chromium instance works for demos, but production agents quickly run into problems:

  • Infrastructure overhead – managing Chrome versions, system dependencies, and concurrent sessions.
  • Resource limits – each local browser consumes CPU/RAM, capping the number of agents you can run.
  • Detection risk – many sites block traffic from headless Chrome or known datacenter IPs.
  • Session fragility – if your agent crashes, the browser state is lost.

Remote Browser solves these issues by providing a hosted, managed Chromium runtime that integrates seamlessly with browser-use. Instead of running a browser on your laptop or server, you connect your agent to a cloud browser via CDP (Chrome DevTools Protocol). You get session isolation, persistent profiles, configurable proxy and stealth settings, and pay‑as‑you‑go pricing – without managing a single browser binary.

In this guide, you'll learn how to install browser-use, set up your Remote Browser API key, and configure your first agent to use a hosted cloud browser.

---

Step 1: Install Browser-Use

Installing browser-use is straightforward with pip. Open your terminal and run:

pip install browser-use

This installs the core library along with its dependencies, including Playwright. By default, browser-use expects a local Chromium installation (you can run playwright install to download one). However, we'll override that to connect to a remote browser instance.

---

Step 2: Get Your Remote Browser API Key

To connect to a Remote Browser cloud instance, you need an API key and the CDP endpoint URL.

  1. Visit remote-browser.dev/pricing to sign up for a free tier or choose a plan.
  2. After creating an account, generate an API key from the dashboard.
  3. Your CDP endpoint will look like: wss://remote-browser.dev/connect?token=YOUR_API_KEY

Full instructions are available in the Remote Browser documentation. No separate browser installation is required – Remote Browser spins up a fresh Chromium session for each request, isolated and ready to accept CDP commands.

---

Step 3: Configure Browser-Use to Use a Remote Browser

The easiest way to point browser-use to a remote Chromium is to use its custom browser feature. You specify a CDP endpoint when initializing the agent.

Below is an example in Python:

from browser_use import Agent
from browser_use.browser.browser import BrowserConfig, Browser

# Create a browser configuration that connects to Remote Browser
browser_config = BrowserConfig(
    cdp_url="wss://remote-browser.dev/connect?token=YOUR_API_KEY",
    # Optional: set a persistent profile to reuse cookies/localStorage
    # profile_dir="persistent_profile_123",
    # Optional: configure proxy/stealth settings via Remote Browser's API
    # extra_kwargs={"proxy": "http://user:pass@proxy.example.com:8080"}
)

browser = Browser(config=browser_config)

agent = Agent(
    task="Go to amazon.com, search for 'mechanical keyboard', and report the top 3 results.",
    browser=browser,
    llm=...,  # your LLM instance
)
await agent.run()

The cdp_url parameter replaces the local Chromium with a hosted session from Remote Browser. Under the hood, browser-use uses Playwright's connect_over_cdp method.

Under the Hood: Playwright CDP Connection

If you prefer to work directly with Playwright (e.g., in a TypeScript/Node.js project), the CDP connection looks like this:

import { chromium } from 'playwright';

const browser = await chromium.connectOverCDP(
  'wss://remote-browser.dev/connect?token=YOUR_API_KEY'
);
const page = await browser.newPage();
await page.goto('https://example.com');
// ... your automation logic
await browser.close();

This is exactly what browser-use does internally. The key takeaway: any CDP‑compatible client – Playwright, Puppeteer, Selenium, or browser-use – can drive a Remote Browser session.

---

Step 4: Run Your Agent at Scale

With the configuration above, your agent now uses a cloud browser. Each session is isolated, so you can run multiple agents simultaneously without worrying about resource contention. Remote Browser handles session lifecycle, so you don't need to worry about zombie processes or memory leaks.

The real benefit becomes apparent when you need:

  • Persistent profiles – save cookies, localStorage, and session data across runs (great for logged‑in agents).
  • Stealth settings – Remote Browser lets you configure user‑agent, viewport, geolocation, and proxy settings to avoid bot detection. No need to patch Playwright.
  • Live viewer – watch your agent's browser in real time for debugging.
  • Usage controls – set concurrency limits, timeouts, and budget caps per API key.

---

Comparison: Local Chromium vs. Remote Browser

AspectLocal Chromium (browser-use)Remote Browser (hosted cloud browser)
SetupInstall Playwright, manage Chrome versionsZero infrastructure – just an API key
ConcurrencyLimited by your machine's RAM/CPUScalable to many sessions
Session persistenceManual – must save state to diskBuilt‑in persistent profiles
Stealth / anti‑detectionRequires custom patches or third‑party libsConfigurable proxy, viewport, and user‑agent
CostFree (your own compute)Pay per browser hour – no subscription needed
ReliabilitySingle point of failureRedundant cloud infrastructure
DebuggingLimited to local logsLive viewer and session replay

For production AI agents that must handle real websites reliably, the hosted route wins on almost every dimension.

---

Tips for Production Browser-Use Workloads

  • Persistent profiles – Use Remote Browser's profile IDs to maintain login sessions across agent runs. This avoids repeated CAPTCHAs or login flows.
  • Rotating proxies – Combine Remote Browser's proxy settings with a proxy provider to distribute requests across different IPs.
  • Heartbeat and timeout – Set reasonable timeouts in your agent code. Remote Browser sessions automatically expire after a period of inactivity (configurable in the dashboard).
  • Monitor usage – Keep an eye on active session counts and costs via the Remote Browser web UI or API.
  • Error handling – Implement retries in your agent logic to handle transient CDP disconnections gracefully.

---

Troubleshooting Common Issues

  • Connection refused – Verify your API key is correct and the CDP endpoint is reachable. Check if your firewall allows WebSocket connections to wss://remote-browser.dev.
  • Session limit exceeded – Reduce concurrency or upgrade your plan. You can view active sessions in the dashboard.
  • Browser version mismatch – Remote Browser uses the latest stable Chromium. Ensure your browser-use and Playwright versions are up‑to‑date.
  • CAPTCHAs appearing – Enable stealth features (custom user-agent, viewport, and proxy) in Remote Browser settings.

---

Get Started Today

Installing browser-use is trivial. The hard part – running dependable browsers at scale – is solved by Remote Browser. Head over to the documentation for advanced configuration (like custom launch args, proxy, and stealth options), or check pricing to see how affordable hosted browsers can be (competitive per‑hour pricing, no subscription required).

If you're already running browser-use locally, switching to a hosted cloud browser takes less than five minutes. Your agents will thank you.

For more context on why AI agents benefit from a dedicated browser runtime, read our earlier post: Remote browsers for AI agents: the missing runtime layer.

*External reference:* Connect to Browser via CDP – Playwright Docs