Browser & Device Clouds

Selenoid starts a fresh Docker container per WebDriver session, proxies the session to the driver inside, then force-removes it on delete. Nothing carries over: no profile, cookies, downloads or stray process, unless browsers.json mounts a host directory in.

Anything the cleaning between sessions did not reach: installed apps and their data, signed-in accounts, granted permissions, clipboard, downloads, browser profile and system settings like locale. Battery charge and temperature carry over regardless, because they are physical, not configured.

A Linux container grid hosts what Linux can run, so Chromium-family and Firefox builds. Apple's Safari needs Apple machines and a handset is hardware, so a rented fleet reaches them only because the provider racked those machines.

Selenoid's server-side limit flag does, capping simultaneous container runs on each Selenoid host. Ggr has no concurrency ceiling at all; the count attribute in its quota file is a relative host weight for load balancing, not a cap.

Virtual capacity is manufactured on demand: an image started onto server capacity the provider extends by adding servers. A handset model exists as physical units nobody can duplicate, so that supply grows slowly, and it shrinks as units fail.

W3C WebDriver reserves the colon for extension capabilities, so a provider's settings must sit under prefixed keys; gathering them into a single map is convention, not a rule. Loose non-standard keys are not capabilities the specification recognises at all.

A tunnel carries traffic for a defined set of names; anything outside that set the remote browser fetches the ordinary way. The danger is silence: an unlisted internal name can resolve publicly and the test passes against the wrong site.

An internal name means something only to a resolver inside your network, so the name itself must cross the tunnel and resolve at the inside end. A pre-resolved address freezes one machine's answer, which the rented browser cannot check.

A relay process inside your own network opens an outbound connection to the provider and holds it open; the rented browser's requests for internal names travel back down that connection, so no inbound firewall opening is needed.

Because the credential is a component of the URL rather than a separate field, every tool that touches the address touches the secret. Selenium's own client both authenticates from that user info and masks it before printing a request.

No. The worker count is a local setting that decides how many sessions your suite tries to hold at once; the ceiling belongs to the provider account and is enforced there, whatever your runner is configured to do.

It is attached to the account a session request authenticates as, not to a machine, a pipeline, a repository or a person. Everything presenting that account's credential draws on the same ceiling, including runs your team never started.

Not from the error code. WebDriver defines no capacity error, so implementations reuse the generic ones and only the message string names the cause. Read the message text, the failure's timing, and your own queue counters instead.

Nothing on the far side necessarily bounds it. Selenoid, unmaintained per its own README, waits until a slot frees or the client disconnects, with no server deadline, so your client's read timeout is the bound you actually control.

A run consumes session time — the count of sessions open at once multiplied by how long each stays open. Running wider shortens wall-clock but barely moves that total; shortening each session shrinks it directly, and idle time counts.

The service makes the recording on its own machine: a capture process beside the browser grabs the virtual screen for the whole session. A test asks with one setting in the session request and fetches the finished file afterwards.

A separate container reads the browser's virtual display over the container network and encodes it, needing no hook in the browser and no driver command. The two projects differ in whether that recorder is per session or standing.

A remote end can end your session first: an inactivity timer that frees the slot, a ceiling on total session length, your own client hanging up, or the fleet reclaiming the machine. Later commands then fail on an unknown session.

A missing verdict takes one of three shapes: the call was skipped before it ran, refused when it arrived, or lost when the process died. That is evidence about your reporting path, not about the test.

Send the verdict, a case name that is stable across runs, something separating this attempt from the last, and a short failure reason. Keep secrets out of all of it: the payload lands on someone else's machine.

Typing a password into a rented browser delivers the live secret onto hardware you do not own: it sits in the form field, in that browser process, and in whatever the page's own script does with it.

A rented session is a browser on hardware you do not own, so it holds what any browser holds: the passwords your test types, the tokens the logged-in session carries, claim records rendered on screen, and internal names it resolves.

Three things: it is standing, so only the issuer ending it ends it; it names and authenticates the account with one pair; and its destination is inside a connection address, so it lands in a string many tools print whole.

Potentially every run on the account. An artefact route commonly checks only that the caller authenticates, then resolves the recording from its session identifier, so a credential that never started the run can still fetch it. Measure that boundary yourself.

Entitlement, capacity, artefacts, audit identity and revocation all collapse onto the account. Whoever holds the key draws on the same pool, reads the same artefacts, appears in records under the same name, and loses access together when it is rotated.