Self-hosting overview
Run the full VeilBrowser stack (control plane, worker fleet and release origin) inside your own network.
Enterprise VeilBrowser is self-hosted. You run the control plane and worker fleet on your own infrastructure; browser sessions never leave your network. This section is the operator's guide to installing, running and maintaining that stack.
Who this is for
Teams that need data residency, network isolation, or high concurrency behind their own perimeter. Managed (cloud) users can stay on the Platform docs.
What you run
Three components, on your side of the perimeter:
- The cluster manager is the control plane. It owns the OpenResty load-balancer configuration, serves the release origin that feeds browser builds and profile bundles to workers, and runs every fleet change as an audited operation.
- Workers run the Local API. They are the only tier that launches browsers, and they hold no configuration of their own beyond an organization key and an install directory.
- The release origin is a webroot served by the cluster manager. Workers pull activated browser builds and profile bundles from it, so a fleet upgrade is a publish-then-activate operation rather than a redeployment.
One thing stays in the cloud: the VeilBrowser control plane remains authoritative for accounts, plans and concurrency. Workers call it before each launch and fail closed if it denies them. See Licensing & concurrency for what that call carries and what it does not.
Reviewing this before you deploy it
Architecture enumerates every connection that crosses between your infrastructure and ours — direction, payload, purpose and where each terminates — including the one that does not cross. The security page is its companion and leads with what VeilBrowser does not hold: no third-party audit or certification, no published data-protection position, no bug bounty.
Getting to production
Understand the model
Read Architecture so the separation of duties and the config-reload pipeline are clear before you install anything.
Install the control plane
Installation covers the one-command Docker path and the manual steps behind it. The onboarding walkthrough explains every field in the first-run wizard.
Harden the edge
Configure TLS and lock down direct-IP access following Edge security & TLS before you point real traffic at the cluster.
Scale out
Add workers. Automation keeps connecting to one load-balanced endpoint rather than to individual boxes.
Set up operations
Establish a backup routine and read Operating the cluster for the daily health sweep and the release workflow.
Reference
Configuration
Every environment variable, port, volume and role.
Troubleshooting
Diagnose launch, fleet, TLS and registry failures.
Licensing & concurrency
How plan limits reach a self-hosted fleet.
Upgrades & rollback
Roll the control plane and workers safely.
Security posture
What is not in place — audits, certifications, disclosure — and what exists instead.