Selenium Grid 4 Tutorial

Many testers assume running Selenium tests across browsers becomes straightforward once scripts work locally. Set up the environment, trigger execution, and expect consistent results across machines.

That expectation collapses the moment tests move beyond a single setup. Scripts that pass locally start failing elsewhere, execution timing becomes unpredictable, and platform differences introduce flakiness that is difficult to diagnose or reproduce.

Selenium Grid 4 was introduced to address a deeper problem than parallel execution. It rethinks how test sessions are created, routed, and observed across environments, turning distributed testing from an operational risk into a system that can be understood, controlled, and scaled with confidence.

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

In this article, I will guide you through Selenium Grid 4, showing how to run tests efficiently across multiple browsers and platforms.

What is Selenium Grid 4?

Selenium Grid is a smart proxy server that makes it easy to run tests in parallel on multiple machines and manages different browser versions and browser configurations centrally (instead of separately, in individual tests).

Can't Test Old Safari or Edge on Local Grid?

Installing legacy & beta browsers locally is complex. Access cloud Grid with 3500+ browser/OS combinations.

Test Across Browsers

Selenium Grid 4 is a fresh implementation and does not share the codebase of the previous version. Grid 4 takes advantage of new technologies in order to facilitate scaling up, while still allowing local execution.

How Selenium Grid 4 Works

Selenium Grid 4 executes tests by decoupling test requests from browser execution, allowing sessions to be routed dynamically across available machines. Instead of binding tests to a fixed setup, Grid 4 treats execution as a distributed system.

At a high level, this is how a test moves through the Grid during execution:

• Session request submission: The WebDriver client sends a new session request to the Grid endpoint with browser and platform capabilities.
• Request routing: The Router receives the request and places it into the New Session Queue until matching resources are available.
• Node selection: The Distributor evaluates registered Nodes and selects one that can satisfy the requested capabilities.
• Session registration: The selected session is recorded in the Session Map, creating a persistent mapping between the test and the Node.
• Command execution: All subsequent WebDriver commands are routed to the same Node, which executes them on the browser instance.
• State synchronization: The Event Bus propagates execution and availability updates across Grid components in real time.

Selenium Grid 4 Features

Selenium Grid 4 introduces a range of enhancements and architectural changes that make it more powerful, scalable, and easier to manage than previous versions.

Architecture Support

From Selenium 2, the Grid consisted of two processes – Hub and Nodes. Selenium 4 architecture supports four distinct processes – Router, Session Map, Distributor, and Node.

Different Grid Types

Selenium 4 supports three grid types:

• Standalone Mode
• Classical Grid (Hub and Node)
• Fully Distributed (Router, Distributor, Session, and Node)

Docker Support

Grid 4 offers Docker support. The Docker integration does not use Unix domain sockets, so users need to make sure that the daemon is listening on port 2375.

When compared to Selenium Grid 3, this version is easier to use on virtual machines.

Improved Observability & Debugging

• Built-in logging, event tracing, and detailed session tracking.
• Integration with external monitoring tools is easier via APIs and telemetry support.

Selenium Grid UI

• New web-based interface for real-time monitoring and management of Grid status, sessions, and nodes.
• Helps quickly identify test distribution and system health.

Better Configuration Management

• Uses TOML-based configuration files that are more readable and easier to maintain.
• Supports CLI and environment-based configuration overrides.

Cloud and Kubernetes Integration

• Designed for modern cloud-native deployments.
• Easily deployable on Kubernetes and compatible with major cloud platforms.

These features collectively make Selenium Grid 4 a comprehensive, flexible, and modern solution for automated cross-browser testing at scale.

Selenium Grid 4 is powerful, but managing infrastructure can be complex. BrowserStack offers a cloud-based alternative. It provides instant access to real devices and browsers, supports Selenium tests, and scales effortlessly for parallel execution. For teams seeking faster, hassle-free testing, BrowserStack is an excellent solution.

Components of Selenium Grid 4 Architecture

Selenium Grid 4 introduces a modular and distributed architecture that enhances flexibility, performance, and scalability. Each component in the architecture plays a specific role in managing and executing automated tests.

