Browser-Use HTTPS: Run AI Agents on Hosted Chromium

The browser-use HTTPS endpoint is the small detail that decides whether an AI web agent works in production or fails on the first TLS handshake. When you run browser-use locally, the library launches Chromium on localhost and talks to it over plain HTTP. That works in a demo. In a production pipeline—behind a firewall, inside a container, or on a shared CI runner—browser-use needs HTTPS, and a local Chromium process won't give you a secure, routable endpoint.

Remote Browser is a hosted browser API that gives browser-use agents a real Chromium runtime in the cloud, exposed over secure WebSocket (WSS) and CDP. You keep the same Playwright, Puppeteer, or Selenium calls you already write, but you point them at a session that scales, persists, and comes with the TLS handling already solved.

The local browser ceiling

browser-use is a popular open-source library for letting AI agents drive a real browser. The pattern is simple: the agent receives a task, converts it into browser actions, and executes them against a Chromium instance. The library handles navigation, clicking, typing, and extracting content while the LLM decides the next step.

The weak point was never the agent logic. It is the browser underneath.

Running browser-use locally means managing a Chromium binary, keeping it patched, passing the right flags, and exposing a debugging port. That setup is fine for a notebook. For a browser-use cloud browser workload, it breaks down fast:

• Every agent process wants its own browser, which means CPU and memory spikes on the host.
• Headless Chromium needs --disable-dev-shm-usage, --no-sandbox, and a dozen other flags depending on the base image.
• There is no natural HTTPS endpoint. You are stuck with http://localhost:9222.
• If the host dies, the browser session and its cookies die with it.
• There is no standard way to observe what the agent is doing unless you wire up extra tooling.

The open-source project solved the agent loop. It did not attempt to solve browser infrastructure. That is what a hosted browser runtime is for.

What browser-use HTTPS really means

When someone searches for "browser-use https," they usually hit one of three problems:

1. TLS errors in the agent loop. The site under test has a certificate issue, the proxy intercepts traffic, or the CDP connection is being blocked because it uses an insecure transport.
2. Remote debugging over the network. browser-use can connect to an existing Chrome instance over CDP, but exposing localhost:9222 to a container or a remote worker requires an HTTPS tunnel or a reverse proxy.
3. Secure API access. Teams want to call a browser-use API over HTTPS rather than managing a local browser process. They need a hosted endpoint that accepts authenticated requests and returns a live browser session.

All three are infrastructure problems, not agent problems. A browser-use HTTPS solution should give you a secure, authenticated endpoint that a browser-use agent or a raw CDP client can connect to without you building a tunnel.

Remote Browser does exactly that. Each session gets a dedicated Chromium instance, a CDP endpoint, and a live viewer. The connection is delivered over WSS, so TLS is handled at the edge rather than inside your application code.

Remote Browser: a hosted browser API for browser-use

Remote Browser is a browser automation API designed for AI agents, browser-use, and QA workflows. Instead of running Chromium on your machine, you request a hosted session and receive a connection string. Your code—whether it uses the browser-use library, Playwright, Puppeteer, or raw CDP—connects to that session and drives it like a local browser.

Key capabilities:

- **Hosted Chromium sessions** with CDP access over a secure WebSocket.
- **Playwright and Puppeteer compatibility**, so existing scripts run with minimal changes.
- **Live viewer** to watch what the agent is doing in real time.
- **Persistent profiles** for logged-in states and long-running sessions.
- **Session isolation** so agent A cannot read agent B's cookies or storage.
- **Usage controls** to cap session length and resource consumption.

The result is a browser-use cloud browser that behaves like a real browser but lives in infrastructure you do not have to babysit.

## Connecting Playwright to a remote session over CDP

The most common integration pattern is connecting Playwright over CDP to a hosted session. The TypeScript example below uses `chromium.connectOverCDP`, which is the same mechanism browser-use's Playwright-based workflows rely on.

import { chromium } from 'playwright';

// Replace with the WSS endpoint and token from your Remote Browser session. const browser = await chromium.connectOverCDP( 'wss://<your-remote-browser-endpoint>?token=<api-token>' );

// The remote browser already has a default context. const context = browser.contexts()[0] ?? (await browser.newContext()); const page = await context.newPage();

await page.goto('https://example.com', { waitUntil: 'networkidle' }); console.log('Title:', await page.title());

// Keep the session alive for long-running AI agent tasks, or close it. await browser.close();

The same endpoint works with Puppeteer's `connect` and with raw WebSocket CDP clients. If you are using the browser-use Python library, you can point it at the same CDP endpoint instead of letting it spawn a local Chromium process. That is the fastest path from a laptop demo to a browser-use production deployment.

For a deeper look at the agent-runtime layer, read [Remote Browsers for AI Agents: The Missing Runtime Layer](/blog/remote-browser-for-ai-agents).

## Local browser vs. hosted browser for browser-use

The table below summarizes what changes when you move a browser-use workload from a locally managed browser to a hosted browser API.

