Cloud Grid Execution

Introduction

What is Cloud Grid Execution?

Cloud Grid Execution lets you take the test suite you already run locally and execute it on a hosted browser fleet — BrowserStack, LambdaTest, or Sauce Labs — by clicking one button in the Runner. Testver handles everything the vendor normally makes you wire by hand: credentials, hub/CDP endpoints, config files, build naming, SDK agents, artifact collection, and — critically — proof that the run actually executed on the cloud.

Note

In one sentence: pick a provider next to Run on:, press Run, and your unchanged test command executes on the cloud grid — with the build, video, and logs linked back into Testver’s Results.

Who this guide is for

• QA engineers who need cross-browser coverage without maintaining grid config in every project.
• Teams migrating an existing local suite (Selenium, Playwright, Cypress — any language) to cloud execution.
• Anyone burned before by a “cloud” run that silently executed on a local browser — Testver’s verdict system makes that impossible to miss.

Key terms (glossary)

Term	What it means here
Cloud provider / grid	The hosted browser fleet: BrowserStack, LambdaTest, or Sauce Labs. Enabled in Connectors.
Zero-touch	A cloud run that needs no changes to your project at all — Testver attaches a vendor SDK or injects environment variables at run time.
Cloud-aware / cloud-ready	A project whose driver setup honors Testver’s cloud environment variables, so selecting a provider is enough.
AI Assistant fix	For stacks with no zero-touch path: a one-click handoff that has the AI Assistant make the smallest code change, run one verification test on the cloud, and confirm success from the ground-truth verdict.
SELENIUM_REMOTE_URL	The WebDriver hub URL Testver injects at run time (credentials embedded). Selenium-family projects read this to create a RemoteWebDriver.
CLOUD_CDP_URL	A complete, ready-to-connect websocket URL (capabilities and credentials embedded) Testver injects for Playwright/Puppeteer projects — connect to it verbatim.
Cloud execution verdict	Ground truth stamped on every cloud-selected run: whether a real cloud session was observed. A run that silently lands local gets a loud amber banner in Results; a run Testver couldn’t check with the provider is marked not verified.
Build name	The label grouping the run’s sessions in the vendor dashboard. Auto-generated per run unless you set one. A name you set can use {date}, {time} (both UTC) and {framework}, filled in when the run starts — e.g. testver-{date} becomes testver-2026-11-02.
SDK agent	A vendor-provided runtime component (e.g. BrowserStack’s Java agent) that redirects browser creation to the cloud without touching your source. Testver fetches and attaches it automatically.
Session capture	Testver reading the page through the test’s own cloud browser session — the evidence that powers Auto-Heal on cloud failures.

Setup: connect a provider

1. Open Settings → Connectors → Cloud Testing Providers and click Configure on your provider (BrowserStack / LambdaTest / Sauce Labs). Tick Enable ‹provider›, enter your Username and Access Key (and Region — US West, EU Central or US East — for Sauce Labs), optionally a Default Build Name, use Test Connection if you like, then Save.
2. That’s it for setup. The provider now appears in the Runner’s Run on: row (next to Local, Testver Grid when connected, and Local Devices for mobile workspaces, with a Build: field for cloud runs), in suite and Test Plan cycle run settings, and in schedules (Run On). CI pipeline mappings run on whatever target the mapped suite or cycle is set to.

Credentials never enter your project files as permanent secrets — Testver injects them per run (environment variables or a generated config file that is rewritten on every run). The access key is stored encrypted with a key file kept next to it in the project’s .testver/ folder (secret-store.key, never committed), so the saved keys move with the project and don’t depend on the user account or home folder Testver runs under. If your team commits .testver/cloud-config.json to Git, Testver keeps the keys in it in the older encoded (not encrypted) form, so teammates who check it out can still read them — keep such a repository private, or leave the file out of Git and let each person enter their own key. Testver masks the key in run output, stored logs, reports and the context it gives the AI, the same way it does for Testver Grid.

When a cloud run is refused

