Containerizing browser automation without hiding complexity

Browser behavior depends on the browser binary, automation library, operating-system packages, fonts, locale, and sometimes GPU settings. Pin them as one tested unit rather than independently upgrading pieces in production.

Use an image built for the selected automation framework when possible, then add only the application and required system dependencies. Rebuild regularly so reproducibility does not become permanent staleness.

• Pin image and package versions.
• Install only required browser engines.
• Set timezone, locale, and fonts explicitly.
• Record the runtime version with every job.

Browsers consume memory, shared memory, file descriptors, and CPU in bursts. A job that works locally can fail under container limits with symptoms that look like navigation bugs.

Measure peak usage with realistic concurrency. Bound the number of pages and contexts, close resources deterministically, and make worker concurrency configurable per environment.

environment:
  MAX_CONCURRENT_JOBS: 2
  PAGE_TIMEOUT_MS: 30000
  ARTIFACT_RETENTION_HOURS: 24
shm_size: 1gb
restart: unless-stopped

Screenshots, traces, HTML snapshots, downloads, and console logs turn an intermittent failure into evidence. Store them under an execution identifier and return a small manifest to the calling system.

Capture detailed artifacts selectively: always for terminal failures, sampled for success, and temporarily at higher rates during investigation. This controls storage without sacrificing diagnosis.

A missing selector, blocked session, browser crash, network timeout, and full disk require different recovery. Normalize these outcomes at the worker boundary so orchestration can retry or escalate intelligently.

Do not let raw automation exceptions become the public API. Return stable failure codes with a short message, retryability, and artifact references.

Test the same entrypoint, image, environment contract, and artifact destination used in production. Health checks should prove the worker can launch the browser, not only that the container process exists.

Roll out version changes with a representative job set and compare duration, memory, failures, and output quality before replacing the previous runtime.