The docker-selenium project provides a robust set of Docker images for the Selenium Grid Server README.md15-16 These images facilitate the deployment of scalable browser automation infrastructure using various container orchestration tools like Docker Compose and Kubernetes README.md30-31
The project is built on a layered architecture starting from a base Ubuntu image, extending into browser-specific nodes, and supporting advanced features like video recording, dynamic scaling, and multi-architecture (amd64/aarch64) support Base/Dockerfile1-112 Makefile27-28 Makefile139-141
The Selenium Grid can be deployed in three primary modes depending on the scale and complexity required. For a detailed guide on setting up your first environment, see Getting Started.
The simplest form where all Grid components (Hub and a single Node) run within a single container. This is ideal for local development and small-scale testing README.md53
selenium/standalone-chrome, selenium/standalone-firefox, selenium/standalone-edge README.md28 Makefile56-60A classic distributed setup where a central Hub manages multiple Nodes. Each Node registers itself to the Hub and provides specific browser capabilities README.md54-55
selenium/hub Hub/Dockerfile1-32selenium/node-chrome, selenium/node-firefox, selenium/node-edge, etc. NodeChrome/Dockerfile1-77 NodeFirefox/Dockerfile1-100A more advanced mode where the Grid spawns ephemeral browser containers on-demand. Instead of having persistent nodes, a node-docker or node-kubernetes container manages the lifecycle of browser containers via the Docker socket or Kubernetes API README.md60-65
selenium/node-docker or selenium/node-kubernetes to map browser capabilities to specific image tags via a config.toml mapping NodeDocker/config.toml1-8 Makefile53-54The project uses a hierarchical build system to maximize layer reuse and maintain consistency across different browser versions.
The following diagram shows how high-level image concepts map to specific Dockerfiles and build targets in the Makefile.
Sources: Base/Dockerfile1-131 NodeBase/Dockerfile1-4 NodeChrome/Dockerfile1-4 NodeFirefox/Dockerfile1-4 Hub/Dockerfile1-3 Makefile158-175
The behavior of all containers is controlled primarily through SE_* environment variables. These variables are processed at runtime by scripts like generate_config to produce the config.toml file required by the Selenium Server NodeBase/Dockerfile79-81 Base/Dockerfile42
SE_EVENT_BUS_PUBLISH_PORT, SE_NODE_MAX_SESSIONS, SE_SCREEN_WIDTH NodeBase/Dockerfile41-71The containers use supervisord to manage multiple background processes, such as Xvfb (for virtual displays), the Selenium Server itself, and browser-specific cleanup utilities like chrome-cleanup.sh or firefox-cleanup.sh NodeBase/Dockerfile178 NodeChrome/Dockerfile57 NodeFirefox/Dockerfile14
Video recording is handled by a separate selenium/video image. It can run as a sidecar or as part of a Dynamic Grid to capture browser sessions using FFmpeg README.md56-58 Makefile64
The following diagram illustrates how internal scripts and configuration generators bridge the gap between environment variables and the running Selenium Server process.
Sources: NodeBase/Dockerfile166-170 Hub/Dockerfile28-31 NodeChrome/Dockerfile56-57 Base/Dockerfile42 NodeBase/Dockerfile178
RemoteWebDriver connection.SE_* configuration options.Sources: README.md43-51 README.md69-71
