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 keeps browser sessions 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.
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
- Sessions stay on your infrastructure. Nothing about what you browse leaves your network.
- 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.
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 — 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, with a usage heartbeat.
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 via Docker or a bare-metal bootstrap. 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 requests a launch slot; the cloud verifies plan and organization-wide concurrency, and the same call reports usage. It is fail-closed after an offline grace window, so limits hold even during a network blip. Details in licensing & launch slots.
FAQ
Talk to us
Planning a large deployment? Contact sales or read the self-hosting docs.