Cloud browsers that don't look automated.

browserscale is a browser-as-a-service platform that runs real Chromium browsers in the cloud. You rent an isolated session and drive it from Go or TypeScript instead of installing, scaling and babysitting your own headless browser farm.

browserscale is used for large-scale web scraping and data collection, automated testing, and driving AI browser agents — anywhere you need real Chromium sessions that stay undetectable and scale to hundreds or thousands of parallel tasks, driven from Go (browserscale-go) or TypeScript (browserscale-ts).

Playwright and Puppeteer drive the browser from outside over the DevTools protocol (CDP). browserscale runs natively inside Chromium itself: commands execute in the renderer process, nothing is injected into the page, there is no Runtime.enable and no DevTools handshake. That removes the automation traces sites look for and makes execution faster — and you get undetectable fingerprints, human-like input, captcha solving, proxies and live remote control on top.

It's a real, full Chromium engine running in the cloud — real pages, frames, cookies, storage and a complete network stack — not a headless DOM emulator or an HTTP client with a JavaScript shim. Sites get a genuine browser environment, which is part of why automation stays undetectable.

browserscale isn't a drop-in replacement — you drive it through its own Go (browserscale-go) or TypeScript (browserscale-ts) SDK rather than the Playwright or Puppeteer API. But the concepts map closely: the same click, fill, wait, evaluate and network primitives are there, so porting a script is mostly mechanical. In return you drop the CDP-based stack that sites can detect and gain engine-level control, a flat frame tree and managed proxies.

That's the core thing browserscale is built to avoid. Because control happens inside the engine with no injected JavaScript and no CDP control-plane signals, page scripts can't observe the automation. Combined with real, replayable fingerprints (canvas, WebGL, audio, codecs, WebRTC) and human-like mouse movement, sessions look like a genuine user's browser rather than a headless bot.

No — and that's the point. browserscale sessions run hardware-accelerated on real consumer GPUs that browserscale owns and operates, so canvas and WebGL readbacks like toDataURL or getImageData return genuinely rendered pixels. There is no spoofing layer and no fingerprint hash database that a new bot-protection probe could unmask, which also makes sessions future-proof as passive checks get deeper.

Yes. Mouse movement uses browserscale's own motion algorithm with realistic paths instead of teleporting the cursor straight to the target, and input is delivered as genuine browser-level events rather than synthetic DOM dispatches. Together with real fingerprints and engine-level control, interactions read like a person rather than a script.

browserscale ships official SDKs for Go (browserscale-go) and TypeScript (browserscale-ts). Both drive the exact same browser API, so you can use the same session concepts and commands from backend workers, scripts or services.

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

Capture state with GetCookies and GetStorage, then replay it on the next rental with SetCookies and SetStorage to carry the cookie jar and localStorage across sessions. Pair it with a pinned fingerprint so the site sees a returning visitor instead of a brand-new install, and you skip logging in every run.

Yes. Fingerprints are server-side IDs you can pin and reuse. WithFingerprint(id) restores the whole browser identity — user agent, canvas, WebGL, audio, locale and more — not just cookies, so repeat runs look like the same machine coming back.

Yes. browserscale waits are armed once inside the engine and resolve event-driven the instant the condition is met — no polling loop that can race the page. Built-in steady-time checks only report an element back once it exists and holds its position in the DOM, so animations and layout shifts are absorbed before your click. The checks are configurable if you need to match hidden or off-screen elements too.

browserscale collapses the main document, same-origin iframes and cross-origin OOPIFs into one flat frame tree — every frame is just a frameId. No flattened CDP sessions, no waiting on Runtime.enable for a per-frame execution context. Wait and Click can act across all frames at once or scope to a single iframe, and Wait hands back the frameId that matched so you can act on it directly.

Yes. Passive anti-bot checks tend to pass on their own thanks to real fingerprints, real hardware and clean, CDP-free control. For interactive challenges, a single SolveCaptcha call detects, solves and wires the token back into the page within the same run. Solving is done by browserscale's own AI solver, which learns the known challenge types — puzzle, OCR, slide, hold and more — on its own and keeps improving as they evolve. browserscale never synthesizes a token: the challenge is completed in the valid live browser and the provider's own JavaScript issues the token itself. That's also why it's future-proof — protections browserscale has never seen before pass too, because there's no emulated environment or synthesized response for a new check to expose.

Yes — and unlike CDP-based route handlers that race navigations and late-attaching frames, browserscale interception sits in the browser's network stack itself. Every request from every frame, including cross-origin OOPIFs, passes through it; nothing slips by. From the SDK you can wait for specific requests or responses as part of the flow, modify headers, mock responses, or block matching requests by pattern — without leaving your script.

Mark repeated JS, CSS and image paths as static once with SetStaticPaths. browserscale then serves them from a server-side cache, so repeat runs skip re-downloading the heavy static assets through your proxy — only the bytes that actually change go over the network.

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 with SetProxy without relaunching the browser.

Yes — that's what browserscale is built for. Each session is an isolated browser context rather than a fresh VM or OS process, so there's no machine to boot: a browser spins up in under 250 ms. Every context has its own cookies, storage, cache and fingerprint, so large queues never share or collide on state. You can fan out from one job to thousands of concurrent sessions without managing browsers yourself.

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

Yes. GetObservation returns a compact, token-budgeted view of the visible, interactive elements — as text or JSON — across every frame, each tagged with a node handle you can hand straight to an action. Your model reasons over what matters instead of a megabyte of raw HTML.

That's what browserscale-cli is for. Running browserscale-cli init scaffolds a Go module that already compiles and runs — the worker harness, a config schema, the lifecycle loop, a 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-cli dev rebuilds, restarts and streams the logs from one command, so the agent can run its own work and fix what broke.

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 <api-key>' header; the key stays in the client config and never becomes a tool argument. The server is stateless: rent returns a sessionId that later calls carry, so an agent can also attach to a session a failed run left behind and inspect the real page.

No. If you drive the browser yourself, the TypeScript SDK needs nothing but Node. If you want a coding agent to build the automation, the scaffold is Go and you need the Go toolchain installed — but the idea is that you describe the job and review the result rather than writing SDK calls by hand.

For exploring an unfamiliar page, clicking through with the MCP tools is exactly right. For work you repeat, it isn't: 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.

Every cloud browser streams to your screen over WebRTC as a low-latency H.264 video. You can watch automation run in real time to debug failed selectors, redirects or surprise popups, and take over with mouse and keyboard over data channels to finish any step by hand.

Pricing is 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 — your first script runs in under five minutes. The Quickstart walks through the whole flow. If you'd rather have a coding agent build the automation, install browserscale-cli instead and run browserscale-cli init to get a project that runs before you write a line.