Browser automation that doesn’t guess.

browserscale runs real Chromium browsers in the cloud and rebuilds the parts of the browser that browser automation keeps failing on. You rent an isolated session and drive it from Go or TypeScript — or from a script that runs beside the page in BrowserVM — instead of installing, scaling and babysitting your own browser farm. Waits, clicks, typing, frame handling and a session-wide network log behave correctly rather than approximately.

The three failures every browser bot dies of: the element is inside a cross-origin iframe, the click did not land and nobody knows why, and the wait was a poll racing the page. browserscale moves all three into the engine — a wait is reported by the document the instant it becomes true, a click verifies the pixel it is about to press and names the element that blocked it, and a frame at any depth is reachable without bookkeeping.

A click scrolls the element into view through nested scrollers and frames, waits until its bounds stop moving, moves the pointer there along a human path, and then verifies the exact pixel the way a real mouse event is routed — including across process boundaries, so a page-level modal over a cross-origin iframe is caught. If something covers the point it re-aims at the largest exposed part of the element; failing that it steps clear of the whole overlay once, which collapses hover menus, and re-checks. If it still cannot land it refuses instead of clicking the wrong thing, and returns the intercepting element: tag, id, class, text, bounds, pointer-events, stacking order, whether it is pinned, and whether it swallows clicks while invisible.

There is no polling loop that can race the page. Each document that a condition concerns watches for it itself and pushes a wake-up the moment it starts holding, so a match arrives within a frame or two — including from a frame in its own process, which reports for itself. The default meaning of a condition is visible, reachable and holding still for half a second, not merely present in the DOM, and reachability is decided by the same hit test a click would do. A wait also survives a navigation and re-attaches to the new document.

A per-condition breakdown instead of a bare deadline: for each condition, whether it never appeared, appeared but was hidden, appeared but was covered — with the element that covered it — or was found but still moving when time ran out. Those four cases need four different fixes, which is why they are reported separately.

Yes, and it is the normal way to write a flow here. Pass the success state, the error state, the challenge and the queue page as conditions of one wait; the first to match wins and the result tells you which one it was and in which frame. One call, one deadline, one branch — instead of a nest of short-timeout probes racing each other.

You register a standing reaction: if this ever appears anywhere in the page, click it — or click something beside it, like its close button. The browser carries it out on its own, only while the pointer is idle, so it slots into the gaps of an action that is already retrying. A click blocked by a modal therefore lands, because the reaction dismissed the modal while the click was still working its way in. Reactions are one-shot, watch every frame including frames created later, and survive navigation.

A condition or an action can search one frame or every frame in the page at any depth, same-origin or cross-origin, including frames that appear after the call started. What comes back carries the frame it was found in plus a node handle for the element, so the next action goes to the right place without you switching frames. Inside BrowserVM it goes one step further: a cross-origin child document is reached by reading contentDocument, and an element out of it can be handed straight to a click.

BrowserVM runs your own script inside the browser, in an isolate of its own beside the page rather than in it. Cross-origin frames become property access, values come back as live objects you can assign to, a step into the document costs microseconds instead of a network round trip — so loops are affordable — and nothing is injected into the page. Every command the session has is callable from in there, on the same session, in the same run.

Playwright and Puppeteer drive the browser from outside over the DevTools protocol. browserscale replaces the control plane: commands are carried out by the browser itself, nothing is injected into the page and there is no DevTools handshake on the connection, which removes the traces sites look for and makes fine-grained work fast. On top of that you get the reliability machinery — occlusion-aware clicks, pushed waits with diagnostics, standing reactions — plus real GPUs, a persistable persona, a session-wide network log that does not pause the page, captcha solving, managed proxies and live remote control. BrowserVM runs your own script beside the page rather than in it.

It is not a drop-in replacement — you drive it through the Go or TypeScript SDK rather than the Playwright API. But the concepts map closely: click, fill, wait, evaluate and the network primitives are all there, so porting is mostly mechanical. What changes is that a lot of the retry and frame-handling code around your steps stops being necessary.

Your flow is ordinary Go or TypeScript in your own repository. There is no proprietary workflow format, no designer file, nothing that only opens in our tool — you review, diff, test and deploy it like the rest of your software. What is browserscale-specific is the client calls, so moving means replacing those and putting back the retry and frame-handling code the engine was doing for you. That is a real cost and worth knowing up front; it is not a hostage situation.

That is a core design goal. Control happens below the page with no injected JavaScript and no DevTools control-plane signals, so page scripts have nothing to observe. Pointer and key events travel the path real hardware takes and carry none of the markers that identify remote-controlled input. Combined with real GPUs, a persona you can pin and bring back, and a browser that presents itself on the wire the way a shipped Chrome does rather than a bare automation build, sessions look like a genuine user's browser rather than a headless bot.

No — and that is the point. Sessions run hardware-accelerated on real consumer GPUs that browserscale owns and operates, so canvas and WebGL readbacks return genuinely rendered pixels. There is no spoofing layer and no fingerprint hash database that a new probe could unmask, which is also why sessions hold up as passive checks get deeper.

Both. Text is typed character by character on the keyboard layout of the session's region, with per-character timing that varies the way a hand does, and composition for layouts that need it. Filling is strictly bound to its target: the field is verified as still holding focus as it types, and if something steals focus half way through it stops and names the element that took it rather than typing the rest of a password into it. There is also a deliberately loose mode for one-time-code boxes that move focus themselves on every digit.

