Skip to content

What is browserbay

browserbay is a box that lends out browsers. You ask it for one and get back a DevTools address and a token. What drives the browser is up to you: Playwright, Puppeteer, an AI agent loop, a screenshot service. The box does not know or care what is on the other end, which is what makes it reusable across projects.

your service A ─┐ ┌─ node (anywhere): Chromium, one isolated context per slot
your service B ─┼──▶ relay (one instance) ◀┤
your service C ─┘ auth + scheduling └─ node (another machine, behind NAT, a laptop…)
  • Isolated browsers. Every browser is its own BrowserContext (own cookies, storage, cache) on a shared Chromium. A client sees its own pages and nothing else on that Chromium. This is tested against real Chromium, including attempts to reach another slot.
  • Deploys anywhere. docker run it on a VPS, a container platform, a Raspberry Pi. Nodes only ever connect out to the relay, so a node can sit behind NAT, and no DevTools port is open anywhere.
  • Scales by adding nodes. Start with one container. Add capacity by running more nodes, wherever you like.
  • Hard to leak. Three separate secrets, a leased lifetime on every browser so a crashed client does not hold one forever, and a protocol version check between relay and nodes.
  • Clients for Node, Python and Go. Anything else can use the small HTTP API.
  • Runs on Kubernetes. A Helm chart runs one relay and nodes that scale on their own.
  • Live view. A person can watch a browser and click and type in it while your service is away, then your service picks up where they left off. See Live view.

browserbay gives you the browser and nothing on top of it. There is no agent loop, no model call, no crawler and no screenshot API. If you want those, build them on the DevTools address the box hands you.