Skip to content
Docs
Documentation

Docs · Start

Documentation

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

Install & run is the shortest path from nothing to a profile that starts. On Windows that is a desktop app with an installer; on Linux it is the daemon binary plus one engine install. Both end at the same place: a daemon answering on 127.0.0.1:8787 with your API token.

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 UI the daemon serves 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.

Why the profiles hold up

Two 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.

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 — software rendering is visible from the page regardless of what the profile claims. Details in Install & run.
  • 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. Coherence & proxies covers what the daemon checks about an exit once you have one.

Next