Browserless Docker is what you reach for when managed browser APIs are directionally right but the browser runtime still needs to live inside your network. You get a standard container, a documented WebSocket surface, and operational controls for concurrency, queueing, session timeouts, and reconnect windows.
What Browserless Docker Is
Browserless Docker is not just Chrome in a container. The open-source image and the enterprise image are both trying to solve the same real problem: browser automation becomes infrastructure faster than most teams expect.
One script becomes ten. Ten scripts become a service. Then you need queueing, auth, timeouts, reconnection, debugging, and a sane surface for Playwright and Puppeteer clients. Browserless packages that into a container boundary instead of asking each team to build its own browser platform.
The query intent behind browserless chrome
The `browserless chrome` keyword is usually not asking for a different product. It is usually asking how to run Chromium-backed Browserless infrastructure or connect to a Browserless-hosted Chrome session without hand-rolling that runtime.
Quick Start
The Browserless README starts with the most honest possible quick start: run the image, connect to the local endpoint, and keep using normal browser automation libraries.
Start Browserless Chromium locally
docker run -p 3000:3000 ghcr.io/browserless/chromiumConnect Puppeteer to Browserless Docker
import puppeteer from 'puppeteer-core';
const browser = await puppeteer.connect({
browserWSEndpoint: 'ws://localhost:3000',
});
const page = await browser.newPage();
await page.goto('https://example.com');
console.log(await page.title());
await browser.close();Connect Playwright to a Browserless Playwright endpoint
import pw from 'playwright-core';
const browser = await pw.firefox.connect(
'ws://localhost:3000/firefox/playwright'
);
const page = await browser.newPage();
await page.goto('https://example.com');
console.log(await page.title());
await browser.close();Configuration Knobs
The enterprise Docker docs make the operational story explicit. Browserless expects you to tune the container the same way you would tune any shared runtime service.
Authentication
TOKEN controls API authentication for client requests. Enterprise deployments also distinguish between the enterprise KEY and the runtime TOKEN.
Concurrency and queueing
CONCURRENT or MAX_CONCURRENT_SESSIONS limit active browsers, and queue-length settings cap how many pending requests wait before 429s.
Timeouts and reconnects
TIMEOUT and MAX_RECONNECT_TIME define how long sessions live and how long they remain reconnectable after a client disconnect.
Health and monitoring
Docker-level config extends into logging, health, external address config, and webhook alerts for production supervision.
Representative enterprise Docker run
docker run -p 3000:3000 \
-e "KEY=ent_abc123..." \
-e "TOKEN=my-secure-token" \
-e "CONCURRENT=20" \
-e "QUEUED=30" \
-e "TIMEOUT=300000" \
registry.browserless.io/browserless/browserless/enterprise:latestBrowserless Chrome and Browser Choice
The default mental model is Chromium, because the quickest start is the Chromium image and the default local endpoint. That is why `browserless chrome` is such a common modifier around the product.
But Browserless is broader than Chromium-only usage. The README explicitly points teams toward Firefox and multi-browser images when they need Firefox or WebKit support for Playwright. So if you only remember Browserless as “hosted Chrome,” that is directionally right for the common path but incomplete for the full product.
Open Source vs Enterprise Docker
| Dimension | Open-source image | Enterprise Docker |
|---|---|---|
| Best for | Testing, development, smaller internal tooling | Production workloads, private deployments, stronger control surfaces |
| Getting started | Fastest path | Longer setup but broader config |
| Auth model | Simpler | License key plus runtime auth model |
| Operational controls | Core controls | Broader configuration surface for storage, monitoring, hooks, and private deployment |
| Typical buyer | Engineering team owning its own tools | Platform, infra, or security-conscious teams |
When Docker Wins
Use Browserless Docker when the browser is part of your platform, not just part of a one-off script.
- You need a shared browser service inside your network perimeter.
- You want one endpoint for multiple teams using Playwright or Puppeteer.
- You need predictable concurrency, queueing, and session policy controls.
- You want to standardize browser automation without adopting an agent-specific stack.
If you do not need those things, the managed Browserless API is usually the simpler starting point.
FAQ
Can I use docker compose with Browserless?
Yes, but the important decision is not Compose versus a raw Docker command. The important decision is how you will set auth, concurrency, queue limits, timeout, and persistence around the container.
Does Browserless Docker replace Playwright?
No. It gives Playwright and Puppeteer a remote browser runtime. Your automation code still lives in Playwright or Puppeteer unless you choose the REST-style API routes instead.
Should I start with the Chromium image or a multi-browser image?
Start with Chromium if your workload is Chromium-only and you want the fastest path. Move to Firefox or multi-browser images when your Playwright coverage actually needs those engines.
Browser automation code gets messy fast
Selectors, retries, session code, and deployment config rarely arrive as clean one-file changes. Morph is built for merging those cross-file updates back into a real repo quickly.