Router

The Router is the central entry point for all external requests to the Grid. It receives both session creation and command execution requests, directing new session requests to the Distributor and routing ongoing session commands to the correct Node based on session data.

Its main function is to manage and streamline communication across different components.

Distributor

The Distributor manages test session allocation. When the Router receives a new session request, it forwards it to the Distributor, which evaluates the available Nodes and selects the most suitable one based on the desired capabilities and current load.

This decision-making process ensures efficient use of system resources and balanced test execution.

Session Map

The Session Map maintains a registry of all active sessions in the Grid. It links each session ID to the Node handling it. When a test command is issued, the Router consults the Session Map to determine which Node should receive the request.

This component is critical for ensuring that commands are sent to the correct browser instance.

Node

A Node in Selenium Grid 4 is the actual execution environment where browser instances are launched and tests are run. Each Node registers itself with the Distributor, advertising its capabilities such as supported browsers, versions, and platforms.

The Selenium Grid 4 Node Configuration is crucial in defining these capabilities. This configuration is typically managed using a TOML file or command-line parameters, making it flexible and easy to customize for different environments. Once a session is assigned, the Node executes the test and communicates results through the Grid infrastructure.

New Session Queue

The New Session Queue handles incoming session requests in a sequential and controlled manner. It ensures that the Grid does not become overloaded by limiting how many session requests are processed at a time.

This component is particularly useful in high-demand scenarios, allowing the Grid to manage capacity and load more effectively.

Event Bus

The Event Bus enables seamless communication among distributed components using a publish-subscribe model. It allows different parts of the Grid to stay updated on events such as Node status changes, session starts, or terminations.

This internal messaging system ensures that the components operate in sync and react promptly to system events.

Selenium Grid 4 Deployment Modes in 2026

Selenium Grid 4 can be deployed in multiple modes depending on team needs, infrastructure, and scale. Each mode changes how the components interact and how test sessions are managed.

Here are the different deployment modes in Selenium Grid 4:

1. Standalone Mode

Standalone mode combines all Grid components, including Router, Distributor, Session Map, Event Bus, and Nodes, into a single process. All communication happens in memory, which reduces network latency.

Test requests go to the local Router, the Distributor immediately finds a matching Node, and sessions are managed in the same process. This mode is ideal for small-scale testing, debugging, or local development.

How to deploy:

• Download the latest selenium-server-<version>.jar.
• Run the Grid in standalone mode using:

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

• Nodes can be included in the same process or connected externally.
• Access the Grid console at http://localhost:4444 to see active sessions and nodes.

2. Hub and Node Mode

In hub and node mode, the Router, Distributor, and Session Map run in a central hub process. Nodes run on separate machines and register to the hub over HTTP or WebSocket.

When a test request arrives, the Router forwards it to the Distributor, which queries registered Nodes for matching capabilities. The Event Bus propagates session state changes between the hub and nodes, ensuring test execution is synchronized and stable.

How to deploy:

• Start the hub using:

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

• On each Node machine, register the Node with the hub using:

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

• Confirm nodes are connected by checking the hub console.

3. Fully Distributed Mode

In fully distributed mode, each Grid component, including Router, Distributor, Session Map, and Event Bus, runs on a separate machine. Nodes register to the Distributor or Router as configured.

Test requests go to the Router, which communicates with the Distributor to find a compatible Node. The Event Bus propagates updates across all components in real time, enabling fault tolerance and dynamic load balancing for large-scale parallel testing.

How to deploy:

• Start each component on separate machines using their respective commands:

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

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

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

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

• Start Nodes and register them with the appropriate Distributor or Router.
• Monitor components via their respective consoles or logs.

4. Docker and Kubernetes Deployments

This mode runs Grid components inside containers with ephemeral Nodes that can scale dynamically. Routers and Distributors communicate over container networking, and the Event Bus synchronizes session state.

Nodes can automatically register and deregister based on demand, allowing easy scaling and integration with CI/CD pipelines.

How to deploy:

• Use Selenium Grid Docker images:

docker run -d -p 4444:4444 selenium/standalone-chrome

