BrowserCat
Dashboard →

How BrowserCat Works

BrowserCat is a router for browser infrastructure. You connect to one endpoint with one API key, and we route each session to the browser backend best suited for the job, then pipe the browser straight back to your code.

Think of it like an OpenRouter for browsers: you describe what you need, and we pick a backend that can deliver it. You never connect to a provider directly, so you’re never locked into one.

This page explains, in plain English, how a session flows through BrowserCat and which backends sit behind the router today and tomorrow.

The flow, end to end

Your code always connects to the same place: wss://api.browsercat.com/connect. Everything else happens behind it.

  your code
     │  wss://api.browsercat.com/connect   (unchanged)
     ▼
┌─────────────────────────────────────────────┐
│                 BrowserCat                   │
│   1. authenticate your API key               │
│   2. meter the session for billing           │
│   3. route by capability / cost / region /   │
│      failover                                 │
└─────────────────────────────────────────────┘
     │  opens a CDP socket to the chosen backend
     ▼
┌──────────────┬──────────────┬───────────────┐
│  Cloudflare  │    Steel     │   roadmap...   │
│  (live)      │   (landing)  │  (planned)     │
└──────────────┴──────────────┴───────────────┘
     │
     ▼
  frames piped back to your code

Step by step:

  1. You connect. Your Playwright, Puppeteer, or raw CDP client opens a websocket to /connect, exactly as it always has.
  2. We authenticate and meter. BrowserCat verifies your API key and starts metering the session so we can bill you the minimum possible amount.
  3. We route. The router chooses a backend based on what the session needs: the capabilities you’ve requested, plus cost, region, and which backends are currently healthy.
  4. We open a CDP socket to the chosen backend and pipe frames back and forth. To your script, it’s just a browser. You launch tabs, click, scrape, screenshot, and so on, none the wiser about which backend is doing the work.

The key idea: the /connect endpoint never changes. As we add backends and capabilities, your code keeps working untouched.

The backends

Each backend is good at different things. The router’s job is to match your session to the right one. Here’s the current lineup.

Cloudflare — live ✅

Every /connect session today is proxied to Cloudflare Browser Rendering: headless Chromium running on Cloudflare’s global edge.

  • Capabilities: headless Chromium, served from close to your request for low latency worldwide, with predictable spin-up and no cold-start surprises.
  • Pricing: $0.09 per browser-hour, pay only for what you use.
  • Status: Live. This is the default for the vast majority of jobs, scraping, screenshots, PDFs, e2e tests, and giving LLMs a real browser.

Steel — landing 🟡

Steel is joining as our second backend for sessions that need something Cloudflare can’t do today.

  • Capabilities (landing): bring-your-own proxy, route a session’s traffic through your own proxy provider for geo-targeting, residential IPs, or bandwidth control.
  • Capabilities (later): heavier anti-bot work such as stealth and CAPTCHA handling, brought online thoughtfully rather than promised before it’s solid.
  • Status: Landing. The router sends a session to Steel when it requests a capability Steel provides.

Own fleet — planned ⏭

A fleet we run ourselves, for the cases third parties don’t cover well yet.

  • Capabilities (planned): Firefox and WebKit, headed browsers, and custom launch flags, the jobs that need a specific engine or a specific tweak we want to guarantee with a backend we fully control.
  • Status: Planned. No dates, just direction.

Lightpanda — planned ⏭

A backend focused on speed.

  • Capabilities (planned): ultra-fast cold-starts, for when you want a browser available almost instantly and don’t need a full Chromium for the task.
  • Status: Planned.

Browserbase — planned ⏭

Another high-quality backend for the router to lean on.

  • Capabilities (planned): a premium and failover option, giving the router more room to route around trouble or reach for extra muscle when it’s the right call.
  • Status: Planned.

No lock-in, with failover built in

Because every session flows through one router, two things come for free:

  • No vendor lock-in. You authenticate with BrowserCat, not with any single provider. You’re not betting your codebase on one vendor’s roadmap or pricing page. If the landscape shifts, the router shifts with it, and your code doesn’t change.
  • Automatic failover. When a provider has a bad day, the router can route around it to a healthy backend. Your job doesn’t have to care which backend is healthy this afternoon, as long as one is.

One API key. One connection. The right browser for every job. That’s BrowserCat.

Want to know exactly what’s live versus on the way? Check the roadmap.

Quick Start
Roadmap