Where your code runs

Browlix has two kinds of calls, and they run in different places.

Management calls: anywhere

Everything in the API reference — creating profiles, opening and stopping sessions, reading runs, managing webhooks — is an HTTPS call to browlix.com. Make it from your server, a laptop, a CI job or an AI agent in the cloud.

Browser control: on the session's machine

Driving the page itself (Playwright, Puppeteer or raw Chrome DevTools Protocol) goes through a broker that the Browlix worker runs on the same machine as the browser:

1. sessions.attach returns a ticket and endpoint: ws://127.0.0.1:<port>/cdp.
2. The broker listens on the loopback address only. Nothing outside that machine can reach it.
3. It accepts the connection only with a valid, unexpired ticket for that session, and refuses it once the session moves on.

So the code that calls connectOverCDP must run on that machine — for example a script you deploy next to the worker, or one of your apps running there. A cloud agent that receives a ticket cannot use it from elsewhere: the address points at its own machine, and the broker would refuse it anyway.

your server / agent ──HTTPS──▶ browlix.com ──commands──▶ worker on machine A
                                                         │
                         script on machine A ──ws://127.0.0.1──▶ broker ──▶ browser

Watching and controlling from elsewhere

To see or operate a browser from another computer, use Remote view in the web app: it streams the page and forwards input under the control rules of the workspace. It is meant for people, not for automation code.

Choosing a machine

devices.list returns each machine's operating system, whether it is online and how many sessions it can still open. sessions.start needs an explicit device_id; Browlix does not pick a machine for you through the API.