Introduction
Documentation for Scalebrowser: install the daemon, then drive a profile from an AI agent over MCP, direct CDP, REST or the AdsPower-compatible adapter.
Everything needed to run Scalebrowser and drive a profile from an agent, and nothing that is not backed by the code that ships.
What it is
Scalebrowser is self-hosted browser infrastructure for AI agents. You run a daemon on your own machine; it creates browser profiles, launches them, and hands them to whatever drives them: an agent, your own code, or a script you already have. Headless by default, with a visible window when you ask for one.
It comes in two parts, and they are shipped separately. The daemon is a single binary: it holds the profiles, enforces what has to be true before one may start, and serves every interface on this site. The engine is a Chromium fork we build and sign ourselves, the browser the profiles actually run in. The daemon verifies the engine's signature at install and at every launch, and refuses to start a profile without one.
A profile is a persistent identity: its own cookies and storage, its own proxy, and a full set of fingerprint values drawn deterministically from one seed, so the same profile is the same machine every time it starts.
Start here
Five steps from nothing to an agent reading a page. Start here if you want to see it work.
Install & runThe Windows client, where everything lands, and the settings most installs touch.
Core conceptsNine words the rest of this site uses: daemon, engine, profile, persona, seed, tier, lease, run, machine.
The management appThe interface the daemon serves, and the settings that exist nowhere else.
Four ways in
All four talk to the same daemon and the same profiles. Pick by who is driving, not by what you want to do. Anything one of them can do, the profile can do.
| Interface | Pick it when |
|---|---|
| MCP server | An AI agent should read the page and act on it itself. It gets a handle and a small tool set instead of a browser connection, and every click and keystroke goes through the input layer. |
| Direct CDP | You are writing the automation. The daemon starts the profile and hands back a WebSocket address you drive with your own code, in any language. |
| REST API | You are managing profiles rather than pages: creating them, assigning proxies, starting and stopping them, watching what the fleet is doing. |
| AdsPower adapter | You already have scripts written against AdsPower's local API and want them to keep working without a rewrite. |
The management app is a fifth way in, and it is the one to use first: it does everything the REST API does, and it is how you see a profile before you point an agent at it.
An agent in a chat service that runs in someone else's cloud reaches the same MCP server through remote access, without the browser leaving your machine.
Why the profiles hold up
Three pages explain the parts that are not an API surface, because they are what you are actually paying for.
Coherence & proxies covers what a profile has to agree with before the daemon lets it start, and why a launch is sometimes refused. Human input covers how a click or a typed word is produced, and why nothing on that path adds random noise. Proxies & exits covers the half of an identity that lives outside the browser, which is the half judged first.
What it expects from you
Three things, and none of them are optional in practice:
- Your own hardware. There is no hosted mode and no browser of ours in the middle. Profiles, engines and the database live in one directory on the machine you run the daemon on. Back up that directory and you have backed up everything.
- A real GPU. A host whose GPU is a software rasterizer boots the daemon and serves the entire API, but a profile launch is refused at the pre-launch check, because software rendering is visible from the page regardless of what the profile claims. Details in Coherence & proxies.
- A residential or mobile proxy. Nothing in the daemon forces one, and a profile without a proxy starts and works. It just leaves from your own address, and where a request comes from is judged before any JavaScript on the page has run, so no amount of work inside the browser reaches it. Proxies & exits covers what to do about that.
Read these docs from an agent
Everything on this site is served twice: once for you, once for whatever you are building with. No account and no key on any of it.
https://scalebrowser.net/llms.txtlists every page with a one-line summary, so a model can pick before it fetches.llms-full.txtis the whole site in one file.- Any page plus
.mdis that page as plain Markdown.https://scalebrowser.net/docs/install.mdis this site's install page with nothing around it. https://scalebrowser.net/docs/mcpis an MCP server over these docs, with three tools: search them, read one page, list the structure. Add it in Cursor or VS Code from the Copy page menu at the top of any page, or point any MCP client at that address.
The MCP server here reads documentation and nothing else. The one that drives browser profiles is the daemon on your own machine, which is what the rest of this site is about.
Next
- Quickstart: the shortest path that ends with an agent working a page.
- Tool reference: every tool an agent can be given.
- Errors · Events: the two contracts a client has to handle.
- Plans & limits: what a subscription actually buys.
- Changelog: what shipped, and when.