Selenium Server Standalone: How to Setup and Configure

Running Selenium tests locally is easy when everything happens on one machine. The problems start when I need to execute tests remotely, share browser infrastructure, or run several sessions without tying everything to my local setup.

That is where Selenium Server becomes useful. Without the right setup, remote execution can quickly turn into connection errors, mismatched browser drivers, or a Grid configuration that feels more complicated than the tests themselves.

In this guide, I’ll show you how Selenium Server works in Standalone mode, how to configure it for remote browser testing, and when it makes sense to move from a single-machine setup to a larger Selenium Grid.

What is Selenium Server Standalone?

Selenium Server Standalone is useful when I want my Selenium tests to run somewhere other than the machine where the test code lives. It comes as a JAR file that bundles the components needed to accept WebDriver commands and pass them on to the browser.

In practice, it sits between my test script and the browser session. That makes remote execution possible and also gives me a simple starting point before moving to a larger Selenium Grid setup with multiple machines or browser environments.

The main benefit is that I can separate where the test is written from where the browser actually runs, without introducing a complex distributed setup from the start.

Why Selenium Server Standalone Is Useful in Practice

I would use Selenium Server Standalone when local WebDriver execution starts becoming a bottleneck. On a local setup, the test code and browser usually run on the same machine. Standalone changes that by giving my tests a single RemoteWebDriver endpoint, while Selenium handles browser sessions behind it.

Here is where Standalone adds the most value:

• One endpoint for remote execution: Instead of creating every browser directly on the machine running the test code, I can point RemoteWebDriver at the server. By default, Standalone listens on http://localhost:4444, and that same endpoint can later be replaced with another Grid address without redesigning the entire test suite.
• Parallel sessions without a full distributed setup: Standalone can run several browser sessions on the same host. Selenium limits concurrent sessions according to available processors by default. Its documentation gives the example of an 8-CPU Node supporting up to eight concurrent sessions, with Safari remaining limited to one, and recommends budgeting roughly 1 GB of RAM per browser session as a starting point.
• A practical step toward cross-browser coverage: The same remote endpoint can receive different browser capabilities, so I can route tests to the browsers available on that machine rather than maintaining completely separate execution logic. Selenium Grid itself is designed for parallel execution, different browser versions, and cross-platform testing.
• Useful for CI pipelines: Standalone is small enough to spin up as part of a Jenkins or GitHub Actions job, run the browser suite, and shut down afterward. Selenium itself lists quick test suites and CI/CD environments among the common use cases for this mode.
• Central visibility into running sessions: Once the server is running, I can open the Grid UI at port 4444 or query the status API. That is much easier to troubleshoot than several unrelated local browser processes when tests start running concurrently.
• An easier path to scale later: Standalone is still limited to one machine. When that host runs out of CPU, memory, operating systems, or browser combinations, I can move to Hub-and-Node or a distributed architecture while keeping the same RemoteWebDriver model. Selenium’s own sizing guidance treats Standalone as suitable for smaller setups and recommends distributed approaches as Grid size grows.

One thing I would remove from the original feature list is “Remote Control (RC) support.” Selenium RC belongs to Selenium’s legacy architecture. For a current Selenium 4 article, the useful concept is Remote WebDriver, not Selenium RC.

Key Features of Selenium Server Standalone

Some of the key features of Selenium Server Standalone are:

• Remote Control (RC) Support: Supports running Selenium WebDriver tests on remote browsers.
• Selenium Grid Compatibility: Allows you to set up a hub and node architecture to run tests in parallel across different environments.
• WebDriver support: Provides all the features of Selenium WebDriver for remote sessions with browsers.
• Cross Browser Testing: Helps run tests on different browsers such as Chrome, Firefox, and Safari.
• Integration with various testing frameworks: Works easily with frameworks like TestNG and JUnit for test execution and reporting.

Prerequisites

For setting up Selenium Server Standalone, make sure to have the following prerequisites in place:

1. System requirements

