Selenium Grid

Visit Website

Introduction

Selenium Grid is the part of the Selenium project that lets you run WebDriver tests on remote machines. Test code connects to a single Grid URL, asks for a browser with certain capabilities, and the Grid routes the session to a node that can provide it. That makes it possible to run many tests in parallel and to cover browsers and operating systems that are not on the developer’s laptop or CI runner.

Grid 4, the current generation, was rebuilt as a set of components: a Router that receives requests, a Distributor that assigns sessions to nodes, a Session Map, a New Session Queue, an Event Bus and the Nodes that run browsers. You can run all of this in one process (standalone), in the classic hub-and-node layout, or fully distributed, with each component scaled separately. The same Selenium server jar provides every role.

Because Grid speaks the W3C WebDriver protocol, any Selenium client works with it, in Java, Python, C#, JavaScript, Ruby and other languages, as do frameworks built on WebDriver such as WebdriverIO, Selenide, Robot Framework’s SeleniumLibrary and Nightwatch. Nodes can run Chrome, Edge, Firefox and Safari (on macOS).

Operationally, Grid 4 exposes a web UI that shows nodes, slots and running sessions, a GraphQL endpoint for querying status, and OpenTelemetry-based tracing for observability. Nodes can be configured with TOML files, and a Docker-based ‘dynamic grid’ can start a fresh browser container for each session. The companion Docker Selenium project packages the Grid and browsers as container images and provides a Helm chart for Kubernetes, including autoscaling with KEDA.

Selenium Grid is part of the main Selenium repository, one of the most popular testing projects on GitHub (about 34,600 stars). The project released Selenium 4.52.0 on 29 October 2026, and Grid ships in step with the client libraries.

In the quality loop, Grid is infrastructure for the end-to-end stage. Teams choose it when they want to keep browser execution in-house for cost, data residency or network-access reasons, instead of renting a cloud grid. The trade-off is that you own the machines, browser versions and stability. Cloud grids such as BrowserStack, Sauce Labs or LambdaTest, and container-first alternatives such as Moon, are the common alternatives.

The source code is at SeleniumHQ/selenium on GitHub under the Apache-2.0 licence, with about 34,600 stars; the most recent commit was on 11 November 2026.

Features

1. Parallel execution: Run many WebDriver sessions at once across nodes.
2. Flexible topology: Standalone, hub and node, or fully distributed components.
3. Any WebDriver client: Java, Python, C#, JavaScript, Ruby and frameworks built on WebDriver.
4. Cross-browser nodes: Chrome, Edge, Firefox and Safari on macOS nodes.
5. Web UI: See nodes, slots and live sessions, with session viewing via VNC in Docker setups.
6. GraphQL status: Query grid state for dashboards and automation.
7. OpenTelemetry tracing: Trace sessions across Grid components.
8. Dynamic grid: Start a fresh Docker container per session.
9. TOML configuration: Version-controlled node and component settings.
10. Kubernetes: Helm chart and autoscaling through the Docker Selenium project.

Pros

1. Self-hosted control: Keep browsers inside your network and budget.
2. Standard protocol: Works with the whole WebDriver ecosystem.
3. Free to use: Open source under the Apache-2.0 licence, so the core tool costs nothing to use.
4. Actively maintained: The repository had commits as recent as 11 November 2026.
5. Community: About 34,600 GitHub stars.

Cons

1. Operations burden: You maintain machines, browser versions and capacity.
2. Flakiness at scale: Under-provisioned nodes and network issues show up as test failures.
3. No real mobile devices: Mobile needs Appium nodes or a device cloud.
4. Learning the components: Distributed mode has many moving parts to configure.

Usage and Links (Example)

Start a standalone Grid locally (requires Java):

java -jar selenium-server-4.52.0.jar standalone

Or with Docker:

docker run -d -p 4444:4444 --shm-size=2g selenium/standalone-chrome

Point tests at the Grid:

from selenium import webdriver
options = webdriver.ChromeOptions()
driver = webdriver.Remote(command_executor="http://localhost:4444", options=options)
driver.get("https://example.com")
assert driver.title == "Example Domain"
driver.quit()

Practical tips:

1. Use Docker images and pin browser versions so runs are reproducible.
2. Size nodes for one or two sessions per CPU core; overloaded nodes cause flaky tests.
3. Watch the Grid UI and queue length in CI to spot capacity problems.
4. On Kubernetes, use the Docker Selenium Helm chart with autoscaling.

Resources:

• Selenium Grid website
• GitHub repository

Pricing

Selenium Grid is free and open source under the Apache-2.0 licence.

Recommended for?

1. Teams that want to run browser tests on their own infrastructure.
2. Organisations with data residency or private-network requirements.
3. Large WebDriver suites that need parallelism.
4. Not a fit if you want zero operations work or real mobile devices; use a cloud grid.

Conclusion

Selenium Grid is the standard open-source way to scale WebDriver tests across browsers and machines. Grid 4’s component design, observability and Docker and Kubernetes support make it a capable platform for teams willing to run it.

Its cost is operational. Teams that can invest in stable infrastructure get full control and no per-minute fees; teams that cannot are usually better served by a managed grid.

On CheckOps, Selenium Grid is filed under the End-to-end & functional stage. Related tools listed here include Docker Selenium, Moon, Browserless, Selenium, BrowserStack and Sauce Labs. Before choosing, compare them on licence, supported languages and platforms, hosting model, and how well each fits your existing CI pipeline. Facts on this page were checked against the official website, documentation and repository on 11 November 2026; statements the vendor makes about its own product are marked as vendor claims.