Included with Pro, Power and Team plans

Cloud browsers, without a vendor account

Run your existing suite on Chromium, Firefox and WebKit in the cloud — no third-party grid to sign up for, and not a line of test code to change.

Chromium · Firefox · WebKitNo vendor keysNo code changesSession videoCommand logReaches your localhost
Testver — Runner
Run onTestver GridChromiumFirefoxWebKit
checkout.spec.tsChromium
login.spec.tsFirefox
search.spec.tsWebKit
Cloud execution verified — 3 sessions on the grid
Browser engines
3Browser enginesChromium, Firefox, WebKit
Browsers at once
1–3Browsers at oncePro 1 · Power 2 · Team 3
Vendor accounts
0Vendor accountsand no access keys
Lines changed
0Lines changedyour suite runs as-is

Running browsers in the cloud usually means an account with a grid vendor, a set of keys in your CI secrets, a capabilities block in your config, and a bill that scales with something you cannot easily predict.

Testver Grid is a browser fleet built into Testver. Pick it next to Run on, choose a browser, and press Run. Your unchanged test command executes against the fleet, and the video, the command log and the evidence come back into the same reports you already read.

The grid is rarely the hard part — the paperwork around it is

Most teams do not want a browser grid. They want their suite to run on three browsers at once without their laptop becoming unusable. The usual route adds a vendor between them and that.

  • A separate account, plan and invoice for something that is one step in your pipeline.
  • Access keys to distribute, rotate and keep out of your repository.
  • Vendor-specific capabilities baked into test config that then only runs there.
  • Ten parallel browsers meaning ten browsers on your own machine.
Getting started

How Testver Grid works

Four steps, in order — and none of them is a migration.

  1. 1

    It comes with your plan

    Pro, Power and Team include the grid. The moment the plan is active it appears in your Testver dashboard with your pool size and usage; an administrator can also grant it to an individual account.

  2. 2

    Connect, once

    Press Connect. Testver exchanges your session for a short-lived grid token and refreshes it before each run. There is no username or access key to enter. One installation holds the connection for your account or team; another machine can take it over once the first has gone idle.

  3. 3

    Choose the grid in the runner

    Set Run on to Testver Grid and pick Chromium, Firefox or WebKit. Everything else about your run stays exactly as it was.

  4. 4

    Run, and read the evidence

    Output streams live as it does locally. When the run finishes, the session video and logs sit in Results next to the verdict.

What you get

Everything Testver Grid handles for you

Three real browsers

Chromium, Firefox and WebKit, on machines that are not yours. Your laptop stays usable while your whole pool of browsers is busy.

Nothing to rewrite

Selenium and Playwright suites run unmodified — Testver supplies the connection at run time rather than asking you to hard-code a vendor into your config.

Video and command log

Every session is recorded, and WebDriver sessions keep an ordered log of every command the test sent. Both open from the run’s report.

Proof it really ran there

Each cloud run carries a verdict from the grid itself. A run that quietly fell back to a local browser is flagged loudly instead of passing silently.

Reaches the app on your machine

Testing something that only exists on localhost still works. Every hop is an outbound connection, so nothing new is exposed on your network.

Watch it happen

Open a live view of a session while it is still running, when you would rather see the failure than read about it afterwards.

The part most grids leave out

Evidence, not just a pass

A cloud run you cannot inspect is a claim. Every session on the grid comes back with the material to check what actually happened — in the same report you already open.

  • Video of the session

    The whole browser session, recorded, and playable from the run that produced it.

  • Every command, in order

    WebDriver sessions keep an ordered log of what the test sent, so a failure can be read rather than guessed at.

  • Proof it ran in the cloud

    The grid itself returns a verdict. A run that quietly fell back to a local browser is flagged, not passed.

  • Live view while it runs

    Watch a session in progress when seeing the failure beats reading about it afterwards.

Side by side

The usual route, and this one

A third-party grid

Testver Grid

A separate account, plan and invoice
Part of Testver — nothing else to buy
Access keys in your CI secrets
A short-lived token Testver refreshes for you
Vendor capabilities baked into test config
Connection supplied at run time — config untouched
Evidence in a second dashboard
Video and logs in the report you already read
Localhost needs a tunnel agent you install
Reaches your localhost, all outbound

The specifics, stated up front

Browsers
Chromium, Firefox, WebKit
Frameworks
Selenium and Playwright suites, unmodified
Browsers at once
Your plan’s pool — Pro 1, Power 2, Team 3 shared by the team
Runs per day
Unlimited — you pay for concurrency, not volume
Connected installations
One per account or team; take-over once the holder is idle
Session lifetime
30 minutes by default, 2 hours maximum
Price
Included with your plan — nothing metered per run

Need more than three browsers at once? The pool is a number we set per plan, not a ceiling in the product — talk to us about a custom plan.

Questions

Testver Grid, answered

Do I need an account with a grid vendor?

No. There is no third-party account, no access key, and nothing to add to your CI secrets. The grid is part of Testver.

Do I have to change my tests?

No. Testver supplies the connection details to your runner at run time, so the same suite runs locally or on the grid without a config change.

Can it test an application running on my own machine?

Yes. A cloud browser can reach an app on your localhost, and every hop in that path is an outbound connection — nothing new is opened up on your network.

How do I know the run really used a cloud browser?

Every cloud-selected run gets a verdict from the grid itself. If a run silently fell back to a local browser, it is flagged rather than passing quietly.

What does it cost?

Your plan includes a number of browsers at once — today Pro 1, Power 2, Team 3 — and offers parallel-browser add-ons if you need more, up to the plan’s cap. An add-on is prepaid for the rest of your plan’s term and renews with the plan; runs themselves are never metered or billed. The pricing page lists the exact figures.

How do I get access?

Once a plan that includes Grid is active it appears in your dashboard — press Connect in Testver and choose it in the runner. If your plan offers Grid as an add-on instead, buy the browsers you need from the Grid page or Billing → Add-ons. Administrators can also grant access to an individual account.

Can my whole team use it?

A team plan is one shared pool of browsers and one connected Testver installation — the team owner’s, or a member the owner names platform manager. Runs from that installation use the pool in parallel, and everyone on the team sees the usage.

Ready to upgrade your test suite?

Keep your framework. Add AI and a premium toolset.

Set up in minutes. Self-host on your own hardware. Describe a test in plain English and get working code in your own framework — in a fraction of the time.