ScreenshotNeo

BlogHow-to

How to Run Chrome Dev and Beta with Docker Selenium

Run Chrome Dev or Beta with Docker Selenium using standalone containers or Grid nodes. Learn the right image tags, architecture limits, and troubleshooting steps.

By the ScreenshotNeo team4 October 20266 min read

Direct answer: For one remote browser, run selenium/standalone-chrome:beta or selenium/standalone-chrome:dev, publishing ports 4444 and 7900 and allocating 2 GB of shared memory. For a Grid node, use the matching selenium/node-chrome tag and point it at the hub with SE_EVENT_BUS_HOST. The documented Dev and Beta Chrome images are for Linux on AMD64.

Choose an image and deployment

Use case Image When to choose it
One browser endpoint selenium/standalone-chrome:beta or :dev Local development or a simple remote WebDriver service.
Chrome for Testing standalone selenium/standalone-chrome-for-testing:beta or :dev Use this distinct image family when you specifically need the Chrome for Testing variant.
Grid browser node selenium/node-chrome:beta or :dev Attach a browser node to a separately run Selenium Hub.

The tags select a browser channel; they do not mean the browser version stays fixed. For repeatable CI, choose a release-specific image tag using the Docker Selenium release information and check the corresponding Grid, Chrome, and ChromeDriver versions. See the official Docker Selenium README and release tags for the current choices.

Run a standalone Chrome Beta container

This command follows Docker Selenium’s documented standalone setup. It publishes the WebDriver endpoint on port 4444, the browser viewing endpoint on 7900, and reserves 2 GB of shared memory for Chrome.

docker run --platform linux/amd64 --rm -it \
  -p 4444:4444 -p 7900:7900 \
  --shm-size 2g selenium/standalone-chrome:beta

For the Dev channel, change only the final tag:

docker run --platform linux/amd64 --rm -it \
  -p 4444:4444 -p 7900:7900 \
  --shm-size 2g selenium/standalone-chrome:dev

When the container is ready, configure your Selenium client to use the remote WebDriver endpoint at http://localhost:4444. Port 7900 is for viewing the browser session. Keep the container running while the client creates and uses sessions; stop it with Ctrl+C. The --rm option removes the container after it stops.

Try it with Python Selenium

Install the Selenium Python package in your client environment, then run this script while the container is up:

from selenium import webdriver
from selenium.webdriver.chrome.options import Options

options = Options()
driver = webdriver.Remote(
    command_executor="http://localhost:4444",
    options=options,
)
try:
    driver.get("https://example.com")
    print(driver.title)
finally:
    driver.quit()

The browser runs in the container; the Python script is a client connecting to its remote WebDriver endpoint. From another container, localhost refers to that client container itself, not the Selenium container. Use a reachable service name or hostname on the shared Docker network instead.

Run Chrome Dev or Beta as a Selenium Grid node

In Grid, the hub accepts WebDriver requests and browser nodes provide sessions. Start the hub with its event-bus ports available to the node. The node’s SE_EVENT_BUS_HOST must resolve to the hub from inside the node container.

Here is a minimal Compose example for Beta. Save it as compose.yaml:

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

  chrome:
    image: selenium/node-chrome:beta
    shm_size: 2gb
    depends_on:
      - hub
    environment:
      SE_EVENT_BUS_HOST: hub

Start the services with docker compose up. Send WebDriver requests to http://localhost:4444 from the host. For Dev, change the node image to selenium/node-chrome:dev. For reproducible CI, pin the hub and node to compatible release tags instead of leaving the hub on latest; consult the Docker Selenium release page when selecting them.

The official Grid setup uses ports 4442–4444 for hub communication and WebDriver access, and allocates 2 GB shared memory to the Chrome node. If the node cannot register, first check that the hub hostname resolves on the Compose network, the event-bus ports are reachable, and both images belong to compatible releases.

