Single Node/Standalone Image With All Browsers in Selenium Grid Docker

[VietND96]

Introduction

The Selenium Docker project has reached a significant milestone with the introduction of unified container images that include all popular web browsers in a single package. Starting from version 4.35.0, users can now leverage selenium/standalone-all-browsers and selenium/node-all-browsers images that come pre-installed with Chrome, Edge, Firefox, and Chromium browsers, dramatically simplifying deployment and testing workflows.

This new capability addresses a long-standing need in the testing community for a more streamlined approach to cross-browser testing, eliminating the complexity of managing multiple browser-specific containers while maintaining the flexibility and power of Selenium Grid.

Background

Traditionally, Selenium Grid with Docker deployments required separate containers for each browser type:

• selenium/node-chrome for Chrome testing
• selenium/node-firefox for Firefox testing
• selenium/node-edge for Edge testing
• selenium/node-chromium for Chromium testing
• selenium/standalone-chrome, selenium/standalone-firefox, etc. for standalone deployments

This approach, while providing fine-grained control and optimized resource usage, introduced several challenges:

1. Complex orchestration: Managing multiple containers required sophisticated Docker Compose files
2. Resource overhead: Each container carried its own Selenium Grid node overhead
3. Network complexity: Inter-container communication and load balancing became more intricate
4. Deployment friction: Setting up comprehensive cross-browser testing environments required significant configuration

The community had been requesting a unified solution, as evidenced by GitHub issue #2795 and the extensive discussion in GitHub discussion #2659.

Motivation

The primary motivations for developing the all-browsers images were:

Simplicity and Convenience

Many development teams and individual developers prefer the "all-in-one" approach for:

• Rapid prototyping: Quick setup of testing environments without complex configuration
• Educational purposes: Learning Selenium Grid concepts without infrastructure complexity
• Small to medium projects: Where the convenience outweighs the resource optimization benefits

Reduced Operational Overhead

• Single container management: Easier monitoring, logging, and troubleshooting
• Simplified networking: No need to configure inter-container communication for multiple browser nodes
• Streamlined CI/CD: Fewer moving parts in continuous integration pipelines

Cross-Browser Testing Efficiency

• Unified test execution: Run tests against multiple browsers from a single endpoint
• Consistent environment: All browsers share the same base system and configuration
• Faster iteration: Quick switching between browsers during development and debugging

Implementation

The implementation of the all-browsers images involved significant engineering work to create a unified container that supports multiple browsers while maintaining the flexibility and reliability of individual browser containers.

Technical Approach

The development team implemented an innovative layered build approach that reuses existing Dockerfile configurations from individual browser containers. The all-browsers images are built through a sequential layering process:

1. Base Layer: Starting with node-base as the foundation
2. Chromium Layer: Building from NodeChromium, using node-base as the base image
3. Firefox Layer: Building from NodeFirefox, using the previous node-all-browsers image as the base
4. Chrome Layer: Building from NodeChrome, layering on top of the existing node-all-browsers image
5. Edge Layer: Building from NodeEdge, adding the final browser to the node-all-browsers image
6. Standalone Layer: Creating standalone-all-browsers using the completed node-all-browsers as the base

This approach allowed for:

• Code reuse: Leveraging existing Dockerfile configurations from individual browser containers without modification
• Incremental building: Each browser installation builds upon the previous layer, accumulating all browsers in a single image
• Maintainability: Preserving the existing codebase structure while extending functionality through build orchestration

Key Implementation Features

Multi-Browser Installation: All supported browsers (Chrome, Edge, Firefox, and Chromium) are installed within a single container image, along with their respective WebDriver binaries.

Dynamic Configuration Generation: The system automatically detects available browsers and generates appropriate Selenium Grid node configurations based on the runtime environment and architecture.

Runtime Browser Selection: Environment variable-driven browser selection allows users to customize which browsers are active and how they behave, including the ability to switch between Chrome and Chromium binaries on supported architectures.

Architecture-Aware Deployment: The implementation includes intelligent handling of different processor architectures, ensuring that only compatible browsers are activated on each platform.

Architecture Overview

The all-browsers images are built with:

• Base Layer: Standard Selenium Grid node or standalone configuration
• Browser Layer: All supported browsers installed with their respective drivers
• Configuration Layer: Dynamic configuration generation based on available browsers and architecture
• Runtime Layer: Environment variable-driven browser selection and customization

Configuration

Available Images

Two primary images are available:

1. selenium/standalone-all-browsers: Complete standalone Selenium Grid with all browsers
2. selenium/node-all-browsers: Multi-browser node for Hub-Node grid deployments

Image Tag Convention

The all-browsers images use a multi-tag approach, where each image is tagged with multiple version identifiers for flexibility:

Available Tags (all pointing to the same image):

• latest - Latest stable release
• 4 - Major version tag
• 4.35 - Major.minor version tag
• 4.35.0 - Full semantic version
• 4.35.0-20250828 - Full version with build date

Tag Usage Examples:

