A Browserless alternative when you need a profile per account, not a headless pool

Browserless is a browser pool: a server that hands out headless Chrome, Firefox or WebKit over a WebSocket to whichever script connects, and queues the rest. You can rent it or run the Docker image yourself. For screenshots, PDFs, tests or scraping, a pool is probably the better design. This page is for teams using it to hold many accounts, each of which should look like the same device every time.

Figures below come from browserless.io/pricing, the persisting state docs and the GitHub README, all captured 2026-10-22.

What Browserless's pricing page says

The pricing page shows annual billing, which it says saves 30%. Monthly prices are higher and were not shown in the page content we captured, so they are not quoted here.

Plan	Price (billed annually)	Units/month	Max concurrent	Max session	Persisted sessions	Overage
Free	$0	1k	2	2 min	1 day	-
Prototyping	$25/mo	20k	10 (+5)	15 min	7 days	$0.0020/unit
Starter	$140/mo	180k	40 (+10)	30 min	30 days	$0.0017/unit
Scale	$350/mo	500k	100 (+20)	60 min	90 days	$0.0015/unit

A unit is "a block of browser time of up to 30 seconds per browser connection", and "Session-reconnects count as new browser connections and incur a fresh Unit charge." Residential proxy traffic is 6 units per MB, datacenter 2 units per MB, and a solved CAPTCHA 10 units. Enterprise is custom, with licensed self-hosting.

Self-hosting has a licence question

Browserless publishes a Docker image (ghcr.io/browserless/chromium) and the source on GitHub. The README gives the licence as "SSPL-1.0 OR Browserless Commercial License" and says that building commercial sites, applications, or closed-source CI on it needs a commercial licence. Read that before you plan a pool inside a proprietary product.

The README also splits features in two. Queueing, a debug viewer and crash tolerance come with the open-source image; persistent sessions, BrowserQL, the stealth and CAPTCHA routes and the residential proxy are premium features of the cloud and Enterprise offerings. In a self-hosted open-source pool, keeping an account's state between runs is your code's job.

How persistence works there

On the hosted plans you POST /session with a required ttl, get a connect URL, and reconnect later. Cookies, localStorage and cache persist in an isolated user data directory, and each reconnect starts a new browser process on a blank page. Per the docs, "Sessions are permanently deleted when the ttl elapses", the TTL is capped by plan at 1, 7, 30 or 90 days, and a second client connecting to the same session gets HTTP 429.

What a long-lived account costs in units

Units are charged per connection in 30-second blocks, and a reconnect is a new connection. An account checked six times a day for five minutes costs 10 units a visit, 60 a day, about 1,800 a month. Prototyping's 20k units cover roughly 11 such accounts; past that, overage at $0.0020 a unit is about $3.60 per account-month, before proxy traffic. The free plan's 2-minute session cap is shorter than many sign-in flows that wait for an email code. None of this is unfair. It is a fleet priced for short jobs, applied to a long one.

When Browserless is the right tool

• Stateless volume. Screenshots, PDFs, Lighthouse runs, tests, public-page scraping, and the /smart-scrape, /crawl, /map and /search endpoints the README lists.
• Compliance paperwork. The pricing page lists SOC 2 Type II, GDPR, an available HIPAA BAA and a DPA.
• Several engines. Chrome, WebKit and Firefox appear on the free plan.
• An SSPL-compatible open-source project that wants a free self-hosted pool.

The general split between these two kinds of work is in scraping vs account automation.

Pool versus profile, when both run on your hardware

• A pool hands out interchangeable browsers. Any client gets the next free one, with concurrency limits and timeouts set on the server. That makes it efficient, and leaves per-account identity to be bolted on from outside. The README lists "fingerprint randomization" among the premium stealth features: right for scraping, wrong for an account that should look like the same device on every visit.
• A profile is not interchangeable. In AntiBrow you launch a named profile, a directory on your disk with no TTL, and its fingerprint, cookies, IndexedDB and passkeys come with it. The fingerprint is generated once and applied in the browser engine below the JavaScript layer. Give each account its own profile and the account-to-device mapping is fixed by construction, not by your scheduler.
• Scaling and billing follow. A pool scales by adding containers behind one endpoint. AntiBrow keeps local profiles unlimited on every plan and meters how many run at once, from $9.9/mo. launch() returns a real Playwright Page and BrowserContext, so page-level code written for a Browserless endpoint mostly carries over.

Not something either tool fixes

Detection mostly comes down to proxy reputation, behaviour and account history. We have no current test run comparing the two, so no claim here about which is detected less.

Check it yourself

Start the open-source image with docker run -p 3000:3000 ghcr.io/browserless/chromium, connect twice, and open CreepJS each time. Do the same with one AntiBrow profile launched twice. Write down navigator.userAgent, the WebGL renderer, navigator.hardwareConcurrency and the fingerprint ID for all four runs, and note which values change between runs of the same setup.

Read the SDK docs or see pricing.