Testver Grid

Introduction

What is Testver Grid?

Testver Grid is Testver’s own cloud browser service. Your tests keep running on your machine; only the browser moves to the cloud. You pick Testver Grid next to Run on: in the Runner and press Run — that is the whole setup.

It is the same idea as Cloud Grid Execution with BrowserStack, LambdaTest or Sauce Labs, with one difference: there is no vendor to sign up with. No account, no username, no access key, no separate bill. Your Testver account is the only thing you need.

Note

In one sentence: cross-browser cloud execution that comes with your Testver plan — nothing extra to buy, nothing to configure, and nothing in your test project changes.

Who this is for

• Teams who want cross-browser coverage without opening a vendor account or managing another set of credentials.
• Anyone whose laptop is the bottleneck — browsers are heavy, and running ten of them locally makes a machine unusable while the suite runs.
• Projects that must run somewhere clean — a fresh browser per session, with nothing left over from the last run.
• CI-less teams who still want runs that do not depend on one particular developer’s machine being awake.

What you get

Browsers	Chromium (three version lines), Firefox, WebKit
Clients	Selenium in any language, Playwright, WebdriverIO, Puppeteer, and Testver’s own AI browser
Session evidence	Video of every session, plus a WebDriver command log
Localhost testing	Supported — grid browsers can reach an app running on your own machine
Setup in your project	None. No config file, no new dependency, no code change
Included with	Pro (1 browser at a time), Power (2) and Team (3, shared by the whole team). Nothing is billed per run

Advantages

Nothing to sign up for. Vendor grids need an account, a plan, and a pair of credentials pasted into every machine and CI job that runs tests. Testver Grid needs your Testver login and nothing else.

Your test code does not change. Testver Grid speaks the protocols your framework already speaks — the WebDriver hub for Selenium, Playwright’s own connect protocol, CDP for Puppeteer. Whatever runs locally runs on the grid, unmodified.

One credential, and it expires. There is no long-lived access key to leak. Testver vends a short-lived token for your account, refreshes it before each run, and the browser machine’s own credentials are never given to your machine at all.

A clean browser, every time. Each session gets its own isolated machine, and that machine is destroyed when the session ends. Nothing carries over between runs — no profile, no cache, no cookie left behind.

Proof it really ran in the cloud. Every cloud-selected run gets a verdict from the grid itself, not from the test framework’s word for it. A run that quietly fell back to a local browser is flagged loudly in Results instead of passing silently.

Your laptop stays usable. Ten parallel browsers is ten browsers on someone else’s hardware.

How to use it

1. Check that your account has access

Testver Grid comes with the Pro, Power and Team plans; each plan sets how many browsers you may hold at once (see Limits). Open Grid in your Testver account dashboard: if the page shows your connection and usage, you have access. If it says Grid is not part of your plan, upgrade — or ask your Testver administrator, who can also grant access to an individual account outside a plan.

On a team plan, the team shares one Grid pool and only two people may connect it: the team owner, and one member the owner has named platform manager on the Team page. Everyone else on the team sees the Grid page in a read-only “managed by” state and still benefits from the runs the connected tool performs.

You can also check from the app itself — open Testver → Connections and look at the Testver Grid card.

2. Connect

1. Open Testver → Connections in the app (the pinned entry at the bottom of the sidebar) and press Connect to Testver.
2. Approve the connection on testver.com. Testver Grid switches on by itself if your plan includes it — unless another installation already holds your connection, in which case the card names it and offers Take over.
3. That is the whole setup. There is no username or access key to enter. See Testver Connections for the page itself.

The token expires on its own and Testver refreshes it before each run, so you should never have to think about it again.

One installation at a time. Your account (or your team) holds a single Grid connection. If you connect from a second machine, Testver tells you which machine currently holds it and offers Take over here — allowed once the other machine has had no browser running for five minutes, so a live run is never cut mid-way. The machine that lost the connection is told, and simply reconnects to take it back. Disconnect on the Grid page or in the app releases the connection deliberately; a connection that runs no browser for an hour is released for you.

3. Run

1. Open the Runner.
2. Set Run on: to Testver Grid.
3. Press Run. There is no browser to pick: the grid runs whatever browser your framework is configured for. A Playwright --project or the config’s first project decides between Chromium, Firefox and WebKit; Selenium, WebdriverIO and Puppeteer projects keep the browser they set in code. Testver shows the browser it will use next to the Run on chips.

Your unchanged test command executes, output streams live exactly as it does locally, and when the run finishes the session video and logs appear in Results alongside the verdict.

Suites, schedules and CI pipelines can all target the grid the same way.

4. Testing an app on your own machine

If the site under test runs on localhost, switch on the local tunnel for the run. Testver opens an outbound connection from your machine to the grid for exactly as long as the run lasts, so the cloud browser can reach http://localhost:3000 as if it were local.

Nothing is exposed to the internet: no port is opened on your machine, and the tunnel is closed the moment the run ends.

Which browsers run on the grid

