What’s New in Selenium 4 Grid: Features and Setup
Learn what Selenium Grid 4 changes, choose Standalone, Hub and Node, or Distributed mode, and start a secure Grid with runnable examples.
Selenium Grid routes WebDriver commands to remote browser instances so tests can run in parallel across machines, browsers, and operating systems. For local development or a small CI run, start Standalone; choose Hub and Node to combine browser machines behind one entry point; choose Distributed when you need to operate Grid components separately. Grid 4’s main architectural change is its component based design, with built in tracing; later releases add version specific improvements. [Selenium’s Grid overview](https://www.selenium.dev/documentation/grid/) describes its goal as running tests in parallel across multiple machines.
1. What Selenium Grid 4 does
A WebDriver client sends commands to the Grid URL. The Grid finds a browser slot with matching capabilities, starts or reuses a session as appropriate, and routes commands to the machine running that session. A Grid is useful when you need parallel test execution, multiple browser versions, or cross platform coverage that is impractical on one machine.
Grid 4 is a ground up rewrite that separates responsibilities into components. The Router is the client entry point. A new session request enters the New Session Queue; the Distributor finds a compatible Node and slot. The Session Map tracks which Node owns an active session, while the Event Bus carries internal messages. Nodes run the actual browser sessions. This architecture supports multiple deployment shapes, but does not itself guarantee faster tests: throughput depends on available browser slots, machine resources, test behavior, and queueing.
2. What is new, and when it arrived
Separate foundational Grid 4 architecture from improvements that were introduced in later releases. Do not assume that a feature in a recent release announcement exists in every Selenium 4 server. Check the release notes and the help output from the JAR you actually run.
| Area | What it means | Version context |
|---|---|---|
| Component architecture | Grid responsibilities are split among Router, Distributor, Session Map, New Session Queue, Event Bus, and Nodes. This enables Standalone, Hub and Node, and Distributed deployment patterns. | Core Grid 4 design. [Components](https://www.selenium.dev/documentation/grid/components/) |
| Observability | OpenTelemetry tracing follows requests through Grid components. Traces, logs, and metrics help investigate where a distributed request stalls or fails. | Documented Grid 4 capability; tracing is enabled by default. Export and visualization setup is version/configuration dependent. [Observability guide](https://www.selenium.dev/documentation/grid/advanced_features/observability/) |
| WebSocket Router changes | Transparent TCP tunnel bypass, handling for dropped close frames and idle disconnects, and a pluggable NodeCommandInterceptor loaded through --ext. |
Called out in Selenium 4.42, released April 9, 2026. [4.42 release notes](https://www.selenium.dev/blog/2026/selenium-4-42-released/) |
| Dynamic Grid on Kubernetes | Per session video subfolders and inherited Node Pod security context were among the changes. | Called out in Selenium 4.47, released August 10, 2026. These Dynamic Grid details are not required for a basic local Grid. [4.47 release notes](https://www.selenium.dev/blog/2026/selenium-4-47-released/) |
These examples are selected release highlights, not a complete changelog. Consult the [Selenium releases](https://www.selenium.dev/blog/) for the release you are upgrading to. The currently published CLI options page can describe flags added after an older installed version, so validate each flag with that version’s own --help output.
3. Choose a Grid deployment mode
| Mode | Use it when | Tradeoffs |
|---|---|---|
| Standalone | Local RemoteWebDriver development, debugging, or a quick small CI suite. | One process on one machine; simplest setup and a single endpoint. |
| Hub and Node | You want one client endpoint and browser capacity across machines or operating systems. | The Hub coordinates; each Node must reach the Hub’s Event Bus and be reachable for registration and traffic. |
| Distributed | You need to start and operate Grid components individually, often across hosts. | Most control and most networking/configuration work. Components must be able to communicate on the required ports. |
The official [getting started guide](https://www.selenium.dev/documentation/grid/getting_started/) notes there is no one size fits all capacity plan. Its rough reference of 1 CPU and 1 GB RAM per browser is a starting point only, not a guaranteed minimum or benchmark. Measure your actual test mix and machine utilization.
4. Start a local Standalone Grid
Prerequisites
- Java 11 or higher.
- The browser or browsers you want to run.
- Browser drivers available on
PATH, or use Selenium Manager with--selenium-manager true. - The Selenium Server JAR for the version you intend to use. Download it from the [official Selenium downloads page](https://www.selenium.dev/downloads/).
Start the server
java -jar selenium-server-<version>.jar standalone --selenium-manager true
Replace <version> with the downloaded JAR version. The documented default endpoint is http://localhost:4444. Open that address to view the Grid UI; check http://localhost:4444/status for server status. Keep the terminal running while tests use the Grid.
Run a Java RemoteWebDriver example
Add Selenium Java to a Maven project. Replace the dependency version with the binding version you use, preferably aligned with your Grid release.
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-java</artifactId>
<version>4.48.0</version>
</dependency>
import java.net.URI;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeOptions;
import org.openqa.selenium.remote.RemoteWebDriver;
public class GridSmokeTest {
public static void main(String[] args) throws Exception {
ChromeOptions options = new ChromeOptions();
WebDriver driver = new RemoteWebDriver(
URI.create("http://localhost:4444").toURL(), options);
try {
driver.get("https://example.com");
System.out.println(driver.getTitle());
} finally {
driver.quit();
}
}
}
The example requests a Chrome slot. For Firefox, use FirefoxOptions; a remote session requires that a compatible browser capability is advertised by an available Node.
Python client
python -m pip install selenium
from selenium import webdriver
from selenium.webdriver.chrome.options import Options
options = Options()
driver = webdriver.Remote(
command_executor="http://localhost:4444",
options=options,
)
try:
driver.get("https://example.com")
print(driver.title)
finally:
driver.quit()
Node.js client
npm install selenium-webdriver
const { Builder } = require('selenium-webdriver');
const chrome = require('selenium-webdriver/chrome');
(async () => {
const options = new chrome.Options();
const driver = await new Builder()
.usingServer('http://localhost:4444')
.forBrowser('chrome')
.setChromeOptions(options)
.build();
try {
await driver.get('https://example.com');
console.log(await driver.getTitle());
} finally {
await driver.quit();
}
})();
Check the Grid with cURL
curl --fail --silent --show-error http://localhost:4444/status
The status response helps confirm the server is reachable. It does not prove that a requested browser is installed or that a matching slot is free; verify those through the UI and an actual session request.
5. Add Nodes with Hub and Node
Run the Hub on the machine clients can reach:
java -jar selenium-server-<version>.jar hub
On each browser machine, start a Node. If it can reach the Hub at the default ports:
java -jar selenium-server-<version>.jar node --hub http://<hub-ip>:4444
Replace <hub-ip> with the Hub host address reachable from the Node. The Hub uses port 4444 for WebDriver requests by default and Event Bus ports 4442 and 4443 for Node communication. Network rules must permit the required component traffic. For Nodes on the same machine, the documented examples assign distinct Node ports:
java -jar selenium-server-<version>.jar node --port 5555
java -jar selenium-server-<version>.jar node --port 6666
When changing Hub ports, configure matching publish and subscribe Event Bus addresses on both sides. Use the exact options shown by the installed JAR’s hub --help and node --help. Confirm each Node registers in the Grid UI and advertises the browser capabilities your clients request.
6. Distributed mode and networking
Distributed mode starts each component separately. The Event Bus is started first; the other services need correct addresses for the Event Bus, New Session Queue, Session Map, Distributor, and Router. Documented defaults include Event Bus ports 4442, 4443, and 5557, New Session Queue port 5559, Session Map port 5556, Distributor port 5553, Router port 4444, and Node port 5555. Defaults are deployment references, not a recommendation to expose all ports publicly.
Because every component needs the right address and ports, a copy and paste distributed setup is easy to misconfigure. For every host, document which component listens there, which peers need to connect, and whether advertised addresses resolve from those peers. Follow the official [Distributed setup instructions](https://www.selenium.dev/documentation/grid/getting_started/) and each role’s help output for complete commands and version-specific flags.
7. Configuration, capacity, and observability
Discover options from the installed JAR
Help commands reflect the code in the JAR and can be more current than prose documentation. Run:
java -jar selenium-server-<version>.jar info config
java -jar selenium-server-<version>.jar info security
java -jar selenium-server-<version>.jar info sessionmap
java -jar selenium-server-<version>.jar info tracing
java -jar selenium-server-<version>.jar --config-help
java -jar selenium-server-<version>.jar standalone --help
java -jar selenium-server-<version>.jar node --help
Grid uses a local Session Map by default; the configuration help also describes Redis and JDBC SQL storage options. Check the installed version’s instructions before selecting an external store or assuming behavior across restarts.
Capacity and stability
- Begin with fewer concurrent sessions, then increase concurrency while watching queue time, CPU, memory, and browser failures.
- Give each test its own WebDriver session and always call
quit()in a cleanup path so slots are returned. - Use compatible Selenium versions and matching browser capabilities across Nodes; avoid asking for a browser/version that no slot advertises.
- Separate infrastructure delays from test delays. A long new-session wait can mean all matching slots are busy, a Node is unreachable, or a capability mismatch.
- Do not treat CPU/RAM guidance or rough Grid-size categories as hard capacity guarantees. Workload, page weight, browser, and test behavior change the result.
Tracing and debugging
Grid is instrumented with OpenTelemetry tracing and tracing is enabled by default. Traces follow a request across components; logs provide event and error context. To see the available export/Jaeger setup for your version, run info tracing. The [observability documentation](https://www.selenium.dev/documentation/grid/advanced_features/observability/) explains traces, spans, and event logs. Grid also documents GraphQL query support and management endpoints; consult the advanced features docs before building monitoring around them.
8. Security checklist
A publicly reachable Grid can give outsiders a path to the Grid host and internal web applications or files, and can allow custom binaries to run. Selenium explicitly warns operators to protect Grid from external access. Keep it on a private network or behind suitable firewall rules; allow only trusted test clients and component peers. Configure secure communication and Node registration using info security and the security options available in the installed release. Do not expose Event Bus or internal component ports to the public internet.
9. Troubleshooting
| Symptom | Likely cause | What to check or fix |
|---|---|---|
| Connection refused at port 4444 | Server is stopped, listening elsewhere, or the client cannot reach its host. | Check the server process and startup log; test /status locally; verify host, port, and firewall rules. |
| Session request times out or remains queued | No free slot matches the requested browser/capabilities, or Nodes are unavailable. | Inspect Grid UI and Node registration; compare client capabilities with advertised slots; reduce concurrency or add matching capacity. |
| Node does not register | Hub address, Event Bus ports, advertised Node address, or network reachability is wrong. | Check both publish/subscribe configuration and bidirectional component reachability; use role-specific --help. |
| Browser driver or browser cannot start | Browser/driver missing, incompatible, or not available to the Node process. | Install the browser, put its driver on PATH, or enable Selenium Manager; inspect Node logs and capabilities. |
| Works locally but not from another host | Client still targets localhost, or firewall/bind/advertised addresses prevent remote access. | Use the reachable Grid hostname and verify routing and access rules. Localhost means the client machine itself. |
| Port conflict starting multiple local Nodes | More than one process tries to bind the same port. | Assign distinct Node ports and configure any related Event Bus options required by the layout. |
| Newer CLI option is rejected | The option belongs to a later server version or differs in that release. | Use the exact JAR’s --config-help or component --help; align deployment docs with the version in use. |
| Sessions leak and capacity gradually disappears | Tests skip session cleanup after success or failure. | Put driver.quit() in finally or equivalent teardown and monitor for abandoned sessions. |
| Tracing data is not visible in the backend | Tracing may be enabled but exporter/backend configuration is incomplete, or logs are below the needed verbosity. | Run info tracing for version specific setup and check Grid logs and exporter connectivity. |
10. Cost and performance notes
Selenium Grid is server software; this setup guide does not imply a Selenium license charge. Operating cost comes from the machines or container infrastructure, browser capacity, storage, network traffic, and the engineering time required to secure and maintain the Grid. Adding Nodes can increase parallel capacity only when suitable resources and matching browser slots are available. Benchmark your own workload rather than relying on generalized concurrency claims.
For screenshot-only jobs, running a full WebDriver browser stack can be more setup than the task needs. ScreenshotNeo is a hosted website screenshot API and MCP server; it does not replace Selenium for browser automation or interactive testing.
Or skip the browser setup
If the job is to capture a website image or PDF, [ScreenshotNeo](https://screenshotneo.com) provides a one-call screenshot API. See the [API documentation](https://screenshotneo.com/docs/) for request options.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp
import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)
const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
- Cookie banners, popups, and chat widgets are removed before the shot.
- Bot checks, blank pages, and failed loads are never billed.
- An MCP server lets AI agents use screenshot tools.
- 1,000 screenshots a month are free with no card; paid plans start at $5 for 3,000.
Sign up for 1,000 free screenshots a month, no card required.
FAQ
Does Grid 4 require Selenium tests to run in Java?
No. Grid is a remote WebDriver server; clients can use Selenium bindings such as Java, Python, and JavaScript and connect to the Grid URL.
Can a Node use a different operating system from the Hub?
Yes. Nodes can provide browser environments on different machines and operating systems; the Hub and Nodes communicate over the configured network.
Is Standalone appropriate for production?
It is documented for local development, debugging, and quick CI suites. Choose an architecture based on the scale, isolation, availability, and operational requirements of your environment, and secure every deployment.
Does a new Selenium 4 release automatically update a running Grid?
No. The server JAR and Node processes run the versions you deploy. Upgrade deliberately and verify flags and release changes against the target version’s official notes.