• For distributed setups, run separate containers for router, distributor, and nodes, connecting them via a Docker network.
• Kubernetes manifests can be used to deploy the Grid, automatically scaling Nodes based on test demand.

Can't Test Old Safari or Edge on Local Grid?

Installing legacy & beta browsers locally is complex. Access cloud Grid with 3500+ browser/OS combinations.

Test Across Browsers

Advantages of Grid 4

Selenium Grid 4 offers several enhancements over its predecessors, making test execution more efficient, scalable, and suitable for modern testing needs.

• Provides a wide range of programming language support.
• Offers dedicated framework support.
• Supports multiple browsers and multiple operating systems just like Selenium Webdriver.
• It is free and open-source.
• It supports Parallel Test Execution (Local and Cloud-Based).
• It has a powerful reporting tool for test progress tracking.
• It integrates with CI/CD pipelines.

Installing and Configuring Selenium Grid 4 in 2026

The first step is understanding how to download Selenium Grid 4. The latest version of Selenium 4 (Alpha) is 4.0.0-alpha-7 and the same can be downloaded from the official Selenium website.

Let’s understand Selenium Grid 4’s functioning by using Selenium Grid version 4.0.0-alpha, as it is more stable than the other versions.

Selenium Grid 4 can be set up in the following modes:

• Standalone
• Hub and Node
• Distributed
• Docker

1. Standalone

The new Selenium Server Jar contains all the functionalities needed to run a grid. By default, the server will be listening on http://localhost:4444 port – the URL to point RemoteWebDriver tests. The server will detect available drivers that it can use from the System PATH.

java -jar selenium-server-4.0.0-alpha-7.jar standalone

2. Hub and Node

Start the hub using the below command:

java -jar selenium-server-4.0.0-alpha-7.jar hub

Node registration can be done using the command below:

java -jar selenium-server-4.0.0-alpha-7.jar node --detect-drivers true

3. Distributed

Users can start Grid 4 in a fully distributed manner, with each conceptual piece in its own process. First, start the session map responsible for mapping session IDs to the node the session is running on.

java -jar selenium-server-4.0.0-alpha-1.jar sessions

Then the Distributor:

java -jar selenium-server-4.0.0-alpha-1.jar distributor --sessions http://localhost:5556

The Distributor is aware of all the Nodes and their capabilities. Its main role is to receive a new session request and find a suitable Node where the session can be created. After the session is created, the Distributor stores in the Session Map, the relation between the session id and Node where the session is being executed.

Now start the system with a router to expose it to the Web:

java -jar selenium-server-4.0.0-alpha-1.jar router --sessions http://localhost:5556 --distributor http://localhost:5553

This router will be listening to new session requests on

http://localhost:4444

Now, this is all set up, use this command:

curl http://localhost:4444/status

and it should get confirmed.

4. Using Docker

The docker integration doesn’t make use of UNIX domain sockets. So first, ensure the docker daemon is listening on port 2375 using the command below on the console:

socat -ls TCP-LISTEN:2375,reuseaddr,fork UNIX-CONNECT:/var/run/docker.sock

1. Create daemon.json file in /etc/docker

{"hosts": ["tcp://0.0.0.0:2375", "unix:///var/run/docker.sock"]}

2. Add

 /etc/systemd/system/docker.service.d/override.conf
[Service] ExecStart= ExecStart=/usr/bin/dockerd

3. Reload the systemd daemon:

systemctl daemon-reload

4. Restart docker:

systemctl restart docker.service

Once that’s done, it’s easy to start the selenium server and have it delegate to docker for creating new instances:

java -jar selenium-server-4.0.0-alpha-1.jar standalone -D selenium/standalone-firefox:latest '{"browserName": "firefox"}' --detect-drivers false

Or just start a node:

java -jar selenium-server-4.0.0-alpha-1.jar node -D selenium/standalone-firefox:latest '{"browserName": "firefox"}'

The next steps from here remain the same with setting up the Grid. You can refer to the Selenium Grid Tutorial for the next steps.

Limitations of Selenium Grid 4

Selenium Grid 4 significantly improves parallel execution and scalability, but it is not without constraints. Understanding these limitations helps teams plan infrastructure and decide when a cloud-based solution might be more effective.