| Consideration | Local Chromium + browser-use | Remote Browser hosted sessions |
| --- | --- | --- |
| **Setup** | Install browser, patch flags, manage debugging ports | Create a session, use the returned WSS/CDP URL |
| **HTTPS / TLS** | Manual tunnels or insecure localhost | Managed TLS termination on the endpoint |
| **Scaling** | One browser per process on a fixed host | On-demand Chromium sessions in a shared runtime |
| **Persistence** | Manual `user-data-dir` handling | Persistent profiles with isolated storage |
| **Observability** | No built-in view of agent actions | Live viewer and session-level monitoring |
| **Fleet access** | `http://localhost:9222` only | Secure WSS endpoint reachable from any environment |
| **Production controls** | DIY scripts and cron jobs | Usage controls, session isolation, configurable browser settings |

The comparison is not about whether browser-use is good—it is. The question is whether you want to also operate a browser farm, or whether you want a runtime that already solved the hard parts.

## What a hosted browser session API gives you in production

Once browser-use runs against a remote session, several production concerns disappear.

### Secure transport as a default

A remote browser API should never expose plaintext CDP to the public internet. Remote Browser exposes sessions over WSS, which is the standard way to carry CDP traffic over TLS. Your agent talks to the endpoint over HTTPS, and the browser session itself stays inside the runtime. This matters for compliance-minded teams that do not want to bolt TLS onto a local debugging port.

### Persistent profiles without fragile Docker volumes

Long-running agents often need cookies, localStorage, and login state. Locally, you would mount a volume and hope the browser flags align. With a browser session API, the profile is attached to the session. You can request the same profile for a follow-up run, which is useful for agents that check a dashboard every hour.

### Isolation between agents

When multiple browser-use agents run against the same host, they share a kernel, a network namespace, and sometimes a browser binary. A hosted runtime isolates sessions so one agent cannot read another agent's data. This is the difference between a script and a service.

### Configurable browser behavior

Runtime settings like user agent, viewport, locale, and proxy behavior can be applied per session. Instead of maintaining separate browsers for different tasks, you request the configuration you need. See the [documentation](/documentation) for the full list of session options.

### Cost control for agent fleets

AI agents sometimes loop. A stuck agent can keep a browser session alive for hours. Remote Browser supports usage controls so you can cap session duration and stop runaway work. Current pricing and limits are published on the [/pricing](/pricing) page, so you can plan around the real numbers without committing to a subscription.

## browser-use alternatives: why teams move to a runtime

If you are evaluating browser-use alternatives, you are probably comparing agent frameworks, not browser infrastructure. Most alternatives—whether open-source agent libraries or commercial web agent browsers—still need a browser to execute against. The framework chooses the LLM and the action loop; the runtime chooses the browser.

Teams that move from local browser-use to a hosted runtime do so for three reasons:

- **Reliability.** No more "chromium crashed at 3 a.m." incidents.
- **Security.** A WSS endpoint with an API token beats an open debugging port.
- **Throughput.** A browser automation API can spin up many sessions in parallel, while local resource limits cap concurrency quickly.

A web agent browser is only as reliable as the browser behind it. Pinning that browser to a single machine guarantees an upper bound on throughput and uptime.

Related reading: [Remote Control Browser: When Code and Agents Need to Drive the Web](/blog/remote-control-browser) and [Remote Web Browser: The Practical Runtime for Browser Automation](/blog/remote-web-browser) cover adjacent patterns for control-plane and automation use cases.

## Browser-use Playwright: the practical middle ground

Browser-use implements much of its automation on top of Playwright. That is good news for your existing test suite. If you already have Playwright scripts, the same CDP connection works for both human-written tests and AI-driven browser-use workflows. You do not need two browser stacks.

This is the browser-use Playwright pattern in production:

browser-use agent ──> CDP ──> WSS endpoint ──> hosted Chromium Playwright test ───> CDP ──> WSS endpoint ──> hosted Chromium

One runtime, two workloads. The agent gets the same fidelity as your deterministic tests, and the tests get the same infrastructure as the agent.

For the official details on CDP connections in Playwright, refer to the [Playwright connectOverCDP documentation](https://playwright.dev/docs/api/class-browsertype#browser-type-connect-over-cdp). The Chrome DevTools Protocol itself is documented by the [Chromium team](https://chromedevtools.github.io/devtools-protocol/), which is useful if you want to go below the Playwright layer.

## Using a browser-use HTTPS API without changing your agent loop

The fastest migration path is the one that does not touch your agent code at all. If browser-use is currently writing to `http://localhost:9222` or spawning its own Chromium, you change the browser connection details, not the task prompt, not the tool definitions, and not the output parsing.

A hosted browser API should feel like a local browser with better networking. That is the design goal behind Remote Browser: keep the interface identical, change the execution layer.

If you are building a fleet of agents, you also want to avoid the anti-pattern of one long-lived browser per agent. Sessions are cheap to request and dispose when the task is done. The usage controls exist precisely so you can treat browsers as ephemeral resources rather than pets.

## Summary

Browser-use HTTPS is more than a connection detail. It is the dividing line between a demo and a deployed AI workflow. Local Chromium gives you a browser on localhost. A hosted browser API gives you a browser on WSS, with TLS handled, sessions isolated, profiles persisted, and usage controlled.

Remote Browser provides that runtime for browser-use, Playwright, Puppeteer, and Selenium workloads. You bring the agent logic; the runtime provides the browser.

Start with the [documentation](/documentation) to see session configuration, or check [/pricing](/pricing) for the current details on session costs and limits. Then replace your local browser with a session endpoint, and leave the TLS problem behind.