Architecture and version considerations

  • AMD64: The documented Chrome Dev and Beta images target Linux/AMD64. The examples specify --platform linux/amd64 explicitly for standalone use.
  • ARM64: Do not assume those Dev/Beta image tags will work natively on ARM64. Docker Selenium’s ARM64 Chrome images use the Chromium driver of the same major version from a stable-channel package, which is a different path.
  • Chrome for Testing: The documented Chrome for Testing image is also Linux/AMD64 only. Its image names include chrome-for-testing; they are not interchangeable names for the ordinary standalone images.
  • Moving channel tags: :dev and :beta track pre-release channels, so browser versions can change over time. Pin a release-specific tag for repeatable CI and review the release date and component versions when upgrading.

Troubleshooting

Symptom Likely cause Fix
Container exits or image cannot run on this machine The Dev/Beta Chrome image is being used on an unsupported architecture. Use Linux/AMD64 as documented. On ARM64, use the documented ARM64 Chromium/stable-channel path rather than assuming Dev/Beta is available.
Chrome crashes, tabs fail, or the browser reports shared-memory errors The container has insufficient shared memory. Set --shm-size 2g for standalone or shm_size: 2gb for the node, matching the documented setup.
Client gets connection refused The container is not ready, port 4444 was not published, or the client is using the wrong hostname. Wait for startup, publish/map port 4444, and connect to the host address from the client’s network context. Inside another container, do not use localhost to refer to Selenium.
Grid node does not appear The event-bus host is wrong or its ports 4442/4443 are unreachable; hub and node may also be incompatible versions. Set SE_EVENT_BUS_HOST to the hub’s network name, ensure the hub exposes ports 4442–4444 as needed, and use compatible release tags.
Browser viewing page is unavailable Port 7900 was not published or is blocked. Publish -p 7900:7900 and check host firewall or port conflicts.
A CI run changes behavior without code changes A moving :dev or :beta tag pulled a newer browser release. Pin a release-specific image tag and update it deliberately after checking Chrome, ChromeDriver, and Grid release compatibility.
Chrome for Testing image pull fails or does not start The Chrome for Testing variant has a different image name and is Linux/AMD64 only. Use selenium/standalone-chrome-for-testing:beta or :dev on supported architecture, or use the ordinary standalone-chrome family if that is what you intended.

Performance, reliability, and cost

The 2 GB shared-memory setting is Docker Selenium’s documented configuration for these examples, not a performance benchmark. Actual capacity depends on the pages under test and the number of concurrent browser sessions. Start with the documented value, then monitor container memory and session failures under your workload before increasing concurrency.

For reliability, pin image versions in CI, keep hub and node versions compatible, and treat channel upgrades as browser changes that may affect tests. The --rm option makes a local throwaway container easy to clean up; persistent test infrastructure should use an explicit lifecycle and version policy. Container and Selenium costs depend on where and how you run Docker; the image tags themselves do not establish a hosting price.

Or skip the browser setup

If your goal is to capture a page rather than run browser automation, ScreenshotNeo provides a website screenshot API and MCP server. The API returns an image or PDF from one GET request; see the API documentation.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp
import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)
const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
  • Cookie banners are accepted like a visitor, and 60+ known consent platforms, newsletter popups, and chat widgets are removed before the shot; each step can be turned off.
  • Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing; response headers identify the page verdict and billing status.
  • An MCP server gives Claude, Cursor, and other MCP clients screenshot, page-info, and PDF capture tools.
  • 1,000 screenshots a month are free with no card; paid plans start at $5 for 3,000.

Sign up for 1,000 free screenshots a month, with no card required.

FAQ

Can I use the regular Chrome image instead of Chrome for Testing?

Yes. The ordinary selenium/standalone-chrome and selenium/node-chrome families are the direct choices in the commands above. Chrome for Testing is a separately named image family.

Can I use Dev and Beta in the same Grid?

They are separate node image choices. You can configure nodes for each channel, but keep Grid components on compatible releases and identify the browser channel your test session needs.

Does exposing port 7900 make WebDriver work?

No. WebDriver clients connect through port 4444. Port 7900 is for viewing the browser session.

Should I use a channel tag in CI?

Use it when intentionally following the moving pre-release channel. For repeatable CI, pin a release-specific tag and plan upgrades.