browser-gateway
The open router for cloud browsers.
One endpoint that routes across every browser provider you use: automatic failover, persistent profiles, session replay, REST API, MCP server, dashboard.
Works unchanged with Puppeteer, Playwright, Stagehand, browser-use, and any MCP client.
Â
Â
Â
Website
 ·Â
Quick start
 ·Â
MCP
 ·Â
Profiles
 ·Â
Replays
 ·Â
REST API
 ·Â
Dashboard
 ·Â
Discord
Overview
One endpoint. Multiple providers. Automatic failover when one is saturated or goes down.
Your app connects to ws://gateway:9500/v1/connect. The gateway picks the best available provider based on health, capacity, and your routing strategy. Providers can be cloud CDP services, Docker containers, or local Chrome instances.
Dashboard
A web dashboard ships with every install. Open http://localhost:9500/web after starting the gateway.
Overview. Active sessions, queue depth, provider health, connection endpoint, and a copy-paste quickstart for Puppeteer, Playwright, Stagehand, browser-use, and raw CDP.
REST API. Run screenshot, content extraction, and structured scraping endpoints from a form-driven UI, with profile selection and parameter reference inline.
Playground. Drive any provider live from the browser. Pick a provider and profile, type into the canvas as if it were a local browser, and watch the remote session in real time.
Features
Routing & reliability
- Automatic failover - the next provider takes over the instant one fails, no client changes
- Five load-balancing strategies - priority chain, round-robin, least-connections, latency-optimized, weighted
- Per-provider concurrency limits - the gateway enforces
maxConcurrent on every backend
- Request queue - connections wait when every provider is saturated instead of failing immediately
- Cooldown - failing providers are skipped and recover automatically after a TTL
- Health checks - periodic connectivity probes mark providers unhealthy before clients hit them
- Graceful shutdown - active sessions drain cleanly on SIGTERM and SIGINT
- Session reconnect - a dropped client reconnects with
?sessionId=<X-Session-Id>; on a provider that issues a resume token (browserserve with its resume window on) it gets the same browser back with its pages, cookies and storage, otherwise a new browser on the same provider
- Webhooks - fire on provider down, recover, and queue-overflow events
REST API
- Screenshot -
POST /v1/screenshot returns any URL as PNG or JPEG, full-page or scoped to a selector
- Content extraction -
POST /v1/content returns markdown, plain text, HTML, or a cleaned article
- Scrape -
POST /v1/scrape extracts structured data via CSS selectors or full-page formats
- Pooled sessions - browser connections are reused across requests, like a database pool
- Automatic retry - failed requests retry against a fresh page
Profiles — persistent browser state
- Survive across sessions - cookies and
localStorage are captured as you leave each page and on disconnect, and replayed on the next connect with the same id (IndexedDB too on browserserve)
- Saved on any provider - every provider can load and save any profile; pin a provider to one profile only to route that profile's sessions there
- Profiles never mix - a browser that still holds a different profile is refused. Anything else already in a reused browser (from sessions without a profile) is saved with the profile
- One-line opt-in - add
?profile=acme to the WebSocket URL, the rest is automatic
- Encrypted at rest - AES-256-GCM with envelope encryption, anti-swap binding, and a scrypt-derived KEK
- Provider-agnostic - state is captured at the CDP level, so it replays against any provider
- Per-profile locking - concurrent connects to the same id return HTTP 409 to prevent corruption
- Export and import - encrypted
.bgp blobs are portable between gateway installs
- One-click enable - the dashboard wizard generates a strong key in your browser and writes it to config
See the Profiles docs for the full guide, security model, REST endpoints, and limitations.
Session replay — see what the agent saw
- Frame-accurate visual record of every routed session, captured via CDP
Page.startScreencast
- Zero injection - no script runs inside the customer page, capture is fully out-of-band
- Provider-agnostic - works with any backend that supports page screencast
- Dashboard player - scrub through the recorded frames, switch between captured browser targets
- Retention controls - configurable horizon, per-session byte cap, daily cleanup
See the Replays docs for the storage layout, REST endpoints, and tuning knobs.
MCP server for AI agents
- One-call tools -
fetch_page reads any url as markdown and screenshot_page captures it, each in a single call that opens and closes its own browser
- Session tools -
browser_session, browser_navigate, browser_snapshot, browser_act, browser_extract, browser_screenshot, browser_wait, browser_tabs, browser_evaluate, browser_observe for logins, forms and multi-step work
- Fallback for coding agents - a Claude Code plugin sends Claude to
fetch_page when its built-in web fetch is blocked, empty or needs JavaScript (/plugin marketplace add browser-gateway/browser-gateway); setup for Codex, Cursor and Gemini CLI in plugins/browser-gateway
- Zero config - auto-detects Chrome and launches it on first tool use
- Concurrent sessions - every agent gets its own browser, no shared state
- Raw CDP - no Playwright or Puppeteer dependency
- Compatible - Claude Code, Cursor, and any MCP-compatible client