Install & run
Install Scalebrowser on Windows with the desktop client: requirements, first start, engine provisioning, ports and configuration.
Scalebrowser runs on your own machine. Windows is the platform it ships for: a desktop app you install once, which carries the daemon inside it.
Two parts, always. The daemon is the program that manages profiles and serves the API. The engine is the signed Chromium build the profiles actually run in. They are shipped separately, and the daemon refuses to launch a profile until a verified engine is installed.
Every install signs in once. Your subscription decides how many browsers may run at the same time across all your machines, so each machine says which account it belongs to. Until it does, the daemon serves its API and starts no browser. Creating an account is free; running one needs an active plan, and the trial runs seven days and starts one browser for you. See Plans & limits.
The desktop client
The Windows client installs the daemon alongside itself, supervises it, fetches the engine on first start and renders the management UI. Windows 10 or 11, 64-bit.
- Sign in at scalebrowser.net and open Download. The button carries the current version.
- Run the installer. It installs for the current user under
%LOCALAPPDATA%\Programsand asks for no administrator rights. - Start Scalebrowser and press Sign in. A browser window opens on scalebrowser.net; sign in there, and the window closes by itself. The app now knows which account this machine belongs to.
- Wait for the engine. The app downloads and verifies it right after the sign-in and tells you while that is happening. A profile cannot start before it has finished, and the download itself needs an active plan or a running trial.
- Create a profile in the UI, or point an agent at the API: see MCP, direct CDP or REST.
SmartScreen will warn you on first run. There is no Windows publisher certificate on the installer yet, so Windows shows the blue “unrecognised app” screen. Choose More info → Run anyway. The installer and the update feed are signed with our own key (minisign), and the app verifies that signature before it applies any update.
Launching profiles needs a real GPU. There is no software-rendering fallback: a host whose GPU is a software rasterizer boots the daemon and serves the whole API, so you can create and manage profiles, but a profile launch is refused at the pre-launch check.
Where things end up
| What | Path |
|---|---|
| Application | %LOCALAPPDATA%\Programs\Scalebrowser |
| Profiles, engines, database, token | %LOCALAPPDATA%\Scalebrowser |
| App settings and logs | %APPDATA%\Scalebrowser |
Uninstalling removes the application and leaves the data directory alone, so your profiles survive a reinstall. Closing the app stops the daemon, and the daemon stops the browsers it started, so nothing is left running in the background.
Check that it works
/health is public: it answers without a token, which makes it the right thing for a monitor to poll. Everything under /v1 needs the bearer token:
$ curl http://127.0.0.1:8787/health
$ curl http://127.0.0.1:8787/v1/profiles \
-H "Authorization: Bearer $SCALEBROWSER_BEARER_TOKEN"Over TLS the scheme is https, and a self-signed test certificate needs curl -k. If the first call answers and the second returns your (empty) profile list, the daemon is up and your token is right.
Ports
| Interface | Default | State |
|---|---|---|
| Native API (REST, MCP over HTTP, CDP WebSocket) | 127.0.0.1:8787 | On |
| AdsPower-compatible adapter | 127.0.0.1:50325 | Off until you enable it |
| Prometheus scrape endpoint | 127.0.0.1:9464 | Off until you enable it |
The AdsPower adapter is unauthenticated by design, so it may only ever bind to a loopback address, and the daemon refuses to start if it is pointed anywhere else. The same applies to the Prometheus endpoint, which is unauthenticated plaintext and warns loudly if you bind it publicly.
Configuration
Four layers, later ones win:
- built-in defaults
- a TOML config file (
--config) - environment variables
- command-line flags
Every setting, with its default, is on Configuration. The ones most installs touch:
| Environment variable | What it sets |
|---|---|
SCALEBROWSER_BEARER_TOKEN | the API token clients send |
SCALEBROWSER_MASTER_KEY | the key that encrypts stored secrets at rest |
SCALEBROWSER_API_TOKEN | the pairing token that connects this machine to your account |
SCALEBROWSER_DATA_DIR | where profiles, engines and the database live |
SCALEBROWSER_BIND_ADDR | address of the native API |
SCALEBROWSER_ADSPOWER_BIND | address of the AdsPower adapter, or off |
SCALEBROWSER_WEBUI_DIR | serve the management UI from a directory instead of the bundled one |
The data directory defaults to %ProgramData%\Scalebrowser; the desktop client overrides it with its own per-user location. Everything the daemon owns lives there: the SQLite database, installed engines, each profile's browser directory, the at-rest key and runtime.json. Back that one directory up and you have backed up your profiles.
The API token
If you do not supply a token, the daemon can mint one and store it in the data directory:
$ scalebrowser-daemon --generate-tokenOn a loopback bind the daemon prints the management UI's address on start, with the token in the URL fragment so the page signs itself in. That happens only on loopback: on a network address the URL stays token-free and the token is printed separately, because a URL carrying a credential must not be handed around.
Next
- Quickstart: from here to an agent driving a page.
- Core concepts: the words the rest of this documentation uses.
- MCP server: connect an AI agent and let it operate a page.
- Configuration: every setting the daemon reads, with its default.