Browser infrastructure your security review can approve
Browserless runs the headless browsers behind your automation, in our cloud or entirely on your own infrastructure. Same Puppeteer and Playwright code, no browser fleet to operate.
175M+
Docker pulls
SOC 2
Type II report
99.9%
Uptime commitment
Managed headless browsers, as infrastructure
Plenty of work only a real browser can do: signing into a portal that has no API, filling a multi-step form, rendering a page to PDF, driving an AI agent through a site built for humans. Doing that in production means running a fleet of Chrome instances, and Chrome is a bad tenant. It leaks memory, competes for CPU, and needs patching every time it updates.
Browserless is that fleet, run properly. You connect over WebSocket with the Puppeteer or Playwright code you already have, or call REST and BrowserQL endpoints, and you get back a browser that works. The same container is available to run inside your own network, which is what makes it viable for teams whose data cannot leave it.
// Cloud: point at a regional endpoint
const browser = await puppeteer.connect({
browserWSEndpoint: 'wss://production-sfo.browserless.io?token=YOUR_API_KEY',
});
// Self-hosted: same code, your host
const browser = await puppeteer.connect({
browserWSEndpoint: 'wss://browserless.internal.your-vpc.example/?token=YOUR_TOKEN',
});Security & compliance
Three things are true of every enterprise team that buys this
If all three describe your situation, a conversation is worth having. If none of them do, the self-serve plans are almost certainly the better fit.
An engineer owns the automation
Browserless is infrastructure, not a no-code tool. The person who evaluates it writes Puppeteer, Playwright, or BrowserQL, and connects an existing script to a new endpoint. There is nothing to migrate to and no SDK to adopt.
Something is breaking at scale
Chrome leaks memory over time, concurrent sessions compete for CPU and RAM, and self-managed browser infrastructure needs constant security patching. That usually shows up as flaky jobs and a growing on-call burden before it shows up as a budget line.
There will be a security review
The blocker on most enterprise browser automation is not the code, it is the vendor assessment. Self-hosting removes Browserless from the data path entirely, and the SOC 2 Type II report, DPA and BAA terms your reviewers will ask for are available on request through the Trust Center.
Three ways to run it, and the differences are real
The APIs, request formats and connection patterns are identical across all three. What changes is who operates the infrastructure and which features come with it.
Cloud
We run everything
Point your code at a regional endpoint and go. Includes the managed residential and datacenter proxies, stealth routes with automatic CAPTCHA solving, and the advanced REST APIs like Smart Scrape and unblock.
- San Francisco, London and Amsterdam endpoints
- Managed proxies with geotargeting
- Hosted dashboard, request logs and session replay
Self-hosted Docker
You run the containers
The licensed enterprise image on your own infrastructure, inside your VPC, on-premises, or fully air-gapped. It makes no callbacks to Browserless and license keys validate offline, so the only egress you have to allow is to the sites you are automating. This is the option that clears a data-residency or data-sovereignty requirement outright.
- Docker, Podman or Kubernetes; bring your own load balancer
- OpenTelemetry export and a local /metrics endpoint
- Bring your own proxies; managed proxies are cloud-only
Private Deployment
We run dedicated infrastructure for you
Same enterprise image, same APIs, but Browserless operates a dedicated fleet on your chosen cloud provider. The middle path when you want isolation and capacity without taking on the operations.
- Dedicated fleet with tailored specifications
- Extensive datacenter locations including the EU
- GPU-enabled infrastructure available
Self-hosting is the right call when you need data sovereignty, an air-gapped environment, or network policies a managed deployment cannot provide. Everything runs on Linux, on amd64 or arm64.
What comes with an enterprise agreement
Where the compliance argument is sharpest
The pattern matters more than the label: authenticated or bot-protected sites, automated at scale, inside an organization that runs a formal security review.
Tell us what you're automating
Bring the use case, the volume, and whatever your security team needs to see. We will tell you which deployment model fits and what it costs.