Understanding Grid architecture is useful, but you need a running Grid to test against. This lesson walks through two practical deployment methods: standalone mode for quick local setup (one command, everything in one process) and Docker Compose for multi-node environments that mirror real CI/CD infrastructure. By the end, you will have a Grid running with Chrome and Firefox nodes ready to accept tests.
Deploying Grid — Standalone and Docker Compose
Standalone mode is ideal for local development and learning. Docker Compose is ideal for CI/CD pipelines and team environments where reproducibility and scaling matter.
# ── Method 1: Standalone Mode ──
# Requirements: Java 11+ installed, selenium-server JAR downloaded
# Download from: https://github.com/SeleniumHQ/selenium/releases
STANDALONE_SETUP = {
"steps": [
"1. Download selenium-server-4.x.jar from GitHub releases",
"2. Run: java -jar selenium-server-4.18.1.jar standalone",
"3. Grid starts on http://localhost:4444",
"4. Grid UI available at http://localhost:4444/ui",
"5. All components run in one process (Router + Distributor + Node)",
],
"browsers": "Automatically detects installed browsers (Chrome, Firefox, Edge)",
"max_sessions": "Default: number of available CPU cores",
"pros": ["One command setup", "No Docker needed", "Good for local dev"],
"cons": ["Single machine only", "Manual browser/driver management", "Not reproducible"],
}
# ── Method 2: Docker Compose (Recommended for CI/CD) ──
DOCKER_COMPOSE = """
# docker-compose.yml — Selenium Grid with Chrome and Firefox
version: '3.8'
services:
selenium-hub:
image: selenium/hub:4.18.1
container_name: selenium-hub
ports:
- "4442:4442"
- "4443:4443"
- "4444:4444"
chrome-node:
image: selenium/node-chrome:4.18.1
shm_size: 2gb
depends_on:
- selenium-hub
environment:
- SE_EVENT_BUS_HOST=selenium-hub
- SE_EVENT_BUS_PUBLISH_PORT=4442
- SE_EVENT_BUS_SUBSCRIBE_PORT=4443
- SE_NODE_MAX_SESSIONS=4
deploy:
replicas: 2 # 2 Chrome nodes x 4 sessions = 8 parallel Chrome tests
firefox-node:
image: selenium/node-firefox:4.18.1
shm_size: 2gb
depends_on:
- selenium-hub
environment:
- SE_EVENT_BUS_HOST=selenium-hub
- SE_EVENT_BUS_PUBLISH_PORT=4442
- SE_EVENT_BUS_SUBSCRIBE_PORT=4443
- SE_NODE_MAX_SESSIONS=4
deploy:
replicas: 1 # 1 Firefox node x 4 sessions = 4 parallel Firefox tests
"""
# ── Docker commands ──
DOCKER_COMMANDS = [
("docker compose up -d", "Start Grid in background"),
("docker compose ps", "Check running containers"),
("docker compose logs selenium-hub", "View Hub logs"),
("docker compose up -d --scale chrome-node=4", "Scale Chrome to 4 nodes"),
("docker compose down", "Stop and remove all containers"),
]
# ── Verify Grid is running ──
VERIFY_STEPS = [
"1. Open http://localhost:4444/ui in your browser",
"2. You should see the Grid console with registered nodes",
"3. Check that Chrome and Firefox nodes show 'Available' slots",
"4. Run a quick test to verify connectivity (next lesson)",
]
print("Method 1: Standalone Mode")
print("=" * 55)
for step in STANDALONE_SETUP["steps"]:
print(f" {step}")
print(f"\n\nMethod 2: Docker Compose (Recommended)")
print("=" * 55)
print(DOCKER_COMPOSE)
print(f"\nDocker Commands:")
for cmd, desc in DOCKER_COMMANDS:
print(f" $ {cmd}")
print(f" → {desc}")
print(f"\nVerification:")
for step in VERIFY_STEPS:
print(f" {step}")
shm_size: 2gb setting in Docker Compose is critical for Chrome. Chrome uses /dev/shm (shared memory) for rendering, and Docker’s default shared memory allocation is only 64 MB. Without increasing it, Chrome crashes with “session deleted because of page crash” errors during tests that render complex pages. Always set shm_size to at least 2 GB for Chrome nodes.selenium/standalone-chrome:4.18.1 for the simplest possible Docker setup — a single container that includes both the Grid and a Chrome browser. Run it with docker run -d -p 4444:4444 --shm-size=2g selenium/standalone-chrome:4.18.1. This gives you a Grid with one Chrome browser in seconds, perfect for local development and quick CI pipelines. Scale to Hub + Node architecture when you need multiple browsers or more parallelism.selenium/node-chrome:4.18.1) rather than using :latest. The :latest tag can change unexpectedly when a new version is published, potentially breaking your tests with incompatible browser or driver versions. Pinned versions guarantee reproducibility — the same image today produces the same environment tomorrow.Common Mistakes
Mistake 1 — Not setting shm_size for Chrome Docker nodes
❌ Wrong: Running Chrome nodes without shm_size: 2gb — Chrome crashes randomly with “page crash” errors on complex pages.
✅ Correct: Always including shm_size: 2gb (or higher) in the Docker Compose configuration for Chrome nodes.
Mistake 2 — Using :latest tag for Selenium Docker images in CI/CD
❌ Wrong: image: selenium/node-chrome:latest — pipeline breaks when a new version is published with a breaking change.
✅ Correct: image: selenium/node-chrome:4.18.1 — pinned version ensures the same behaviour every time the pipeline runs.