Docker

Why use the Docker image instead of installing browsers on the runner

The main reason I use the Docker image on CI: consistency. The same Ubuntu base, the same browser versions, the same system libraries — regardless of which runner picks up the job. I've had visual regression tests fail because the runner had a slightly different libpango version that changed text rendering. Docker eliminates that class of problem.

The image is at mcr.microsoft.com/playwright:v1.x-noble (Ubuntu 24.04) or v1.x-jammy (Ubuntu 22.04). The Playwright npm package itself is NOT in the image — you still run npm ci to install it. The image only provides browsers and system dependencies.

# Отримати образ (зазвичай CI робить це автоматично)
docker pull mcr.microsoft.com/playwright:v1.50.0-noble

The flags that actually matter when running

--ipc=host — this one bites people. Chromium uses shared memory between the browser process and renderer processes. Docker containers have a tiny /dev/shm by default (64MB). Chromium exceeds this and crashes with cryptic errors. --ipc=host makes the container share the host's IPC namespace, giving Chromium enough memory.

--init — without it, PID 1 inside the container is your shell or Node process. PID 1 has special signal-handling behavior that can cause child processes (browser sub-processes) to become zombies that never get cleaned up. --init puts a proper init process at PID 1.

# Запустити контейнер для e2e тестів (довірений код)
docker run -it --rm --init --ipc=host   mcr.microsoft.com/playwright:v1.50.0-noble /bin/bash

# Для скрейпінгу ненадійних сайтів — окремий користувач + seccomp
docker run -it --rm --init --ipc=host   --user pwuser   --security-opt seccomp=seccomp_profile.json   mcr.microsoft.com/playwright:v1.50.0-noble /bin/bash

Using the image in CI

In GitHub Actions, using the image as a container means I skip the browser install step. The CI job just installs npm packages and runs tests — browsers are already there.

Note the --user 1001 option — GitHub Actions runs as a non-root user by default, and the container needs to match. Without this you get permission errors on the workspace files.

# GitHub Actions з Docker-образом
name: Playwright Tests
on:
  push:
    branches: [ main ]
jobs:
  playwright:
    name: Playwright Tests
    runs-on: ubuntu-latest
    container:
      image: mcr.microsoft.com/playwright:v1.50.0-noble
      options: --user 1001
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v5
        with:
          node-version: lts/*
      - name: Install dependencies
        run: npm ci
      - name: Run tests
        run: npx playwright test

Running Playwright server in Docker, tests on the host

Sometimes I want browsers inside Docker but the tests running locally — useful when I'm on a Mac but need Linux browser behavior. I start the Playwright server in Docker and connect to it via websocket.

# Запустити Playwright-сервер в Docker
docker run -p 3000:3000 --rm --init -it   --workdir /home/pwuser --user pwuser   mcr.microsoft.com/playwright:v1.50.0-noble   /bin/sh -c "npx -y playwright@1.50.0 run-server --port 3000 --host 0.0.0.0"

# Підключити тести до сервера
PW_TEST_CONNECT_WS_ENDPOINT=ws://127.0.0.1:3000/ npx playwright test

Choosing the right image tag

Always pin to an exact Playwright version (v1.50.0-noble, not latest). Using latest means CI can silently switch to a newer browser version and break your visual regression baselines. I update the version intentionally when I'm ready to update the baselines too.

Don't use Alpine-based images for Playwright. Firefox and WebKit are compiled against glibc — they simply won't run on Alpine which uses musl. Only Chromium works on Alpine, and even then it requires workarounds.