Self-hosting an antidetect browser fleet
Why enterprises run antidetect browsers on their own infrastructure, and the three-tier architecture that makes it operable at scale.
TL;DR
Self-hosting runs browser execution inside your network for data residency, isolation and performance. A clean three-tier split (control plane, worker fleet, cloud licensing) keeps a large fleet auditable and safe to operate. Four connections still cross to the cloud, and they are enumerated rather than summarised away.
For teams operating hundreds or thousands of browser identities, where the browsers run matters as much as how they are fingerprinted. Self-hosting answers three needs at once: data residency, network isolation, and predictable performance.
Why self-host
- Execution stays on your infrastructure. The browser process, its profile directory, and everything a session writes to disk are on hardware you provision. Page traffic leaves through the proxy you configured and goes straight to the target, never through us.
- Compliance and isolation. Run inside your own perimeter, with your own controls.
- Concurrency. Scale workers horizontally without a third party's limits in the path.
What that is not is a claim that nothing leaves your network. Licence checks and usage metering go out; profile bundles and browser builds come in. The trust boundary lists what sits on each side and every connection between them, and the security page states what VeilBrowser does not hold. If your review needs a certification, that is worth establishing on the first call rather than the fifth.
The three-tier model
VeilBrowser separates duties so each tier has one job:
Control plane
The cluster manager: load balancer, release origin, and fleet operations, with all changes audited.
Worker fleet
Hosts running the Local API; the only tier that launches browsers.
Cloud licensing
The authority on plan limits and org-wide concurrency, checked before every launch.
This separation is what keeps a big fleet manageable: browsers only ever launch on workers, orchestration only happens through the control plane, and identity and limits live in one authoritative place.
Operability is part of the product
A serious self-hosted product needs more than a binary. The essentials:
- Idempotent install: one Docker container, one command, re-runnable. See installation.
- Safe config reloads: the load-balancer config is staged, validated and atomically swapped, so a bad config can never take down the fleet. See operating the cluster.
- Backup and restore of control-plane state. See backup & restore.
- Upgrades and rollback with versioned installs. See upgrades.
How licensing works when self-hosted
Even self-hosted, the cloud remains the authority on your plan. Before launching, a worker calls the authorize endpoint; the cloud counts running sessions across the whole organization (not per host) and answers allow or deny. The worker then reports session start and stop, which is what keeps that count accurate.
The check is fail-closed with no grace window: if the cloud denies the request or is simply unreachable, the worker does not launch. Sessions already running are never killed. Plan for that when you design the network: workers need reliable outbound HTTPS to the control plane, and a launch costs one round-trip. Details in licensing & concurrency.
FAQ
Talk to us
Planning a large deployment? Contact sales or read the self-hosting docs.