A run that asks for a provider is never moved to your machine. If the provider is turned off, removed, or has no username or access key, the run doesn’t start and a message says why — for example “BrowserStack is turned off in Settings → Connectors — the run was not started.” This applies to the Runner, suites, Test Plan cycles, schedules and CI alike. Turn the provider on (or set it up) in Settings → Connectors, or pick another target.

If a saved access key can’t be read on this machine (the key file it was encrypted with is gone or changed — for example .testver/secret-store.key wasn’t copied along with the project), the run is refused with “The saved access key can’t be read on this machine (the key file changed) — re-enter it in Settings → Connectors.” Open the provider there, type the key again and Save.

How a cloud run works, end to end

When you press Run with a cloud provider selected, Testver:

1. Analyzes the project (a fast code scan, re-checked on every run — no stale cached verdicts) to decide the connection path: zero-touch, already cloud-aware, or needs the AI Assistant fix. This readiness check only looks — it never installs anything. A vendor SDK the path needs is set up by the run itself, as before.
2. Prepares the run: injects provider env vars (SELENIUM_REMOTE_URL, CLOUD_CDP_URL, credentials, build name), generates the vendor config file where needed (e.g. browserstack.yml), attaches SDK agents for zero-touch stacks, and wraps the command where the vendor uses a CLI (browserstack-sdk, saucectl, browserstack-cypress-cli, lambdatest-cypress-cli).
3. Executes your unchanged command and streams output live, exactly like a local run.
4. Watches for cloud sessions as they are created — through its capability proxy, hub relay, or the SDK’s own session journal — feeding both the verdict and Auto-Heal’s session capture.
5. After the run: marks the vendor build complete, fetches artifacts (sessions, video, logs, dashboard links) into the Results page, and finalizes the cloud execution verdict.

Connection paths by stack

The path Testver chooses depends on your framework, language, and provider. You never pick it yourself — the analyzer does — but knowing the map helps you predict what happens.

Zero-touch (nothing in your project changes)