Export the signed-in persona as one object — the account, its refresh token and the device-bound sessions that keep it alive long term — and import it into a fresh context, where it comes up signed in. Cookies and local storage can also be read and written as plain data. A country pins language, locale, timezone and keyboard together, the machine stays the same in every frame and every worker, and the rest of what a shipped Chrome carries comes back with it — so a later run is the same computer returning rather than a new install that happens to hold the same cookies.

Yes. Watching is attached to the session before anything loads — not to a tab you later debug — so a new iframe is already in the log before it fires its first request. A capture reports every finished request without pausing the page: every frame, every worker, every hop of a redirect, with the headers that actually went on the wire. Separately you can arm a wait for one call, rewrite it, swallow it, answer a navigation yourself, or drop matching requests by pattern.

Yes. One call detects the challenge, solves it with browserscale's own solver and wires the token back into the page within the same run — no third-party account or per-solve contract. No token is ever synthesized: the challenge is completed in the live browser and the provider's own JavaScript issues the token exactly as it would for a real user. Passive checks usually pass on their own thanks to real hardware and control the page cannot observe, so an interactive challenge tends to be the exception rather than the rule.

Mark the repeated JS, CSS and image paths as static once. Matching GETs are then served from a server-side cache that is reached directly — not through the session’s proxy — so repeat runs skip both the download and the proxy bill. A miss goes to the network as usual and is stored for next time.

Either way works. Pass your own host, port and credentials, or leave them empty and browserscale allocates a managed proxy server-side. You can also switch the proxy mid-session without relaunching the browser.

Yes — that is what it is built for. Each session is an isolated browser context rather than a fresh VM, sharing a host with its neighbours and rendering on a real GPU. There is no machine to boot: a browser is ready in under 250 ms. Every context has its own cookies, storage, cache, proxy and persona, so large queues never collide on state, and you can fan out from one job to thousands of concurrent sessions without managing browsers yourself.

Sessions share a host, so it is a fair question. Under contention the host divides time between sessions rather than letting whichever one is burning CPU take the machine, so a session grinding through a CPU-heavy challenge cannot starve its neighbours. Nothing is hard-capped either: on a quiet host a session uses what is there, which also means no run carries the flat, benchmarkable slowness of a capped browser.

Yes. The browser lives server-side, so any other worker, process or machine can attach to a running session by its id. The session survives a worker restart or a redeploy instead of dying with the process that launched it.

As the browser tier underneath it, not as a replacement for your orchestrator. Scheduling, approvals and reporting stay where they are; what changes is that the browser step stops being the flaky one. Sessions are addressed by id and outlive the worker that rented them, so they attach cleanly to whatever already owns the queue — and a person can take over a live session by hand when a run needs supervising. If you want the worker tier as well, the CLI scaffolds one as ordinary code you own.

Every session opens a real peer connection inside the browser and encodes the page on the same GPU that paints it — not a sidecar grabbing screenshots. You watch from the dashboard or the CLI. Mouse and keyboard ride dedicated data channels; paste from your machine inserts into the session, copy brings the remote selection back. The viewport size arrives with the stream so you are never aiming at a stale coordinate space. By default only a relay is used, so the session’s address never leaves the host.

Yes. One call returns a compact, token-budgeted view of the interactive elements across every frame — role, type, name, live value, label and flags — each tagged with a node handle you can hand straight to an action. Invisible-but-still-interactive elements are marked rather than dropped. And because failures are structured, a model gets something it can repair instead of a stack trace it can only retry.

Yes, a hosted one at https://mcp.browserscale.cloud/mcp. It exposes the browser as tools that map one-to-one onto the SDK — rent, navigate, observe, wait, click, fill, type, evaluate, screenshot, solve_captcha and the cookie and storage tools. Add the URL to any MCP client with an Authorization: Bearer header; the key stays in the client config and never becomes a tool argument. The server is stateless, so an agent can also attach to a session a failed run left behind and inspect the real page.

That is what the CLI is for. browserscale init scaffolds a Go module that already compiles and runs — worker harness, config schema, lifecycle loop, proxy pool and rent-with-backoff — plus a worked browser flow to pattern-match against. Open the folder in Cursor, Claude, Codex or any other coding agent and describe the job: it fills in the flow against real API signatures, because every scaffold ships an AGENTS.md and the full SDK reference offline. browserscale dev rebuilds, restarts and streams the logs from one command, so the agent can run its own work and fix what broke.

For exploring an unfamiliar page, clicking through with the MCP tools is exactly right. For work you repeat it is not: every step costs tokens on every run, you get one session per conversation, and when the chat ends nothing is left. Having the agent write a program moves the logic into code once. After that it runs with as many parallel workers as you configure, with no model in the loop, and you keep something you can review, diff and re-run.

No. There is no browser binary on your machine and no infrastructure to manage. You rent a session over the API and drive it remotely; browserscale handles the browsers, proxies, scaling and lifecycle server-side.

Official SDKs for Go and TypeScript, both driving the exact same browser API, plus a CLI and a hosted MCP server. If you drive the browser yourself the TypeScript SDK needs nothing but Node; the agent scaffold is Go, so that path wants the Go toolchain installed.

Pay-as-you-go and credit-based: you top up, earn bonus credits at higher tiers, and scale without per-seat fees or a monthly minimum. See the pricing page for the current tiers.

Install the Go or TypeScript SDK, grab an API key from your dashboard, rent a browser and drive it — the first script runs in under five minutes. If you would rather have a coding agent build the automation, install the CLI and run browserscale init to get a project that runs before you write a line.