Multi-profile

Every profile is a different computer.Not one computer reporting different values.

Storage, device signature and network route are held per profile. The device values sit inside the browser build rather than in JavaScript injected at page load, so a profile presents the same machine on its five hundredth launch as on its first.

Contact sales Get started

Pick a plan and start today, or talk to us about enterprise from $5,000 once the profile count and the fleet behind it are the job.

Fig. 01One profile and the three things it owns. The endpoint at the bottom is what a launch hands back to your code.

Isolated per profile: cookies · localStorage · IndexedDB · cache
Device targets: Windows · macOS · Linux · Android
Proxy schemes: http · https · socks5 · socks5h
Lifetime: persistent · one-time

01Isolation

Isolation

Two profiles have nothing to share

Cookies, localStorage, IndexedDB and cache belong to the profile that created them. There is no shared jar, no shared cache and no common directory for one session to read another one's state out of.

Fig. 02Two profiles on one worker. The storage boundary is real, and the machine underneath is shared, which is the honest edge of what isolation means here.

What a profile holds on its own

Cookies: One jar per profile. An account signed in inside one profile is not signed in inside another, and a cookie set in one is not readable from the other.
Site storage: localStorage, sessionStorage and IndexedDB are separate stores. A site that writes an identifier into storage writes it into exactly one profile.
Cache: The HTTP cache is per profile, so an asset one profile has already fetched is not already present in the next one.
The device: Canvas, WebGL, audio and font readings come from the build pinned to the profile. Two profiles on one worker answer differently because they are different builds, not because something rewrote the answer on the way out.
The route: The proxy is a property of the profile rather than of the machine running it, so moving a profile to another worker moves its exit address with it.

What isolation is not

Profiles running on one worker share that host: its kernel, its clock and its network interface. The boundary is the profile's storage and identity, not a virtual machine. A workload that needs machine separation as well needs separate workers rather than separate profiles.

What a profile bundle contains and where its storage lives are documented rather than described, so the boundary can be checked instead of taken on trust.

Profile docs

02The device

The device

Where each value comes from

A detector reads around forty-five properties. Every one of them is answered by the browser build or by the profile bundle, so there is no override layer with a stock engine underneath it for the two to disagree.

Fingerprint signals, what each one covers, where its value comes from, and whether it changes between launches
Signal	Covers	Source	Between launches
Rendering	Canvas, WebGL, WebGPU, client rects and text rects	Browser build	Fixed in the build
Audio	AudioContext readings	Browser build	Fixed in the build
Fonts	The platform font engine for the profile's operating system target	Browser build	Fixed in the build
Client hints	UA-CH headers, platform and model, and their JavaScript counterparts	Browser build	Fixed in the build
Device metrics	Device memory, pixel ratio, hardware concurrency, media devices	Profile bundle	Fixed in the bundle
Screen	Resolution, available area, colour depth, orientation	Profile bundle	Fixed in the bundle
Region	Timezone, locale, language list, geolocation	Proxy exit address	Read at each launch
WebRTC	The ICE candidate set	Proxy route	Follows the route

Nothing in the source column is a script running inside the page, which is why nothing in it can be read around.

The selection space

Operating system targets: Windows, macOS, Linux and Android. A macOS profile enumerates macOS fonts while running on a Linux worker, and the host's own fonts stay out of it.
Chrome majors: 135 through 150. You name the major you want and the platform matches a build to it rather than approximating one with a user-agent string.
Android device models: Android resolves a specific named model rather than a generic phone, and brings touch simulation, mobile device metrics, orientation and a mobile keyboard viewport with it.
Pinned, not sampled: The build a profile resolves is pinned to it. A duplicate carries the selection criteria across but resolves its own build, because a copy is meant to be a second identity rather than the same one twice.

Every signal in the table has a documented default, so the list can be checked against whatever you intend to run it against.

Fingerprint docs

03The route

The route

One proxy per profile, and DNS at the exit

Two identities never share an exit address by accident, because the proxy belongs to the profile rather than to the machine. With socks5h the hostname is resolved at the exit as well, and that is the one item in this section no competitor ships, each of them checked against their own documentation on a stated date.

Fig. 03The same four positions in both lanes. What moves is where the hostname is resolved: on your worker under socks5, at the exit under socks5h.

Per-profile network

Four schemes: HTTP, HTTPS, SOCKS5 and SOCKS5H, assigned per profile. A single launch can also override the route without changing the profile it belongs to.
Remote DNSOurs alone: With socks5h the proxy receives the hostname and resolves it at the exit, so the lookup never appears on your resolver. No other antidetect platform ships it, and the comparison page cites the page and date behind that.
Region from the exit: Timezone, locale, language list and geolocation are read from the exit address at launch. Every serious platform in this category does this; it is on the list because it has to be right, not because it is rare.
WebRTC leak prevention: On by default. The candidate set reflects the proxy route rather than the host, and it is a coherent set rather than an empty one, because no candidates at all is its own tell.
QUIC and STUN tunnelled: Both run over UDP, which does not travel through an HTTP proxy. They are tunnelled over SOCKS5 so neither can carry the host's real position out around the session.