Browser	Use it for	Notes
Chromium	Most runs — Selenium, Playwright, WebdriverIO, Puppeteer, and the AI browser	Three version lines are kept: the current one and the two before it, so you can reproduce a report against the browser the user actually had
Firefox	Cross-browser checks; real Firefox for Selenium clients	Selenium gets genuine Firefox with geckodriver; Playwright gets Playwright’s own Firefox build
WebKit	Safari-family rendering checks	Playwright only — this is Playwright’s WebKit, not macOS Safari on a real Mac

Caution

Cypress does not run on Testver Grid. Cypress drives its own bundled browser rather than connecting to a remote one, so there is nothing for the grid to serve. Cypress projects should use Cloud Grid Execution with a vendor that supports Cypress natively, or keep running locally.

What a run looks like afterwards

Every session leaves evidence you can open from Results:

• Video of the browser for the whole session.
• Command log for WebDriver sessions — every command the test sent, in order.
• Cloud execution verdict — confirmation from the grid that a real cloud session existed for this run.
• Live view while a session is still running, if you want to watch it happen.

Tracking your usage

The Grid page in your account dashboard shows what you have actually used, drawn from the grid itself rather than from your own test reports:

• Runs — how many test runs you started.
• Sessions — how many browsers those runs used.
• Browser time — the total time your sessions held a browser.
• Failed sessions — sessions that ended badly, with the share of the total.
• Runs per day, so a sudden change is visible rather than inferred.

Every figure obeys the date filter above it — Today, Yesterday, Last 7 days, Last 30 days, This month, Lifetime, or a range you pick yourself. Ranges shorter than a lifetime also show the change against the period before, so “busier than last month” is a number rather than an impression.

Nothing here is billed per run — your plan sets how many browsers you may hold at once, not how many runs you make. On a team plan the page shows the team’s pool, and the owner and platform manager also see each member’s share; other members see the pool totals and their own rows. Your administrator sees the same figures for every account on the fleet, which means the two views can never disagree about what you did.

Limits

Limit	Value	Why
Browsers at once	Your plan’s pool — Pro 1, Power 2, Team 3 shared by the team (an admin grant is 1 unless set higher). The Runner caps parallel workers to it	The pool is what the plan buys; a team plan is one pool, not one per member
Runs per day	Unlimited	You pay for concurrency, not for volume
Connected installations	One per account or team, with take-over when the holder is idle	One team, one connected Testver — the pool cannot be multiplied across machines
Idle connection	Released after 60 minutes with no browser running	A forgotten laptop should not hold the team’s connection
Session lifetime	30 minutes by default, 2 hours maximum	A session nobody ends still ends
Idle WebDriver sessions	Closed after 2 minutes of no commands	A crashed test client would otherwise hold a browser forever

If a pool is genuinely too small for you, the next plan up is the answer; for unusual needs an administrator can set any number on a custom plan.

FAQ

Do I need a BrowserStack or LambdaTest account? No. That is the point of Testver Grid. If you already have one of those accounts you can keep using it — both appear side by side under Run on:.

Do I have to change my test code? No. Testver injects everything at run time: the hub URL for Selenium, the connect endpoint for Playwright, CDP for Puppeteer. Your project files are untouched.

Which frameworks work? Selenium (any language — Java, Python, C#, JavaScript, Ruby), Playwright, WebdriverIO, Puppeteer, and Testver’s own AI browser. Cypress does not — see the note above.

Can I test a site running on my own machine? Yes, with the local tunnel. No port is opened on your machine and the tunnel dies with the run.

What does it cost? Nothing beyond your plan. Pro, Power and Team include Grid at 1, 2 and 3 browsers at once; runs themselves are not metered or billed.

What happens to my session data? Video and command logs are collected when the session ends and are available from Results. The machine that ran the browser is destroyed at the same moment — nothing of yours stays on it.

Can two people on my team use it at once? The team shares one pool and one connected Testver installation — the owner’s, or the platform manager’s. Runs started from that installation (schedules, pipelines, the Runner) use the pool in parallel up to its size; each browser still runs on its own machine. A second person who connects takes the connection over, so agree on who holds it.

The app says Grid is connected on another machine — what now? Someone else in your account or team holds the connection. Wait until they are idle (five minutes with no browser) and press Take over here, or ask them to Disconnect. If your run was cut because the connection moved, reconnect and it comes back to you.

Why did my run say “executed locally”? Because the grid saw no session for it. Usually the token was not connected, or the project overrides the browser setup in a way that ignores the injected endpoint. Open Testver → Connections and check that the Testver Grid card shows this device as connected, then re-run.

Is my source code uploaded anywhere? No. Your tests run on your machine. Only browser traffic goes to the grid.

What is the difference between Testver Grid and Testver Cloud? Testver Grid runs browsers for tests you launch. Testver Cloud runs Testver itself on an always-on server, so your test environment exists without your laptop. They are independent — you can use either, both, or neither.

Related

• Cloud Grid Execution — the same idea with BrowserStack, LambdaTest or Sauce Labs
• Runner — where you pick where a run executes
• Results — video, logs and the cloud verdict
• Testver Cloud — the always-on hosted Testver workspace