• OS: Windows, macOS, or Linux
• RAM: 2GB minimum
• CPU: Dual-core processor or higher

2. Java installation and version compatibility

• Java 8 or higher is required. Ensure Java is installed and properly configured.

3. Installing Java Development Kit (JDK) and configuring environment variables

• Download JDK from the official Oracle website, install it, and set JAVA_HOME and PATH environment variables.

4. Browsers and drivers needed for Selenium WebDriver

• Install browser-specific drivers (for example, ChromeDriver for Chrome, GeckoDriver for Firefox).

5. Other dependencies

• Install tools like Selenium Grid and Apache Maven for grid-based distributed testing.

How to Download and Run Selenium Server

I would combine the download and setup steps because there is little value in treating them as separate tasks. With Selenium 4, the file is named selenium-server-<version>.jar, and you start Standalone mode by adding the standalone command. The older selenium-server-standalone-<version>.jar naming belongs to Selenium 3-era setups and should not be used in a current guide.

Step 1: Check Java First

Selenium Grid currently requires Java 11 or higher. Before downloading anything, I would confirm that Java is available from the terminal.

java -version

You should see Java 11 or a newer release. If the command is not recognized, install a supported JDK and make sure Java is available through your system PATH.

You can also check which Java executable the terminal is using:

macOS/Linux

which java

Windows

where java

Step 2: Download the Selenium Server JAR

The safest source is Selenium’s official Downloads page, which links to the current server release. As of August 11, 2026, the latest stable Selenium Server release is 4.47.0, distributed as selenium-server-4.47.0.jar.

I would normally keep the commands in documentation version-neutral so they do not become stale:

selenium-server-<version>.jar

For example:

selenium-server-4.47.0.jar

There is no need to hunt for a separate “Standalone” download. In Selenium 4, the same server JAR can run in Standalone, Hub, Node, or distributed roles.

Step 3: Make Sure a Browser Is Available

The server needs browsers it can actually launch. Selenium’s current setup guidance also requires the corresponding browser drivers. You can either put those drivers on PATH or let Selenium Manager configure them automatically.

For the latter, start the server with:

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

That is useful on a fresh machine or in CI because you do not have to manually maintain every browser driver yourself.

Step 4: Start the Server

Navigate to the folder containing the JAR, then run:

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

For example:

java -jar selenium-server-4.47.0.jar standalone

Standalone mode brings the Grid components together in a single process on one machine. By default, it accepts RemoteWebDriver requests on port 4444.

If I wanted to limit the machine to four simultaneous sessions, I could make that explicit:

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

  --max-sessions 4 \

  --port 4444

Both –max-sessions and –port are supported Standalone configuration options.

Step 5: Check That the Server Is Actually Running

Open:

http://localhost:4444

The Grid interface shows the browsers and capabilities available on the machine. This is more useful than simply checking whether the Java process started because you can immediately see whether Selenium has detected something it can run.

For a quick terminal check, you can also query the status endpoint:

curl http://localhost:4444/status

If the server is healthy, the response should indicate that it is ready to accept sessions.

Step 6: Point a Test at the Server

Starting the server alone does not make an existing local WebDriver test remote. The test needs to connect through RemoteWebDriver and use the server URL. Selenium’s documentation uses http://localhost:4444 as the default Standalone endpoint.

For example, in Java:

import java.net.URL;



import org.openqa.selenium.WebDriver;

import org.openqa.selenium.chrome.ChromeOptions;

import org.openqa.selenium.remote.RemoteWebDriver;



public class RemoteTest {

    public static void main(String[] args) throws Exception {



        ChromeOptions options = new ChromeOptions();



        WebDriver driver = new RemoteWebDriver(

            new URL("http://localhost:4444"),

            options

        );



        driver.get("https://example.com");



        System.out.println(driver.getTitle());



        driver.quit();

    }

}

The important line is:

new RemoteWebDriver(

    new URL("http://localhost:4444"),

    options

);

That tells the test to request its Chrome session from Selenium Server instead of starting Chrome directly through a local ChromeDriver.

