Capabilities
What capabilities are, the few you need to start, and the rest of them one line at a time.
A capability is a note you attach to your test saying what machine you want and what you want kept. You send them once, when the test connects. We read them, hand you a browser, and start recording whatever you asked for.
Nothing here is set up in advance. There is no dashboard to configure first — every session is described entirely by the capabilities your test sends.
Your access key
The one thing every session needs. It is how we know the session is yours — copy it from the Access key page.
There are two places you can put it. Either is fine — pick one:
// in the capabilities
"testkase:options": { accessKey: "xyz_your_access_key_here" }
// or in the address you connect to
"https://x:[email protected]/wd/hub"Most examples use the address, because that is the shape every Selenium tutorial already uses. The x in front of the key is a placeholder for a username we do not need.
Choosing the machine
Three capabilities decide what you get. They sit at the top, next to each other.
| Capability | What it does | Example |
|---|---|---|
browserName | Which browser. The only one you must send. | {"browserName": "chrome"} |
browserVersion | Which version of it. Leave it out for the newest. | {"browserVersion": "latest-1"} |
platformName | Which operating system. Leave it out for the newest macOS. | {"platformName": "windows 11"} |
The four you will actually use
Everything below goes inside testkase:options, like the access key above.
| Capability | What it does | Example |
|---|---|---|
name | What this session is called in your dashboard. Without it, sessions are hard to tell apart. | {"testkase:options": {"name": "Checkout — guest"}} |
recording | Records a video of the session. You get no video unless you ask for it. | {"testkase:options": {"recording": true}} |
runId | Groups sessions together. Give every test in one CI job the same value and they appear as a single run instead of fifty separate ones. | {"testkase:options": {"runId": "ci-8891"}} |
build | A label, like a version number, shown next to the session. Unlike runId, it does not group anything. | {"testkase:options": {"build": "nightly-42"}} |
The rest
You will not need these on day one.
| Capability | What it does | Example |
|---|---|---|
tags | Your own labels on a session, so you can find it later. | {"testkase:options": {"tags": ["smoke", "checkout"]}} |
console | Keeps whatever your site printed to the browser console. Already on. | {"testkase:options": {"console": false}} |
network | Keeps a log of every network request the page made. Already on. | {"testkase:options": {"network": false}} |
driver | Keeps the log from the thing that drives the browser. Useful when a test fails for no clear reason. Already on. | {"testkase:options": {"driver": false}} |
test | Keeps what your own test printed. Already on. | {"testkase:options": {"test": false}} |
resolution | How big the browser window is. | {"testkase:options": {"resolution": "1440x900"}} |
idleTimeout | How long your test may go quiet before we assume it died and stop it. Five minutes by default, up to twenty. | {"testkase:options": {"idleTimeout": 900}} |
maxQueueWaitSeconds | How long to wait for a free machine before giving up. 2 minutes 50 by default on Selenium, up to 9 minutes. Waiting is free. | {"testkase:options": {"maxQueueWaitSeconds": 450}} |
tunnel | Tests a site running on your own computer, not a public one. See Local testing. | {"testkase:options": {"tunnel": "office"}} |
Not every browser can keep all four — Safari has no console or network logs at all. See What each browser records.
Waiting for a free machine
If every matching machine is busy, your session waits in the queue until one frees up. The default wait is 2 minutes 50.
To wait longer, raise Selenium's own timeout as well — it stops waiting after 3 minutes by itself:
ClientConfig config = ClientConfig.defaultConfig()
.baseUri(new URI(HUB_URL))
.readTimeout(Duration.ofMinutes(10));
RemoteWebDriver driver = new RemoteWebDriver(new HttpCommandExecutor(config), caps);{"testkase:options": {"maxQueueWaitSeconds": 450}}Questions
▶Which browser names and versions can I write?
chrome, edge, firefox and safari. chromium also means Chrome, and MicrosoftEdge means Edge. Anything else is refused.
For the version: latest is the newest we have, latest-1 is one behind, or name a major like 142. For the platform: name the operating system with its major version, like macOS 26 or windows 11 — and say which Windows, because plain windows is refused. Capital letters never matter.
The generator only offers combinations that exist right now, which is safer than typing them.
▶Can I run headless?
Not here. Headless works only with Playwright, because that is the one where we start the browser for you — with Selenium, your own code does.
▶Which language and framework can I use?
Any that speaks WebDriver, which is nearly all of them. There is no library of ours to install: the official Selenium client for Java, Python, JavaScript, C#, Ruby or PHP connects directly, and so does anything built on top of them — TestNG, JUnit, pytest, RSpec, PHPUnit, NUnit, Mocha, Cucumber, Robot Framework.
Cypress and TestCafe drive browsers their own way rather than through WebDriver, so they cannot connect here.
▶Is there a username capability?
No. The access key is the only thing that signs you in. If you have a username left over from another service's config, delete it.
▶What ends a session besides my own code?
Two clocks: two hours in total, and five minutes of going quiet. Both are there to stop a stuck test holding a machine, and you can raise the quiet one with idleTimeout.