Chapter 20Lesson 03~225 minutes

Deploying Grid with Containers, Kubernetes, and Cloud Infrastructure: Configuration, Design Patterns, and Trade-Offs

Once the local Compose workflow works, deployment becomes an architecture decision. The goal is not to pick the most sophisticated platform; it is to choose the smallest topology that satisfies browser coverage, concurrency, isolation, observability, security, and recovery requirements.

ArchitectureDynamic GridKubernetesHosted cloudTrade-offs

Learning objectives

Choose local drivers, bare Grid, static containers, Dynamic Grid, Kubernetes, or hosted browser services intentionally.
Explain static versus per-session browser-container lifecycle.
Compare Compose with Kubernetes without confusing orchestration with test-framework responsibilities.
Design image, resource, artifact, and security policies around observable failure modes.
Use a decision table instead of defaulting to the largest topology.

1. Deployment spectrum: complexity should follow need

The following table organizes the key choices and evidence for Deployment spectrum: complexity should follow need. Use it together with the surrounding prose so the rows serve as a comparison aid rather than standalone rules.

Option	Best fit	Strength	Cost / risk
Local driver	Developer feedback, one/few browsers	Lowest moving parts	No shared remote capacity
Bare Standalone Grid	Small trusted host	Simple remote endpoint	Host/browser dependencies managed manually
Static Docker Grid	Small/medium repeatable lanes	Pinned runtime, easy recreation	Capacity is pre-provisioned
Dynamic Grid	Bursty isolated sessions on Docker	Per-session container isolation	Docker socket/API is a high-privilege boundary
Kubernetes/Helm	Shared platform with orchestration needs	Scheduling, policies, declarative rollout	Operational complexity; readiness/capacity still need tuning
Hosted browser cloud	Need broad browser/OS coverage without owning runtime	Provider operates browsers	Cost, data residency, network/identity integration

2. Static nodes versus Dynamic Grid

Static Grid starts browser Nodes ahead of time. Dynamic Grid uses Docker-backed Node/Standalone roles that create a child browser container when a matching session arrives. This improves per-session isolation and elasticity, but it introduces a privileged control boundary: the Grid service can ask the container runtime to create new workloads.

[docker]
configs = [
  "selenium/standalone-chrome:4.47.0-20260808", '{"browserName": "chrome"}',
  "selenium/standalone-firefox:4.47.0-20260808", '{"browserName": "firefox"}'
]
url = "http://127.0.0.1:2375"
assets-path = "/opt/selenium/assets"

Docker socket/API is effectively host-control power

Mounting /var/run/docker.sock or exposing an unauthenticated Docker API is not a minor convenience. Restrict the service, host, network, and identities that can control the daemon. Keep Dynamic Grid optional in this course chapter.

3. Docker Compose versus Kubernetes

The following table organizes the key choices and evidence for Docker Compose versus Kubernetes. Use it together with the surrounding prose so the rows serve as a comparison aid rather than standalone rules.

Dimension	Compose	Kubernetes/Helm
Desired state	Single-host project services	Cluster controllers manage pods/services
Networking	Project network + service DNS	Pod/Service DNS, NetworkPolicy, Ingress
Readiness	Container health + Grid /status	Pod readiness + Grid/browser/application readiness remain distinct
Scaling	Manual/Compose-oriented	Replica/autoscaling mechanisms; Selenium chart supports KEDA patterns
Persistence	Host volumes/binds	PVC/object storage/external systems
Best learning path	Mandatory local lab	Optional architecture for this chapter

The current official chart is selenium-grid 0.58.0 and defaults to Selenium image tag 4.47.0-20260808. The chart can deploy a basic Grid or isolated components. Use a versioned values file so configuration is reviewable in Git rather than hidden in a long shell command.

helm repo add docker-selenium https://www.selenium.dev/docker-selenium
helm repo update
helm search repo docker-selenium --versions
# Optional only; requires a disposable cluster:
helm install selenium-grid docker-selenium/selenium-grid --version 0.58.0 --namespace selenium --create-namespace

4. Pinned images versus floating tags and upgrade strategy

Pin the Grid/browser image, chart version, and—where your supply-chain policy requires it—the OCI digest. Roll forward intentionally. A browser image upgrade can change Selenium Server, browser, driver, OS packages, Java runtime, VNC stack, and architecture support in one change. Record old and new versions, run a compatibility smoke matrix, retain evidence, and keep a rollback path.

5. Ephemeral nodes versus persistent evidence

Browser profiles should usually disappear with the session. Evidence should not disappear accidentally. Separate these concerns: write only approved artifacts to per-session mounted paths or external storage; set quotas and retention; do not mount a shared personal downloads directory across parallel sessions.

Artifact	Default policy	Why
Browser profile	Ephemeral	Avoid state leakage and credential persistence
Screenshot on failure	Persist short-term	High triage value, modest size
Grid/browser logs	Persist bounded subset	Correlate session/runtime failures
Video	Opt-in / short retention	High CPU/storage/privacy cost
Downloads	Persist only when test meaning requires	Can contain sensitive data; use per-test directories

6. Privileged flags versus safer defaults

Do not normalize --privileged, broad host mounts, disabled browser sandboxes, or public Docker APIs. If a browser fails under resource pressure, measure shared memory/CPU/memory first. If a certificate/proxy policy blocks traffic, fix trust or network policy at the correct boundary rather than disabling TLS validation globally.

7. Worked decision: three CI profiles

Profile A: 20 pull requests/day, Chrome + Firefox smoke, 2 concurrent sessions. Choose static Compose Grid on a private runner. Profile B: bursty 60-session nightly suite with strong per-session isolation on an existing Kubernetes platform. Evaluate Helm/Dynamic Grid plus quotas and autoscaling. Profile C: must test Safari/macOS versions that the team does not operate. A hosted provider or owned macOS infrastructure may be justified. In every case, test intent remains in the suite; infrastructure config stays in deployment code.

Knowledge check

When is Dynamic Grid more appropriate than static Nodes?

Does moving to Kubernetes make Selenium waits or assertions more reliable automatically?

Why are personal/shared browser profiles a poor optimization for container Grid?

What should be versioned together for a Kubernetes Selenium deployment?

When can a hosted browser cloud be the smaller architecture?

Next lesson

Deploying Grid with Containers, Kubernetes, and Cloud Infrastructure: Diagnostics, Failure Modes, and Production Practices

Continue with Deploying Grid with Containers, Kubernetes, and Cloud Infrastructure: Diagnostics, Failure Modes, and Production Practices. It builds directly on the state, evidence, and operating assumptions established here, so carry those constraints forward rather than treating the next page as an isolated topic.

Official references and current-version notes

Version baseline — August 2026

These lessons pin Selenium Python and Grid concepts to 4.47.0, Docker Selenium image tag 4.47.0-20260808, and Helm chart 0.58.0. The nightly images track Selenium 4.48.0-SNAPSHOT and are intentionally excluded from the mandatory path.

Keep the academy open

Support free, practical DevOps education.

Every lesson is designed to remain readable in a browser, downloadable from GitHub, and usable without a paid learning platform. Contributions help expand and maintain the curriculum.

Ethereum / ERC-20

0x716c4Ab160C4B66F31a28AE2448BfF68fc3a2ef0Send only Ethereum/ERC-20 compatible assets to this address.