Stack	BrowserStack	LambdaTest	Sauce Labs	How
Selenium Java and Kotlin (TestNG / JUnit / Kotest / Cucumber-JVM)	✅	—	—	BrowserStack’s JVM agent, fetched once via your own Maven (or from Maven Central when Maven isn’t installed) and attached with JAVA_TOOL_OPTIONS. Maven and Gradle projects both work. new ChromeDriver() becomes a cloud session.
Selenium Python (pytest / pytest-bdd / behave) and Robot Framework + SeleniumLibrary	✅	—	—	BrowserStack’s Python SDK, installed once via your own pip; Testver prepends browserstack-sdk to your command. A command run through an environment tool (poetry run, uv run, pipenv run, pdm run, hatch run) gets the SDK inside that environment: poetry run browserstack-sdk pytest …. A command that already starts with browserstack-sdk is left as it is.
Robot Framework + SeleniumLibrary	✅	✅	✅	Testver adds its own Robot listener to the run (through ROBOT_OPTIONS), which opens SeleniumLibrary’s Open Browser on the provider’s hub — your suites don’t change. A remote_url your suite passes itself is kept. Also used on Testver Grid. (Robot’s Browser library, which is Playwright-based, still needs the AI fix.)
Selenium C# (NUnit / xUnit / Reqnroll / SpecFlow)	✅	—	—	BrowserStack.TestAdapter NuGet package (one PackageReference added via your own dotnet CLI to each Selenium test project of the solution — the only zero-touch path that touches a project file, never source code). Plain dotnet test then runs on the cloud.
Playwright JS/TS	✅	—	✅	Command wrap: browserstack-node-sdk / saucectl, for a command that calls playwright test directly (a cd folder && in front is kept). On BrowserStack, Firefox and WebKit runs use BrowserStack’s Playwright Firefox and WebKit browsers. On Sauce Labs your filters carry over: files, -g / --grep, one or more --projects, the config named with -c / --config, and a single test run by file:line (sent as that test’s title); with Local tunnel on, the run joins your Sauce Connect tunnel by its Tunnel Name (without a name, no tunnel is used and the Output panel says so).
Cypress	✅	✅	✅	The vendor’s Cypress CLI runs your project: browserstack-cypress-cli, lambdatest-cypress-cli or saucectl, fetched with npx. Testver writes its config for the run (browserstack.json, lambdatest-config.json or .sauce/config.yml) next to your Cypress config. The config carries your specs (--spec), the browser (--browser or the run’s target browser), --headed, --component, your Cypress version and your other npm packages. Your --env and --config values and CYPRESS_* variables such as CYPRESS_grep (a single test run by name) carry over too. Sauce Labs has no place for --config values, so they are not sent there and Testver logs a warning — set them in your Cypress config file instead. A cd folder && in front and an npm script that is one cypress run both work. If your project has its own browserstack.json or lambdatest-config.json, its settings are kept; only the account, build name and tunnel are set.
Selenium selenium-webdriver (JS)	✅	✅	✅	The JS Builder honors SELENIUM_REMOTE_URL natively — env injection is enough.
WebdriverIO	✅	✅	✅	A config Testver generates for the run (wdio.testver.conf.*, next to yours and removed afterwards) points it at the provider and adds the build and session names; your config is never edited. Works when the command calls wdio directly. A command that runs a package script (npm test) still needs a config that reads the user, key and hostname from the environment variables Testver sets.
Mobile (Appium, any language)	✅	✅	✅	The mobile cloud-bridge: it uploads the app and adds the device capabilities, with no code changes (see Mobile (Appium) commands). Each vendor gets its own fields: BrowserStack’s bstack:options, Sauce Labs’ sauce:options build and name, and LambdaTest’s LT:Options build, name and real device (isRealMobile). The Local tunnel setting applies to device sessions too. Your WebdriverIO capabilities are kept, with the picked device and app set over them. Java, C# and Ruby projects get the picked device, OS version and app too, in place of their local values (a local device serial or emulator name is dropped). A zipped simulator .app is refused for the cloud — simulator builds run only on a local iOS simulator; upload an .ipa for a cloud iPhone or iPad. An uploaded app is reused for the same account (and Sauce Labs region) and uploaded again after 25 days, before the vendor deletes it. If the vendor no longer has it (deleted in its dashboard), the run says so and the next run uploads it again.

The provider files Testver writes for a run (browserstack.yml, browserstack.json, lambdatest-config.json, .sauce/config.yml) carry your access key, so they are removed when the run ends. If your project keeps its own copy of one of them, that copy is put back. If Testver stops in the middle of a run, it does this the next time it starts (a file you edited since is left as it is). While they exist, the Git page leaves them out of staging and commits.

Runs in the same project that read one of these files — BrowserStack SDK runs, Sauce Labs Playwright and Cypress runs, LambdaTest Cypress runs — take turns, so one run never picks up another’s file. A run that has to wait says “Waiting for another cloud run in this project to finish” in its output, and Stop cancels it before it starts. For the same reason, suites and Test Plan cycles run their tests one at a time on BrowserStack, on Sauce Labs for Playwright and Cypress, and on LambdaTest for Cypress.

One-time costs on a fresh machine (SDK download via your own Maven/pip/NuGet) happen automatically on the first cloud run and are cached after that. If a fetch fails (offline, proxy), Testver logs it plainly and falls back to the standard flow — never a silent wrong state.

AI Assistant fix (one-time, per project)

Stacks with no vendor zero-touch mechanism need the project’s driver setup to honor Testver’s cloud environment variables — a small, one-time code change. Testver does not edit your code silently; it hands the job to the AI Assistant, in front of you:

Stack	BrowserStack	LambdaTest	Sauce Labs
Selenium Java	zero-touch	🔧 AI fix	🔧 AI fix
Selenium Python / behave	zero-touch	🔧 AI fix	🔧 AI fix
Robot Framework (Browser library)	🔧 AI fix	🔧 AI fix	🔧 AI fix (through SeleniumLibrary)
Selenium C#	zero-touch	🔧 AI fix	🔧 AI fix
Selenium Ruby	🔧 AI fix	🔧 AI fix	🔧 AI fix
Playwright Java / Python / .NET	🔧 AI fix	🔧 AI fix	❌ (Sauce has no Playwright CDP endpoint)
Playwright JS	zero-touch	🔧 AI fix	zero-touch
Puppeteer	🔧 AI fix	🔧 AI fix	❌ (not supported by Sauce)

The contract the fix implements is deliberately tiny:

• Selenium-family: when SELENIUM_REMOTE_URL is set, create a RemoteWebDriver pointed at it; when unset, behave exactly as today (local browser).
• Playwright/Puppeteer-family: when CLOUD_CDP_URL is set, connect() to it instead of launching (in a Playwright Test project: use.connectOptions = { wsEndpoint: process.env.CLOUD_CDP_URL } in the config). The URL is complete — capabilities and credentials already embedded — so the code uses it verbatim. It asks for the run’s browser (Chrome, Edge, Firefox or WebKit) and, when Local tunnel is on, the provider’s tunnel.

CLOUD_CDP_URL exists only for BrowserStack and LambdaTest, so the Playwright fix is offered only for them. On Sauce Labs, the AI Assistant does not add a Playwright connection: Robot’s Browser library can move to SeleniumLibrary when that is a small change, and Playwright for Java, Python or .NET is reported as not supported there.

After the fix, the project is cloud-aware for every provider that speaks the same protocol, and the dialog never appears again (readiness is re-derived from the code on each run, so a revert is caught immediately).

The “Not connected yet” dialog

When a cloud run is requested on a project that isn’t cloud-aware and has no zero-touch path, a dialog titled Not connected to ‹provider› yet appears instead of the run, explaining that the project’s driver setup doesn’t honor Testver’s cloud settings and the run would silently execute on a local browser. Its buttons are Cancel, Run Anyway and Fix with AI Assistant:

• Detection Summary — the detected Framework, Language, and the Driver file (guess) a heuristic scan points at (Not located when none is found). The file is labeled a guess: the AI Assistant verifies it (and looks for other driver-creation sites) before touching anything.
• Fix with AI Assistant — the primary action. It makes no changes and no AI calls from the dialog; it navigates to the AI Assistance screen with a complete work order pre-filled: what was detected, the exact env contract, your own run command (so verification reuses your scope), and the verification rules.
• Run Anyway — runs as-is with the cloud env vars injected. If your code already reads them, this just works; if not, the run lands locally and its result carries the “executed locally” warning.
• Cancel (or the X, or a click outside the dialog) — nothing happens.

What the AI Assistant does with the work order

1. Reads the project, confirms where drivers are really created (the hint may be wrong — it checks), and makes the smallest change that satisfies the env contract.
2. Compiles/sanity-checks where the language has a compile step.
3. Runs one verification test on the chosen provider — through Testver’s runner, using a dedicated tool (it cannot and does not improvise with shell commands or APIs).
4. Reads the run’s cloud execution verdict — ground truth, not test output — and self-corrects on failure, up to 3 attempts.
5. Ends in one of exactly two states: verified on the cloud (with the build link), or every change reverted with a plain explanation of what blocked it.

You watch every edit and the verification run live in the AI Assistance screen. Requirements: an AI provider configured (Settings → LLM); each verification attempt uses a small amount of cloud minutes.

Copy-paste AI fix prompts

The Fix with AI Assistant button assembles the prompt automatically from your project’s detections — normally you never write it. These copies exist as a fallback: if the pre-filled prompt was lost, edited by mistake, or produced a wrong result, paste the matching prompt into the AI Assistance screen yourself. Replace <provider> with browserstack, lambdatest, or saucelabs, and <your run command> with the command you normally run.