You can make the same switch in Python:

from selenium import webdriver



options = webdriver.ChromeOptions()



driver = webdriver.Remote(

    command_executor="http://localhost:4444",

    options=options

)



driver.get("https://example.com")

print(driver.title)



driver.quit()

At this point, I would run one test first and confirm that the browser starts successfully. Only after that would I add parallel execution or more complicated Grid configuration. It makes problems with Java, browser detection, ports, and RemoteWebDriver much easier to isolate.

Advanced Configuration of Selenium Server

Some of the advanced configurations of the Selenium server are:

1. Setting up hub and node for Selenium Grid in standalone mode

Setting up the hub and node for Selenium Grid in standalone mode involves starting the hub and node on different terminals or devices. The hub is responsible for distributing tests to the registered nodes, which execute the tests on specific browsers.

You can start the hub with this command:

java -jar selenium-server-standalone.jar -role hub

Also, start the node with this command:

java -jar selenium-server-standalone.jar -role node -hub http://<hub_ip>:4444/grid/register

2. Configuring Selenium Server to run in grid mode

Use the -role argument to start the server as a hub or node. For example, to start the hub:

java -jar selenium-server-standalone.jar -role hub

3. Managing WebDriver versioning compatibility with Selenium Server

Ensure the versions of WebDriver and browser drivers are compatible with the Selenium Server version to avoid compatibility issues during test execution.

4. Using Grid Console to monitor Selenium Grid status

Access the Grid Console at http://localhost:4444/grid/console to monitor the connected nodes and the tests being executed.

5. Configuring Selenium to work with multiple browsers

Easily configure Selenium to work with Chrome, Firefox, and other browsers by specifying the required functionalities in the WebDriver setup.

6. Network configurations and firewall rules for Selenium Server setup

Make sure that proper network configurations and firewall rules are set up to allow communication between the hub and nodes in the Selenium Grid.

When One Machine Is No Longer Enough

Selenium Server in Standalone mode already gives me a working Grid. I would stay there while one machine has enough browsers and resources for my test suite. The reason to move to a Hub-and-Node setup is not to “enable Grid.” It is to add more machines, operating systems, browser versions, or execution capacity.

Start the Hub on the machine that will coordinate execution:

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

Then connect another machine as a Node:

java -jar selenium-server-<version>.jar node \

  --hub http://192.168.1.10:4444

Here, 192.168.1.10 is the Hub machine. When Hub and Node run on different hosts, Selenium’s default Event Bus ports 4442 and 4443 must be reachable, along with the Node’s own port. Otherwise, the Node may start locally but never register with the Hub.

I would also remove this command from the original article:

java -jar selenium-server-standalone.jar \

  -role node \

  -hub http://localhost:4444/grid/register \

  -browser browserName=chrome,maxInstances=5

That is old Grid syntax. In Selenium 4, Nodes can detect the browser drivers available on the machine automatically. If I need a Node with a very specific browser configuration, Selenium provides –driver-configuration, but I would only introduce that when automatic detection is not enough.

So the progression is simply:

One machine is enough

        ↓

Run Standalone


Need more machines or environments

        ↓

Run Hub + Nodes


Need much larger infrastructure

        ↓

Consider a fully distributed Grid

Selenium supports all three deployment models, so there is no need to start with the most complicated architecture.

Common Setup Problems and Better Ways to Handle Them

Most problems I run into with Selenium Server are not really WebDriver problems. They usually come down to browser discovery, machine resources, networking, or configuration. I would make this section diagnostic so readers can go from a symptom to a fix quickly.

Conclusion

Selenium Server is useful when I need more than a simple local WebDriver setup. It gives me a clean way to run browsers remotely, add parallel execution, and move toward a larger Grid without changing how my tests are written.

I would still keep the setup as simple as possible. Start with Standalone mode, confirm that remote sessions work, and only add Hub-and-Node infrastructure when one machine becomes the limitation. That keeps the Grid easier to manage and makes failures much easier to trace when something goes wrong.