Proxy formats, the per-launch override and what a profile does when its exit stops answering are all in the network documentation.

Network docs

04Lifetime

Lifetime

Profiles that persist, and profiles that do not

A persistent profile accumulates its own storage and presents the same device for as long as it exists. A one-time profile deletes itself when its session ends, which is the right shape for work that should leave nothing behind to be reused.

Fig. 04Two lifetimes on the same axis. The persistent lane carries its storage between launches; the one-time lane ends with the profile and its storage removed together.

Choosing between them

Persistent: The default. Storage carries between launches, so a signed-in session stays signed in and the device stays the device an account has already seen. Anything with an account behind it wants this.
One-time: Created for a session and deleted when it ends. Nothing carries into the next run, which is what makes each collection or each observation independent of the last one.
Gone is gone: A one-time profile's storage is removed with it, and there is nothing to recover afterwards. Anything worth keeping has to leave the session before it ends.

Lifetime is one field on the profile, set when it is created and shown on every row in the profile list.

Profile docs

05At volume

At volume

A hundred profiles, and the people who use them

Deletion takes a list of profiles in one call. Duplication and creation are one call each, so a hundred profiles is a loop rather than a single request, and that is worth knowing before you plan around it.

Operations

Create: One call per profile, against the profile allowance on your plan. There is no bulk create endpoint, so scripting the loop is the current answer.
Duplicate: One call copies a profile's operating system target, its browser major, its selection criteria and its proxy. It does not copy the pinned build: a duplicate resolves its own, because a copy is meant to be a second identity.
Bulk delete: One call takes a list of profile ids and returns the number removed. Ids that belong to another organisation are ignored rather than refused.
List and filter: Filter by operating system, browser major, device model and renderer, with pagination, so a large profile set stays navigable from code rather than only from the dashboard.

The people

Organisations and roles: Owner, admin and member. Roles are enforced on the API rather than only in the interface, and members are invited by email against the seat limit on your plan.
Shared without shared credentials: A member launches a profile without ever holding the account password stored inside it, and removing the membership removes the access.
One endpoint for the fleet: Cluster mode puts a single WebSocket endpoint in front of every worker, so automation connects to one URL and the fleet decides which machine serves it.

The full parameter set for every call above is in the API reference, including the ones that are still one request per profile.

API reference

06Automation

Automation

Connect with what you already have

A launch returns a Chrome DevTools Protocol endpoint. Puppeteer and Playwright attach to the WebSocket directly, Selenium attaches to the same debugger's host and port, and nothing needs a driver written for this platform.

launch.sh

curl -X POST http://localhost:3000/sessions/profile \
  -H "X-API-Key: $WORKER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "profileId": "<profile-id>" }'

# 201 Created
# {
#   "id": "<session-id>",
#   "status": "running",
#   "webSocketDebuggerUrl": "ws://127.0.0.1:38923/devtools/browser/<id>"
# }

The launch goes to a worker or to the cluster endpoint, never to the cloud API, because that is where the browser is. The response carries the session id and the debugger URL.

Surfaces

CDP endpoint: Loopback-scoped on the worker, which means code driving it runs on that machine. Cluster mode is the answer when the automation lives somewhere else.
REST API: Provision profiles, launch sessions and read usage over HTTP, with a per-plan request rate published before you buy it.
Typed SDK: A typed client over both the cloud and the worker surfaces, so request and response shapes are checked at compile time rather than in production.
Command line: Drive profiles and sessions from a terminal or a CI job without opening the dashboard.

The examples above are the ones in the documentation, and they are the whole integration: launch, connect, work, stop.

Automation docs

07Limits

Not available

Three things this page will not claim

Set in the same typeface as the capabilities, because an evaluation finds them either way and finding them here is cheaper for both of us.

Not available
iOS and Safari targets
Android is the only mobile target. There is no iPhone profile and no Safari engine, and no amount of user-agent editing produces one.
One call each
Bulk profile creation and duplication
Deletion takes a list of ids. Creation and duplication do not, so provisioning a large set is a loop against those endpoints rather than a single request.
Not a machine boundary
Isolation between profiles on one host
Profiles are separated in storage and identity, not by a virtual machine. They share the worker's kernel, clock and network interface, so a workload that needs machine separation needs separate workers.

None of the three is a roadmap slide. The first two are shapes of the current API and the third is a property of the architecture.

Documented limits

Bring the profile set you actually need to run.

How many identities, on which targets, through whose exits, driven by which tool. Start on your own and read the documentation, or bring those four numbers to a call that ends with a price and a demo.