• Complex setup for large-scale deployments: Fully distributed mode requires multiple machines and careful network configuration.
• Maintenance overhead: Nodes can become unresponsive or misconfigured, requiring manual monitoring and troubleshooting.
• Limited observability compared to cloud grids: While the Event Bus provides internal updates, deep analytics, logging, and failure diagnostics are minimal.
• Scaling constraints on local infrastructure: Running many nodes locally can exhaust CPU, memory, and browser limits.
• Browser and platform dependency management: Teams must manually install and maintain drivers and browser versions.

What’s the difference – Grid 3 vs Grid 4

Selenium Grid 3 comes up with only Hub node setup. To set up a grid on Selenium 3, the only option is the Hub-node setup. All machines should have a selenium-standalone jar downloaded as a hub to represent as a hub in the cluster and a node to represent as a node with separate commands.

Whereas, Selenium Grid 4 can be set up using the above-mentioned methods as it is diversified and comes up with additional features. The entire grid setup has been written from scratch with all modern tools and frameworks to support fully distributed testing and comes with extensive Docker support.

And that is how users can get started with Selenium Grid 4, in order to leverage its many advantages.

How BrowserStack Enhances Selenium Grid 4 Testing

BrowserStack is a cloud-based testing platform that provides access to hundreds of real browsers and devices without the need to manage infrastructure. It integrates seamlessly with Selenium Grid 4, allowing teams to execute tests at scale while reducing setup, maintenance, and environment-related failures.

By combining Selenium Grid 4 with BrowserStack, teams gain reliable parallel execution, improved observability, and access to real devices, which transforms distributed testing from a local bottleneck into a scalable, efficient workflow.

Key BrowserStack features for Selenium Grid 4 testing:

• Real Device Cloud: Run Selenium tests on actual devices rather than emulators, ensuring results reflect true end-user behavior.
• Parallel Testing: Execute hundreds of tests concurrently across multiple browsers and devices, fully leveraging Grid 4’s parallel execution capabilities.
• Local Environment Testing: Test apps hosted behind firewalls or on local servers by connecting Grid 4 sessions to BrowserStack’s secure tunnel.
• Test Reporting & Analytics: Capture logs, screenshots, and videos for every test, providing deep insights for debugging flaky or failing sessions.
• SDK Integration: Seamlessly connect Selenium Grid 4 test scripts with BrowserStack SDKs for advanced automation workflows and CI/CD pipelines.

Can't Test Old Safari or Edge on Local Grid?

Installing legacy & beta browsers locally is complex. Access cloud Grid with 3500+ browser/OS combinations.

Test Across Browsers

What Experts Recommend for Selenium Grid 4

Selenium Grid 4 introduces native observability features that expose how sessions move through the Grid. Here are some recommendations from experts with hands-on experience using Selenium Grid 4.

1. Dave Haeffner, author of Elemental Selenium, has advised that testers should reserve Selenium Grid runs for cross-browser and parallel validation, while keeping local execution as the primary loop for test development and debugging.
2. Simon Stewart, creator of Selenium, has stated that Selenium Grid 4 should be operated like a distributed system, which means testers must monitor session routing, node availability, and Grid health rather than treating execution as opaque
3. Boni García, Selenium contributor and creator of WebDriverManager, has stated that Selenium Grid 4 users should rely on the Grid’s native browser and driver management instead of maintaining custom driver setups per node.
4. Bas Dijkstra, test automation consultant and Selenium community contributor, has stated that Selenium Grid 4 should be introduced only after tests are stable, because Grid parallelism magnifies timing issues and synchronization problems.

Conclusion

Selenium Grid 4 modernizes distributed test execution with a robust architecture that separates routing, session management, and node execution. It enables parallel testing at scale, improves fault tolerance, and provides clear observability, helping teams run tests reliably across multiple browsers and platforms.

BrowserStack removes infrastructure constraints and provides access to real devices, parallel execution, and secure local testing. Combined with detailed reporting and SDK support, it allows teams to scale automation, debug faster, and deliver software more reliably.

Try BrowserStack Now