# Using different tag specificity levels
selenium/node-all-browsers:latest
selenium/node-all-browsers:4
selenium/node-all-browsers:4.35
selenium/node-all-browsers:4.35.0
selenium/node-all-browsers:4.35.0-20250828

selenium/standalone-all-browsers:latest
selenium/standalone-all-browsers:4
selenium/standalone-all-browsers:4.35
selenium/standalone-all-browsers:4.35.0
selenium/standalone-all-browsers:4.35.0-20250828

This multi-tag approach provides:

• Flexibility: Choose the appropriate level of version pinning
• Compatibility: Easy migration between versions
• Stability: Pin to specific versions for production environments
• Convenience: Use latest for development and testing

Multi-Architecture Support

Browser availability varies by architecture:

Browser / Architecture	x86_64 (amd64)	aarch64 (arm64)
Chrome	✅	❌
Edge	✅	❌
Firefox	✅	✅
Chromium	✅	✅

Basic Usage

Standalone Mode

services:
  selenium:
    image: selenium/standalone-all-browsers:latest
    ports:
      - "4444:4444"
    shm_size: 3gb

Hub-Node Mode

services:
  selenium-hub:
    image: selenium/hub:latest
    ports:
      - "4444:4444"

  all-browsers:
    image: selenium/node-all-browsers:latest
    shm_size: 3gb
    depends_on:
      - selenium-hub
    environment:
      - SE_EVENT_BUS_HOST=selenium-hub

Advanced Configuration

Browser Binary Switching

For x86_64 systems with both Chrome and Chromium available, you can switch to Chromium:

environment:
  - SE_BROWSER_BINARY_LOCATION_CHROME=/usr/bin/chromium

Per-Browser Customization

Each browser can be individually configured using environment variables with browser-specific suffixes. The supported environment variable prefixes are:

• SE_NODE_STEREOTYPE_<BROWSER> - Browser stereotype configuration
• SE_NODE_BROWSER_NAME_<BROWSER> - Browser name override
• SE_NODE_BROWSER_VERSION_<BROWSER> - Browser version specification
• SE_NODE_PLATFORM_NAME_<BROWSER> - Platform name configuration
• SE_BROWSER_BINARY_LOCATION_<BROWSER> - Custom browser binary location
• SE_NODE_STEREOTYPE_EXTRA_<BROWSER> - Additional stereotype properties
• SE_NODE_MAX_SESSIONS_<BROWSER> - Maximum concurrent sessions per browser

Where <BROWSER> can be CHROME, FIREFOX, EDGE.

Example configuration:

environment:
  # Chrome configuration
  - SE_NODE_MAX_SESSIONS_CHROME=2
  - SE_NODE_PLATFORM_NAME_CHROME=Linux
  
  # Firefox configuration  
  - SE_NODE_MAX_SESSIONS_FIREFOX=1
  - SE_NODE_PLATFORM_NAME_FIREFOX=
  
  # Edge configuration
  - SE_NODE_MAX_SESSIONS_EDGE=3
  - SE_NODE_STEREOTYPE_EXTRA_EDGE={"myApp:version":"beta","myApp:publish":"public"}

Resource Considerations

The all-browsers images are larger and consume more resources:

• Image size: Significantly larger than single-browser images
• Memory usage: Higher baseline memory consumption
• Shared memory: Adequate shared memory allocation recommended to support concurrent browser sessions

Target Use Cases

These images are ideal for:

• Development environments: Quick local testing setup
• Small teams: Simplified infrastructure management
• Educational projects: Learning Selenium Grid concepts
• Lightweight workloads: Where convenience trumps resource optimization
• Proof of concepts: Rapid prototyping and demonstration

Conclusion

The introduction of Single Node/Standalone Images With All Browsers represents a significant step forward in making Selenium Grid more accessible and user-friendly. By providing pre-configured, all-in-one containers, the Selenium Docker project has lowered the barrier to entry for cross-browser testing while maintaining the flexibility that advanced users require.

This feature particularly benefits:

• New users who want to get started quickly without complex setup
• Small to medium projects that prioritize convenience over resource optimization
• Development teams that need rapid iteration and testing capabilities
• Educational environments where simplicity aids learning

While these images may not be suitable for every use case—particularly large-scale production deployments where resource optimization is critical—they fill an important gap in the Selenium ecosystem. The ability to switch between browser binaries and configure individual browsers provides the flexibility needed for diverse testing scenarios.

As the Selenium Docker project continues to evolve, these all-browsers images represent the project's commitment to both power users who need fine-grained control and newcomers who value simplicity and convenience. The community-driven development process, evidenced by the GitHub discussions and feature requests that led to this implementation, demonstrates the project's responsiveness to user needs.

For teams looking to streamline their cross-browser testing workflows, the new all-browsers images offer an compelling solution that balances ease of use with comprehensive browser support. As browser support continues to expand and multi-architecture compatibility improves, these images will become an even more valuable tool in the modern web testing toolkit.

---

For more information about Selenium Docker and the latest updates, visit the official repository

[cgoldberg]

@VietND96 great work! 👍