Selenium family — any language (Java, Python, C#, Ruby), Robot Framework, behave

Make this test project run on <provider> through Testver, WITHOUT changing how it behaves locally.

- Find where the WebDriver/browser is actually created (driver factories, base classes,
  fixtures, hooks) — verify it in the code, and fix every site that creates a local driver.
- When the SELENIUM_REMOTE_URL environment variable is set, create a RemoteWebDriver
  (or this language's equivalent) pointed at that URL — Testver injects it at run time
  with credentials embedded.
- When it is NOT set, behavior must stay exactly as today (local browser).
  Never hardcode credentials or vendor URLs.
- Make the smallest possible edit. No restructuring.
- My usual run command: <your run command>

Then verify your change yourself (required):
1. Compile/sanity-check first if the language has a compile step.
2. Run ONE quick test using the run_tests tool with cloud_provider: "<provider>" —
   reproduce my run command's scope through the tool's framework/files/args parameters.
   Do NOT use shell commands, the testver CLI, or Testver's HTTP API to start or inspect runs.
3. The tool's result includes the run's CLOUD EXECUTION VERDICT — trust it over any test
   output. observed=true means the run REALLY executed on the cloud; observed=false with
   final=true (and NOT unverified) means it silently ran locally and the change did not
   take effect. unverified=true means Testver could not ask the provider — that is NOT
   evidence of a local run: never change or revert files because of it.
4. On failure, use that evidence, adjust, and retry — 3 attempts maximum.
5. If it still fails after 3 attempts, restore every file you modified to its original
   state and explain exactly what blocked you. An unverified verdict is never a reason
   to restore files.

Report at the end: the files you changed, the verify run's cloudExecution verdict,
and the cloud build link if available.

Playwright family — Java, Python, .NET, or JS on a provider without a zero-touch wrap

Make this test project run on <provider> through Testver, WITHOUT changing how it behaves locally.

- Find where the Playwright browser is actually launched (base classes, fixtures, hooks) —
  verify it in the code, and fix every site that launches a local browser.
- When the CLOUD_CDP_URL environment variable is set, CONNECT the browser to it
  (browserType.connect / playwright.chromium().connect) instead of launching locally.
  It is a COMPLETE websocket URL with capabilities and credentials already embedded —
  use it verbatim; never build capabilities, query strings, or vendor URLs yourself.
- Ignore SELENIUM_REMOTE_URL entirely: it is a WebDriver endpoint and Playwright
  cannot speak to it.
- Under the same cloud condition, disable Playwright's own video recording
  (video: 'off') — the vendor records video platform-side, and Playwright's
  recorder needs ffmpeg on the REMOTE browser host, where it fails.
- When CLOUD_CDP_URL is NOT set, behavior must stay exactly as today (local launch).
- Make the smallest possible edit. No restructuring.
- My usual run command: <your run command>

Then verify your change yourself (required):
1. Compile/sanity-check first if the language has a compile step.
2. Run ONE quick test using the run_tests tool with cloud_provider: "<provider>" —
   reproduce my run command's scope through the tool's framework/files/args parameters.
   Do NOT use shell commands, the testver CLI, or Testver's HTTP API to start or inspect runs.
3. The tool's result includes the run's CLOUD EXECUTION VERDICT — trust it over any test
   output. observed=true means the run REALLY executed on the cloud; observed=false with
   final=true (and NOT unverified) means it silently ran locally and the change did not
   take effect. unverified=true means Testver could not ask the provider — that is NOT
   evidence of a local run: never change or revert files because of it.
4. On failure, use that evidence, adjust, and retry — 3 attempts maximum.
5. If it still fails after 3 attempts, restore every file you modified to its original
   state and explain exactly what blocked you. An unverified verdict is never a reason
   to restore files.

Report at the end: the files you changed, the verify run's cloudExecution verdict,
and the cloud build link if available.

Note

Sauce Labs has no Playwright CDP endpoint — this prompt applies to BrowserStack and LambdaTest only.

Puppeteer — BrowserStack or LambdaTest

Use the Playwright prompt above with one change: replace the connect instruction’s first bullet pair with:

- When the CLOUD_CDP_URL environment variable is set, connect via puppeteer.connect with
  a browserWSEndpoint derived from it. CLOUD_CDP_URL targets the vendor's PLAYWRIGHT
  endpoint — adapt the endpoint path to the vendor's Puppeteer endpoint (BrowserStack:
  wss://cdp.browserstack.com/puppeteer, LambdaTest: wss://cdp.lambdatest.com/puppeteer)
  while KEEPING the capabilities/credentials query string from CLOUD_CDP_URL unchanged.

The cloud execution verdict

Every run that selected a cloud provider gets a verdict answering one question: did it actually execute there?

• Observed — Testver saw real cloud sessions being created (or the vendor’s build records confirm them). The Results page shows the sessions, video, and build link as usual.
• Executed locally — no cloud session was observed and the provider has no build for the run. The run detail shows a loud amber banner: the project’s driver setup is not cloud-connected. No green result can mask this — test output cannot fake the verdict.
• Not verified — Testver could not read the provider’s records (the provider refused the saved key, rate-limited the call, could not be reached, or did not list the build yet). The banner says Cloud execution not verified with the reason, in grey. This is not evidence that the run executed locally — check the build on the provider’s dashboard. The AI Assistant never reverts a fix because of it.
• Device runs — when a mobile run’s test reported no session (a scheduled or CI run, a closed tab, a driver that builds its own hub address), Testver looks the run up in the provider’s app-testing builds: App Automate, LambdaTest mobile automation or Sauce Labs real devices. The sessions it finds confirm the run and bring their video and logs. If none is found, the banner says No device session found on the provider and why. Runs on Local Devices get no verdict: they run on your machine by design.

While the post-run check against the vendor’s records is still in flight, the banner area shows a quiet “verifying cloud execution…” state.

Tip

The verdict is also what the AI Assistant trusts when verifying its own fix — the same ground truth you see is the one it must satisfy.

Results, artifacts, and Auto-Heal on cloud runs

In Results, the Cloud source chip narrows the runs list to cloud-dispatched runs.

• Cloud Session card — each session with browser/OS, status, duration, Video (plays in an in-app player), Logs, and a Session deep link into the vendor dashboard; plus a View Build link. A cloud run whose artifacts haven’t been pulled yet shows a Fetch Artifacts button in the run header (not for Local Devices or Testver Grid runs).
• Build status — Testver marks the run’s sessions passed/failed via the vendor API after every run, so dashboards stay truthful without any status-reporting code in your project. Only this run’s sessions are marked, and a status your test set itself is left alone. A session whose name matches one of the run’s tests gets that test’s result; any other session is marked only when the whole run is clear (every test passed, or every test failed). Device sessions (App Automate, Sauce Labs real devices, LambdaTest app automation) are marked too, when the whole run is clear.
• Auto-Heal works on cloud failures — Testver captures the page through the test’s own cloud session (via its proxies, or the SDK’s session journal for agent runs), so a broken locator that fails on BrowserStack can be healed with the same evidence quality as a local run. See Auto-Heal.

Cloud runs beyond the Runner

• Suites and Test Plan cycles can target a cloud provider the same way. Each test of a suite or cycle gets its own build: the build name plus a short run id.
• Schedules run on the provider configured for the schedule.
• CI pipelines (delegated execution) dispatch through the same runner — the verdict and artifacts appear in CI Runs like any other run. A CI suite mapping that names no target runs where the suite is set to run, with the suite’s saved provider, device and app.
• Re-run Failed in the Runner runs the failed tests on the target the original run used, not the one picked now. If that provider is no longer set up, it says so and puts the command in the Run Command field.
• Stop ends the run’s own sessions on the vendor too: Sauce Labs jobs and LambdaTest sessions are stopped. BrowserStack has no stop call, so its sessions end on BrowserStack’s idle timeout once the test process is gone.
• A cloud run triggered on a project that isn’t cloud-aware doesn’t have a dialog in headless contexts — it runs env-only and, if it lands local, the verdict marks it. Fix it once from the Runner and every trigger path benefits.

Troubleshooting

Symptom	Meaning	Fix
Amber “Cloud run executed locally” banner	The driver setup isn’t cloud-connected — the run never reached the grid.	Run again from the Runner and use Fix with AI Assistant.
Grey “Cloud execution not verified” banner	Testver couldn’t read the provider’s API (the reason is shown). It says nothing about where the run executed.	Check the build on the provider’s dashboard. If the reason is a refused key, re-check it in Settings → Connectors.
”… is turned off in Settings → Connectors — the run was not started” (or not set up, has no username or access key)	The run asked for a provider that can’t be used, so it was refused instead of running on your machine.	Turn the provider on or set it up in Settings → Connectors, or pick another target.
”The saved access key can’t be read on this machine”	The key was saved with a key file this machine no longer has.	Re-enter the access key in Settings → Connectors and Save.
Output says “Waiting for another cloud run in this project to finish”	Another run in the same project is using the vendor config file.	Wait — it starts when the other run ends — or press Stop to cancel it.
Dialog appears again after a successful fix	The cloud-aware code was reverted or removed — readiness is re-checked from the code every run.	Re-apply (the AI fix or your own edit).
”Could not fetch/install the … SDK” in the server log	The one-time SDK download failed (offline, proxy, missing toolchain).	Check network/proxy; the run fell back to the standard flow, nothing is wedged.
Cloud run works but no artifacts/build link	The vendor build lookup can lag a few seconds; it retries. If the build name was reused across runs, links may point at the merged build.	Leave Build: blank (and the connector’s Default Build Name empty) for auto-generated unique names (testver- plus the date and time to the millisecond), or use the {date}, {time} and {framework} placeholders in your build name.
Playwright project told to use SELENIUM_REMOTE_URL by an old guide	Outdated — Playwright/Puppeteer projects use CLOUD_CDP_URL (a complete websocket URL).	Connect to CLOUD_CDP_URL verbatim.
Playwright cloud run fails with “Executable doesn’t exist … ffmpeg”	Your config records video (video: 'retain-on-failure' etc.) — with connectOptions the recorder runs on the vendor’s machine, which lacks Playwright’s ffmpeg. The vendor records video on its side anyway.	Set video: 'off' under the same CLOUD_CDP_URL condition as connectOptions.

FAQ

Does Testver modify my project for cloud runs? Zero-touch paths: no source changes ever (the .NET path adds one NuGet PackageReference; config files like browserstack.yml are Testver-generated and rewritten per run). When your project already has its own browserstack.yml, Testver keeps its settings, adds the run’s own (credentials, build name, browser), and puts your file back when the run ends. Files Testver creates for a run (browserstack.yml, lambdatest-config.json, .sauce/, .sauceignore) are removed afterwards. AI Assistant fix: yes, one small reviewed change — made in front of you, verified on the cloud, and fully reverted if verification fails.

My app runs on localhost or a private network. Can a vendor’s browsers reach it? Yes, through the vendor’s own tunnel: BrowserStack Local, Sauce Connect or LambdaTest Tunnel. Turn on Local tunnel in the provider’s settings under Connectors and add its tunnel name if you use one. Every web session then asks for that tunnel. Start the tunnel on your machine before the run; the Output panel reminds you when the run starts. Runs through a BrowserStack SDK (the zero-touch Java, Python, .NET and Playwright paths) start BrowserStack Local themselves.

Which stacks need nothing at all? See the zero-touch table above — most notably all of BrowserStack’s Java/Python/.NET Selenium paths, Playwright JS, Cypress everywhere, and all mobile Appium runs.

Do cloud runs consume my vendor minutes? Yes — including the AI fix’s verification runs (bounded to one small test per attempt, 3 attempts max) and Auto-Heal’s verification re-runs if enabled.

Can I keep running locally after connecting? Always. The env contract is explicit: cloud only when Testver injects the variables; your local behavior is untouched.