Deploy Selenium Grid

Deploy and Host Selenium Grid on Railway

Selenium Grid is a distributed browser automation platform for running tests and automation workloads across multiple browsers from a single WebDriver endpoint.

This template deploys a complete Selenium Grid environment with Chrome, Firefox, and Edge nodes connected to a central Selenium Hub, making it easy to run cross-browser tests and parallel browser automation without managing separate browser machines manually.

About Hosting Selenium Grid

Selenium Grid separates browser execution from your application or test runner.

Your automation client connects to a single Selenium Hub endpoint, while the Grid routes each requested session to an available browser node.

This template includes:

• Selenium Hub — central WebDriver endpoint and Grid controller
• Chrome Node — runs Google Chrome automation sessions
• Firefox Node — runs Mozilla Firefox automation sessions
• Edge Node — runs Microsoft Edge automation sessions

Only the Selenium Hub needs to be publicly accessible. Browser nodes communicate with the Hub through Railway's private network.

Included Architecture

                    Test / Automation Client
                              │
                              │ WebDriver
                              ▼
                     ┌─────────────────┐
                     │  Selenium Hub   │
                     │                 │
                     │ Session Router  │
                     │ Grid Dashboard  │
                     └────────┬────────┘
                              │
                   Railway Private Network
                              │
              ┌───────────────┼───────────────┐
              │               │               │
              ▼               ▼               ▼
       ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
       │   Chrome    │ │   Firefox   │ │    Edge     │
       │    Node     │ │    Node     │ │    Node     │
       └─────────────┘ └─────────────┘ └─────────────┘

Why Use Selenium Grid?

Selenium Grid becomes useful when browser automation needs to go beyond one browser or one session at a time.

Instead of maintaining separate Selenium instances for Chrome, Firefox, and Edge, the Grid provides one endpoint for all available browser nodes.

Cross-Browser Testing

Run the same test suite against:

• Chrome
• Firefox
• Microsoft Edge

This helps detect browser-specific issues before users encounter them.

Parallel Execution

Multiple browser sessions can run at the same time.

For example:

Test 1 → Chrome
Test 2 → Firefox
Test 3 → Edge

instead of:

Test 1 → Finish
Test 2 → Finish
Test 3 → Finish

Parallel execution can significantly reduce the total runtime of large test suites.

Centralized Browser Infrastructure

Applications only need to know one Selenium Hub URL.

The Hub handles browser selection and routes sessions to the appropriate node automatically.

Common Use Cases

• Cross-browser end-to-end testing
• Regression testing
• Automated QA pipelines
• CI/CD browser testing
• Website compatibility testing
• Parallel Selenium test execution
• Web scraping across different browser engines
• Browser-based integration testing
• Automated form and workflow testing
• Remote browser execution for development teams

Selenium Grid vs Standalone Chrome

If your workload only requires Chrome, a standalone Selenium Chrome instance may be simpler and cheaper.

Use Selenium Grid when you need multiple browsers, distributed execution, or larger automation workloads.

Grid Dashboard

Selenium Hub includes a built-in Grid dashboard.

After deployment, open the public Railway URL assigned to the Selenium Hub.

The dashboard lets you inspect:

• Connected browser nodes
• Browser types
• Available session slots
• Running sessions
• Node availability
• Selenium Grid health
• Current Grid capacity

A healthy deployment should display Chrome, Firefox, and Edge nodes connected to the Hub.

Using the Selenium Grid

Applications connect only to the public Selenium Hub endpoint.

A typical endpoint looks like:

https://your-selenium-grid.up.railway.app

Modern Selenium clients can connect directly to this URL.

Example with Python

Install Selenium:

pip install selenium

Chrome

from selenium import webdriver
from selenium.webdriver.chrome.options import Options

options = Options()
options.add_argument("--headless=new")

driver = webdriver.Remote(
    command_executor="https://your-selenium-grid.up.railway.app",
    options=options,
)

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

print(driver.title)

driver.quit()

Firefox

from selenium import webdriver
from selenium.webdriver.firefox.options import Options

options = Options()
options.add_argument("-headless")

driver = webdriver.Remote(
    command_executor="https://your-selenium-grid.up.railway.app",
    options=options,
)

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

print(driver.title)

driver.quit()

Edge

from selenium import webdriver
from selenium.webdriver.edge.options import Options

options = Options()
options.add_argument("--headless=new")

driver = webdriver.Remote(
    command_executor="https://your-selenium-grid.up.railway.app",
    options=options,
)

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

print(driver.title)

driver.quit()

The same Hub URL is used for every browser. Selenium determines which node should execute the session from the browser capabilities supplied by the client.

Parallel Testing

One of the main advantages of Selenium Grid is parallel execution.

For example, an automated test suite can request:

Chrome
Firefox
Edge

at the same time.

The Hub can distribute those requests across available browser nodes:

Selenium Hub
     │
     ├── Test A → Chrome Node
     ├── Test B → Firefox Node
     └── Test C → Edge Node

This architecture becomes particularly useful as test suites grow.

Scaling the Grid

The browser nodes are independent services.

This gives the Grid more flexibility than increasing concurrency inside a single browser container.

For example, additional Chrome capacity can be added without changing Firefox or Edge capacity:

Selenium Hub
     │
     ├── Chrome Node
     ├── Chrome Node
     ├── Chrome Node
     ├── Firefox Node
     └── Edge Node

This is useful when your workload is heavily biased toward one browser.

Instead of dramatically increasing the number of sessions inside one container, distributing sessions across additional browser nodes generally provides more predictable resource isolation.

Dependencies for Selenium Grid Hosting

• Selenium Hub — central session router and WebDriver endpoint
• Selenium Chrome Node — Chrome browser execution
• Selenium Firefox Node — Firefox browser execution
• Selenium Edge Node — Edge browser execution
• Railway Private Networking — Hub and browser-node communication
• Railway Public Networking — optional external WebDriver access
• Shared Memory — browser runtime stability

No PostgreSQL, Redis, MySQL, or persistent database is required.

Deployment Dependencies

• Selenium Docker Images: https://github.com/SeleniumHQ/docker-selenium
• Selenium Documentation: https://www.selenium.dev/documentation/
• Selenium Grid Documentation: https://www.selenium.dev/documentation/grid/
• Selenium WebDriver Documentation: https://www.selenium.dev/documentation/webdriver/
• Railway Networking: https://docs.railway.com/networking

Why Deploy Selenium Grid on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying Selenium Grid on Railway, you get a distributed browser automation environment with Chrome, Firefox, and Edge behind one WebDriver endpoint, making cross-browser testing and parallel automation easier to operate and scale.