What Is Selenium Grid?
Selenium Grid lets you run WebDriver tests on remote machines instead of the local host that launched the test. Rather than instantiating a local ChromeDriver or GeckoDriver process, your test creates a RemoteWebDriver pointed at a Grid URL, and the Grid routes that session to a machine with the matching browser and platform installed. This decouples test authoring from test execution, so the same test code can run on a developer laptop, a Linux CI runner farm, or a cloud provider's browser matrix without any changes beyond the target URL.
Cricket analogy: It's like the BCCI assigning a Ranji Trophy match to whichever stadium has the right pitch conditions and ground staff ready, rather than the players deciding themselves which venue to show up at.
Hub and Node Architecture
Selenium Grid 3 used a simple Hub-and-Node model: a single Hub process accepted incoming session requests and forwarded them to registered Nodes, each of which hosted actual browser instances. Selenium Grid 4 replaced this with a fully distributed architecture composed of a Router (the entry point that proxies requests), a Distributor (which tracks Node capacity and assigns sessions), a Session Map (which remembers which Node owns which session ID), a New Session Queue, and an Event Bus that lets these components communicate asynchronously. Grid 4 can run as a single all-in-one Standalone process for simple setups, or as fully separated components for large deployments that need independent scaling.
Cricket analogy: It's like an IPL franchise splitting duties between a chief selector who reviews candidates, a scouting network reporting player availability, and a team manager who confirms final squad assignments, instead of one person doing everything.
Setting Up a Grid
The fastest way to try Grid 4 locally is the Standalone mode: downloading the selenium-server-<version>.jar and running java -jar selenium-server.jar standalone starts a fully self-contained Grid on port 4444 with Router, Distributor, and a Node all bundled into one JVM. For a distributed setup you instead start a Hub-equivalent (--role hub in Grid 3, or java -jar selenium-server.jar hub in Grid 4's classic mode) and register separate Node processes against it with java -jar selenium-server.jar node --hub http://hub-host:4444, each Node advertising the browsers and driver binaries installed on its host.
Cricket analogy: It's like a franchise deciding between fielding a full squad from one academy for a quick exhibition match versus scouting and registering players from academies across the country for the full IPL season.
# Start an all-in-one Grid 4 Standalone server
java -jar selenium-server-4.20.0.jar standalone --port 4444
# Distributed mode: start the hub
java -jar selenium-server-4.20.0.jar hub
# Register a Chrome node against the hub
java -jar selenium-server-4.20.0.jar node \
--hub http://192.168.1.10:4444 \
--detect-drivers true
# Point a test at the Grid instead of a local driver
from selenium import webdriver
from selenium.webdriver.chrome.options import Options
options = Options()
options.set_capability("browserName", "chrome")
driver = webdriver.Remote(
command_executor="http://192.168.1.10:4444/wd/hub",
options=options
)
driver.get("https://example.com")
driver.quit()Capabilities and Node Matching
When a test requests a session, it sends a set of desired capabilities such as browserName, browserVersion, and platformName. The Grid's Distributor compares these against the capabilities each registered Node advertised at startup and assigns the session only to a Node that can satisfy the request; if no Node matches, the session waits in the New Session Queue until one becomes available or the request times out. This capability-matching model is what lets a single Grid host a heterogeneous mix of Chrome, Firefox, and Edge nodes across different operating systems while tests simply declare what they need.
Cricket analogy: It's like a tournament organizer only sending a fast bowler to a green, pace-friendly pitch at the WACA rather than a flat batting track, matching player skill to conditions before confirming the fixture.
Grid 4's Router component is protocol-transparent: once a session is created, all subsequent WebDriver commands for that session ID are proxied directly to the owning Node via the Session Map, so your test code never needs to know which physical machine is actually running the browser.
Scaling and Session Queueing
Because each Node has a finite session capacity (commonly limited to avoid oversubscribing CPU and memory), a busy Grid will queue incoming session requests rather than reject them outright. The --session-request-timeout and --session-retry-interval flags control how long a request waits in queue before failing, and --max-sessions on a Node caps concurrent browser instances per machine. In production deployments this queueing behavior is often paired with autoscaling infrastructure, such as a Kubernetes Horizontal Pod Autoscaler watching queue depth, so new Node pods spin up automatically when demand spikes and scale back down when the suite finishes.
Cricket analogy: It's like a stadium's ticket queue during an India versus Pakistan World Cup match, where fans wait in line rather than being turned away, and the venue opens extra gates when the queue grows too long.
Distributed Grid deployments are sensitive to network configuration: if Nodes and Hub/Router sit behind different firewalls or NAT boundaries, the Node must be started with a publicly reachable --publish-events and --subscribe-events bus address, otherwise sessions can appear to hang indefinitely even though capabilities matched successfully.
- Selenium Grid routes RemoteWebDriver sessions to remote machines based on requested capabilities.
- Grid 4 splits responsibilities into a Router, Distributor, Session Map, New Session Queue, and Event Bus.
- Standalone mode bundles all Grid 4 components into a single process for simple local setups.
- Distributed mode registers separate Node processes against a Hub for larger, scalable deployments.
- Capability matching (browserName, browserVersion, platformName) determines which Node a session is assigned to.
- Session requests queue rather than fail immediately when all matching Nodes are busy.
- Network reachability between Hub/Router and Nodes is critical for the Event Bus to function correctly.
Practice what you learned
1. In Selenium Grid 4's distributed architecture, which component is responsible for tracking which Node currently owns a given session ID?
2. What happens when a session request's capabilities don't match any currently available Node?
3. Which command starts a self-contained Grid 4 server bundling Router, Distributor, and a Node into one process?
4. What capability field is used to request a specific browser like Chrome or Firefox on the Grid?
5. Why might a session appear to hang even though the Grid successfully matched capabilities to a Node?
Was this page helpful?
You May Also Like
Cross-Browser Testing
Learn how to write and run Selenium tests that validate application behavior consistently across Chrome, Firefox, Edge, and Safari.
Parallel Test Execution
Speed up Selenium suites by running multiple tests concurrently across threads, processes, or Grid nodes without sessions interfering with each other.
Selenium in CI/CD Pipelines
Integrate Selenium test suites into continuous integration pipelines so UI regressions are caught automatically on every commit or pull request.