What is a Selenium Grid?

Selenium Grid is the part of the Selenium suite that runs tests across multiple machines and browsers at the same time. Instead of one browser on your laptop, you get a pool of environments that a suite can spread across, which is what makes both parallel execution and broad browser coverage practical.

How does Selenium Grid work?

Your test never addresses a browser machine directly. Every session goes through one entry point:

• Your test sends a new session request, with the capabilities it wants, to the grid endpoint instead of to a local driver.
• The grid matches those capabilities against what each registered machine has advertised.
• If a match is free the session starts there. If everything is busy the request waits in a queue rather than failing immediately.
• The grid remembers which session lives on which machine, so every following command in that test is routed to the same browser.
• When the test quits the driver, the session is torn down and the capacity goes back into the pool.

That indirection is the whole idea: the test does not know or care which machine it landed on, so the same suite runs against one browser locally and hundreds in CI without changing the test code.

Hub and nodes

In its classic form a grid has two roles:

• Hub. The central endpoint your tests talk to. It tracks which nodes exist, what each one can run, and forwards each session request to a node that matches.
• Node. A machine that actually runs browsers. A node registers with the hub and advertises the browsers and platforms it can provide.

Starting a hub

java -jar selenium-server-<version>.jar hub

TestingBot runs a hub at https://hub.testingbot.com/wd/hub, which forwards requests to nodes inside the TestingBot cloud.

Starting a node

java -jar selenium-server-<version>.jar node --hub http://<hub-ip>:4444

Each node needs Java 11 or higher and, more importantly, enough CPU and RAM to run both the node process and the browsers themselves. Browsers are memory-hungry, and an under-provisioned node produces timeouts that look like application bugs. A typical grid mixes operating systems so it can cover:

• Chrome on Windows and macOS
• Edge on Windows and macOS
• Firefox on Windows and macOS
• Safari on macOS

Drivers no longer have to be installed by hand. A node detects the drivers already on the system PATH at startup, and Selenium Manager will fetch and configure them for you when the node is started with --selenium-manager true.

What changed in Selenium Grid 4

Grid 4 kept the hub-and-node model as a deployment option but split the hub's responsibilities into separate components, which can be run together or independently:

• Router, the entry point that forwards each request onward.
• Distributor, which tracks nodes and decides where a new session goes.
• Session Map, which remembers which session lives on which node.
• New Session Queue, which holds requests until capacity frees up instead of rejecting them.
• Event Bus, which the components use to communicate.

Grid 4 offers three ways to deploy this, and the Selenium project ties the choice to the size of the grid:

• Standalone runs every component in one process and is the fastest way to get a grid at all. Suitable for a single machine or a CI runner.
• Hub and node is the familiar two-tier layout, and the usual choice up to roughly 60 nodes.
• Fully distributed runs each component as its own process and is what the project recommends beyond about 100 nodes, where the distributor and session queue become the parts you need to tune.

Selenium Grid or Selenium WebDriver?

They are not alternatives. WebDriver is the API your test is written against, and it drives one browser at a time. Grid is infrastructure that accepts WebDriver traffic and spreads it over many machines. The same test code works both ways: point it at a local driver and it runs one browser locally, point it at a grid endpoint and the identical script runs remotely. Grid adds no test-authoring concepts of its own.

Is Selenium Grid still used?

Yes. Grid ships as part of every Selenium release, and Selenium 4.48 was released in August 2026. What has changed is how it is usually run: far fewer teams hand-build a rack of Windows and macOS machines, and far more run the official container images, a Kubernetes deployment, or a hosted grid. The hub-and-node model people learned years ago is still there underneath all three.

Running a grid in Docker or Kubernetes

The Selenium project publishes official images, which is how most self-hosted grids run today. A single-container grid is one command:

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

Tests then point at http://localhost:4444, and port 7900 serves a browser-in-the-browser view of the session over noVNC, which is the quickest way to see what a failing test is actually doing.

For a multi-container grid, run selenium/hub and attach selenium/node-chrome, selenium/node-firefox or selenium/node-edge containers to it, pointing each node at the hub with the SE_EVENT_BUS_HOST environment variable. The project ships ready-made Docker Compose files for the hub-and-node and fully distributed layouts, and a Helm chart for deploying the same grid to Kubernetes.

One flag matters more than the rest. Any image that bundles a browser needs --shm-size=2g: the default shared memory in a container is 64 MB, and Chrome crashes in ways that read as random test flakiness without it.

Ports a grid uses

Worth knowing before you write firewall rules, because a node that cannot reach the event bus simply never registers and the grid looks empty for no visible reason.

• 4444, the router, which is the endpoint your tests use.
• 4442 and 4443, the event bus, which must be reachable on the hub machine.
• 5553 distributor, 5556 session map, 5559 new session queue, in a fully distributed deployment.

For capacity, the Selenium project's starting point is roughly one CPU and one GB of RAM per concurrent browser session. Treat that as a floor to measure from rather than a target.

Never expose a grid to the internet

A grid is remote code execution by design: anyone who can reach the endpoint can start browsers, read whatever those browsers can read, and reach internal applications from inside your network. The Selenium documentation is explicit that a grid must be protected by appropriate firewall rules, and open grids are found and abused. Bind it to a private network, put it behind a VPN or an authenticating proxy, and never leave port 4444 open to the world.

Common ways a self-hosted grid goes wrong

• Under-provisioned nodes. Browsers consume far more memory than the node process, and the resulting failures present as flaky tests rather than as resource errors.
• Browser and driver drift. An OS-level browser update moves out of step with the installed driver and every session on that node starts failing. Selenium Manager removes most of this, and pinned browser builds remove the rest. See Chrome for Testing for how version pinning helps.
• Leaked sessions. Tests that do not quit their driver leave browsers running until the node degrades.
• Safari capacity. Safari only runs on macOS and allows a single session at a time per machine, so Safari coverage is usually the constraint that decides how much Apple hardware you need.
• No isolation between runs. Reusing a browser profile lets cookies and cached state leak from one test into the next.

Self-host or use a hosted grid

Running your own grid is reasonable when you need full control of the environment, have hardware already, or cannot send traffic outside your network. The cost is not the setup, it is the maintenance: browser updates, driver updates, macOS hardware for Safari, capacity for peak CI load, and someone to debug the grid itself when it is the grid and not the tests that broke.

A hosted grid removes that maintenance and gives elastic capacity, at the cost of running tests on someone else's infrastructure. For most teams the deciding factors are how much Safari and mobile coverage they need, and whether they want to own the upgrade treadmill.

TestingBot runs a hosted Selenium grid of real browsers and real devices, with browser and driver versions kept in step for you, single-use VMs so no state leaks between runs, and video, logs and HAR files captured automatically. Point your existing suite at the hub URL and your capabilities keep working unchanged. Learn more about running Selenium Grid in the cloud.