Deploy Selenium Standalone Chrome

Deploy and Host Selenium Standalone Chrome on Railway

Selenium Standalone Chrome is a ready-to-use remote browser automation service powered by Selenium WebDriver and Google Chrome. It exposes a WebDriver-compatible endpoint so applications can control browser sessions remotely for testing, scraping, QA, screenshot generation, and other browser automation workflows.

This template is optimized for Railway with headless Chrome, shared-memory tuning, configurable concurrency, and Selenium Grid monitoring. It provides a practical remote browser environment without requiring you to maintain a dedicated browser virtual machine or manually configure a Selenium server.

About Hosting Selenium Standalone Chrome

Hosting Selenium Standalone Chrome on Railway gives you a remotely accessible Chrome automation environment that can be used by backend services, test runners, scheduled jobs, and local development tools.

Applications written in Java, C#, and other WebDriver-compatible languages can connect to the Selenium endpoint and create browser sessions on demand. Your application sends commands through the WebDriver protocol, while Chrome runs inside the deployed Selenium container.

Typical workloads include:

• Web scraping and structured data extraction
• End-to-end testing
• Automated form submission
• Login and navigation workflows
• Screenshot and PDF generation
• Browser-based integration testing
• Dynamic website data extraction
• Automated QA pipelines
• Website monitoring
• CI/CD browser testing
• Rendering JavaScript-heavy pages

The browser environment is ephemeral by design. Each session can start with a clean profile, which helps prevent cookies, cache, and temporary files from one job affecting another.

Included Architecture

                  Automation Client
                         │
                         │ WebDriver
                         ▼
                Railway HTTPS Proxy
                         │
                         ▼
              ┌────────────────────┐
              │ Selenium Standalone│
              │      Chrome        │
              │                    │
              │ Selenium Grid      │
              │ Chrome WebDriver   │
              │ Headless Browser   │
              └─────────┬──────────┘
                        │
                 Browser Sessions

Concurrent Browser Sessions

This template supports multiple Chrome sessions inside the same Selenium container.

The default configuration supports up to 2 concurrent browser sessions.

For example:

• 2 scraping jobs can execute simultaneously
• 2 E2E test cases can run in parallel
• Multiple automation workers can share one Selenium endpoint
• A test runner and a monitoring job can operate at the same time

The number of concurrent sessions can be adjusted after deployment from the Railway service settings. Before increasing concurrency, make sure the service has enough CPU and memory for the additional Chrome processes.

Resource Considerations

Each Chrome session consumes CPU and memory depending on the website being automated.

Heavy JavaScript applications, video playback, large pages, browser extensions, multiple tabs, file downloads, and complex client-side rendering can significantly increase memory consumption. Websites with long-running scripts may also keep CPU usage elevated for extended periods.

As a rough guideline:

Actual usage depends heavily on the workload, browser flags, page complexity, and the number of tabs opened by each session.

For most deployments, starting with 2 concurrent sessions provides a safer balance between throughput and resource usage. You can scale the Railway service after deployment when your automation workload requires more CPU, memory, or browser capacity.

Shared Memory

Chrome relies heavily on /dev/shm for browser processes, rendering, and inter-process communication.

This template allocates approximately:

2 GiB

of shared memory for improved browser stability.

Additional shared memory reduces the chance of Chrome tabs crashing under heavier workloads and avoids relying on the slower /tmp fallback commonly used when shared memory is too small. This is especially helpful when running multiple sessions, loading large pages, or interacting with complex web applications.

Common Use Cases

• Web scraping and structured data extraction
• End-to-end browser testing
• Automated regression testing
• Browser-based integration tests
• Form submission automation
• Login automation
• Screenshot generation
• PDF generation
• Website monitoring
• Dynamic page rendering
• CI/CD browser testing
• Remote browser automation for backend services
• Testing responsive layouts and user flows
• Validating JavaScript-heavy applications

WebDriver Endpoint

Selenium listens on:

4444

After deployment, your Selenium endpoint will look similar to:

https://<your-domain>

Modern Selenium 4 clients can connect directly to this base URL.

The legacy endpoint is also commonly supported:

https://<your-domain>/wd/hub

Use the public Railway domain assigned to your service, or configure a custom domain if your project requires one. Keep the endpoint private or protected whenever the service handles sensitive automation tasks.

Session Timeouts

Inactive sessions are automatically cleaned up to prevent browser processes from remaining alive indefinitely.

The default session timeout is:

300 seconds

This helps reclaim resources when clients disconnect unexpectedly or forget to call:

driver.quit()

Applications should still explicitly close browser sessions whenever possible. A timeout is a safety mechanism, not a replacement for proper session management.

Long-running workflows should be designed carefully. If a task legitimately requires more than five minutes without browser activity, configure the timeout according to the Selenium image and deployment settings you use, while ensuring that abandoned sessions can still be removed.

Scaling on Railway

You can scale the Selenium service directly from the Railway service settings after deployment.

Increase the service resources when you need to run more browser sessions, process heavier pages, or handle multiple automation jobs at the same time. Scaling the service provides additional CPU and memory for Chrome and Selenium workloads.

For larger workloads, you can also deploy multiple Selenium services and distribute automation jobs between them. This approach can help isolate failures, distribute resource usage, and reduce the impact of a single browser crash.

When scaling, monitor:

• CPU usage
• Memory consumption
• Session queue time
• Browser crashes
• Page load performance
• Average job duration

Start with a small number of concurrent sessions, then scale the Railway service as your automation workload increases.

Dependencies for Selenium Standalone Chrome Hosting

• Selenium Standalone Chrome — Selenium Grid, WebDriver, and Chrome runtime
• Railway Networking — connectivity to the WebDriver endpoint
• Shared Memory Allocation — improves Chrome stability
• WebDriver Client — Java, C#, or another Selenium-compatible client

No PostgreSQL, Redis, MySQL, or persistent volume is required for the basic deployment. Additional services may still be useful if your application needs job queues, result storage, authentication, or persistent reporting.

Deployment Dependencies

• Selenium Docker Images: https://github.com/SeleniumHQ/docker-selenium
• Selenium Standalone Chrome: https://hub.docker.com/r/selenium/standalone-chrome
• Selenium Documentation: https://www.selenium.dev/documentation/
• Selenium WebDriver: https://www.selenium.dev/documentation/webdriver/
• Railway Networking: https://docs.railway.com/networking

Why Deploy Selenium Standalone Chrome on Railway?

Railway is a unified platform for deploying infrastructure and applications. It hosts your service so you do not have to manage browser servers manually, while allowing you to scale the Railway service after deployment as your workload grows.

By deploying Selenium Standalone Chrome on Railway, you get a ready-to-use remote Chrome automation environment with Selenium WebDriver, Grid monitoring, headless execution, configurable concurrency, and shared-memory tuning for more reliable browser automation.

The template is suitable for teams that need a practical remote browser service without maintaining a dedicated Selenium VM. Start with a small number of concurrent sessions, monitor resource usage, secure the endpoint, and scale the Railway service whenever your automation workload requires additional capacity.