Introduction

This guide walks through containerizing a small Node.js script that runs a Playwright end-to-end test suite on a repeating schedule and emails a summary when a run fails. The worked example throughout is a small test suite for a personal project, but the pattern (running tests on an interval inside a container, keeping the last result, emailing on failure) applies to any script built the same way.

The end result runs as a permanently-alive container, not a one-shot job triggered by a scheduler: the script keeps its own interval loop, and Docker’s job is only to keep that process running, restart it if it crashes, and isolate its dependencies.

Why containerize a background script

A script like this already runs on a development machine with node runner.js. Moving it into a container solves three separate problems at once.

Prerequisites: check your Playwright version

The official Playwright Docker images are versioned to match the npm package exactly. The Playwright documentation is explicit about this: “If the Playwright version in your Docker image does not match the version in your project/tests, Playwright will be unable to locate browser executables.” The ^1.48.0 style range that npm install playwright writes into package.json is a floor, not the installed version, so check the version that is actually on disk before writing the Dockerfile.

$ cat package.json | grep playwright
$ npx playwright --version

Commit a package-lock.json if you do not already have one (npm install creates it). It pins the exact version for anyone, or anything, that rebuilds the image later.

Project layout

Six files, all at the root of the project:

The example script below is a minimal, generic version of the real pattern: a loop, a JSON results file, and an email alert. Swap runTestSuite() for however your own project actually runs its tests, if not through the Playwright test runner directly.

require('dotenv').config();
const { execFile } = require('child_process');
const nodemailer = require('nodemailer');
const fs = require('fs');
const path = require('path');

const RESULTS_FILE = path.join(__dirname, 'results', 'last-run.json');
const INTERVALS_MIN = (process.env.INTERVALS_MIN || '360,420,480')
  .split(',').map(Number).filter(n => n > 0);

function saveResult(result) {
  fs.mkdirSync(path.dirname(RESULTS_FILE), { recursive: true });
  fs.writeFileSync(RESULTS_FILE, JSON.stringify(result, null, 2));
}

async function sendSummary(subject, text) {
  const transporter = nodemailer.createTransport({
    host: process.env.SMTP_HOST,
    port: Number(process.env.SMTP_PORT || 587),
    secure: Number(process.env.SMTP_PORT) === 465,
    auth: { user: process.env.SMTP_USER, pass: process.env.SMTP_PASS },
  });
  await transporter.sendMail({
    from: process.env.SMTP_USER,
    to: process.env.ALERT_EMAIL,
    subject,
    text,
  });
}

function runTestSuite() {
  return new Promise((resolve) => {
    execFile('npx', ['playwright', 'test', '--reporter=json'], { cwd: __dirname }, (error, stdout) => {
      let stats = null;
      try { stats = JSON.parse(stdout).stats; } catch { /* stdout wasn't JSON; stats stays null */ }
      resolve({ passed: !error, stats });
    });
  });
}

async function runOnce() {
  const { passed, stats } = await runTestSuite();
  const result = { timestamp: new Date().toISOString(), passed, stats };
  saveResult(result);
  if (!passed) {
    await sendSummary('Test run failed', 'One or more tests failed. See results/last-run.json for details.');
  }
}

function randomIntervalMs() {
  const m = INTERVALS_MIN[Math.floor(Math.random() * INTERVALS_MIN.length)];
  return m * 60 * 1000;
}

async function main() {
  console.log('Test runner started, checking every ' + INTERVALS_MIN.join('/') + ' min (randomized)');
  while (true) {
    try { await runOnce(); } catch (e) { console.error(e); }
    await new Promise(r => setTimeout(r, randomIntervalMs()));
  }
}

main();

{
  "name": "e2e-runner",
  "version": "1.0.0",
  "main": "runner.js",
  "scripts": {
    "start": "node runner.js"
  },
  "dependencies": {
    "playwright": "1.63.0",
    "nodemailer": "^6.9.13",
    "dotenv": "^16.4.5"
  },
  "engines": {
    "node": ">=18"
  }
}

The Dockerfile

The official Playwright image already contains Node, Chromium (and the other engines, if your tests use them) and their OS-level dependencies, so there is no separate base-image and browser-install step to maintain.

# Pin this to the Playwright version actually installed in your project
# (see "Prerequisites"). Do not use the semver range from package.json.
FROM mcr.microsoft.com/playwright:vX.Y.Z-noble

WORKDIR /app

COPY package.json package-lock.json ./
RUN npm ci --omit=dev

COPY . .

# Run as the image's built-in non-root user instead of root
USER pwuser

CMD ["node", "runner.js"]

Replace vX.Y.Z-noble with the exact version from the “Prerequisites” step, for example v1.63.0-noble. The -noble suffix targets an Ubuntu 24.04 base image; Playwright also publishes -jammy (22.04). The two must be the same family the reader’s own Docker host expects, but since the image is self-contained this rarely matters; keep -noble unless a specific reason says otherwise.

Secrets and configuration

Nothing that changes between environments, and nothing secret, belongs in the image. Read it from the environment instead.

INTERVALS_MIN=360,420,480
SMTP_HOST=smtp.gmail.com
SMTP_PORT=587
SMTP_USER=your-address@gmail.com
SMTP_PASS=your-16-character-app-password
ALERT_EMAIL=you@example.org

node_modules
.env
.git
results/
debug/
npm-debug.log

Build and test the container locally

Build and run it on the development machine first, with the real .env filled in, before touching the NAS.

$ npm install
$ npx playwright --version
$ docker build -t e2e-runner .
$ mkdir -p results debug
$ docker run -d --name e2e-runner --init --ipc=host 
    --env-file .env 
    -v "$(pwd)/results:/app/results" 
    -v "$(pwd)/debug:/app/debug" 
    --restart unless-stopped 
    e2e-runner
$ docker logs -f e2e-runner

Watch the logs for one full cycle. If a test is failing, confirm the email actually arrives before moving to the NAS: debugging a container on a NAS with no shell access to the host is slower than debugging it locally.

Docker Compose for a permanent Synology deployment

A NAS is not the development machine, so the compose file’s paths change accordingly.

services:
  e2e-runner:
    build: .
    container_name: e2e-runner
    restart: unless-stopped
    init: true
    ipc: host
    environment:
      INTERVALS_MIN: "360,420,480"
      SMTP_HOST: "smtp.gmail.com"
      SMTP_PORT: "587"
      SMTP_USER: "your-address@gmail.com"
      SMTP_PASS: "your-16-character-app-password"
      ALERT_EMAIL: "you@example.org"
    volumes:
      - /volume1/docker/e2e-runner/results:/app/results
      - /volume1/docker/e2e-runner/debug:/app/debug
    mem_limit: 1g

restart: unless-stopped brings the container back after a crash or a NAS reboot. init: true and ipc: host are Playwright’s own recommendations for running Chromium in a container: init avoids treating the app process as PID 1, and ipc: host gives Chromium enough shared memory without a separate /dev/shm size override. mem_limit caps the container so one runaway process cannot starve everything else DSM is running (see “Deploy on Synology” for why this matters on this model).

Deploy on Synology DSM with Container Manager

Steps below are for DSM 7.2, where Container Manager’s Project tab (the docker-compose feature) is available.

Verify the deployment

Four checks, in order of how much they actually prove:

• The project’s status in Container Manager reads Running, and the Log tab shows the startup line from main().
• Restart the container from Container Manager (or run the commands below over SSH) and confirm it comes back on its own.
• Reboot the NAS from Control Panel > Update & Restore and confirm the container is Running again afterward without any manual step.
• Confirm results/last-run.json on the NAS still holds its previous content after a restart: that proves the results live in the mounted volume and not only inside the container’s own filesystem.

$ docker inspect -f "{{.State.Status}}" e2e-runner
$ docker inspect -f "{{.HostConfig.RestartPolicy.Name}}" e2e-runner
$ cat results/last-run.json

Common pitfalls

What you have now

A background script that:

• Runs inside a container image pinned to a known Playwright and browser version
• Comes back on its own after a crash or a NAS reboot, through restart: unless-stopped
• Keeps its results and any debug output outside the container’s own filesystem, on mounted volumes
• Reads its secrets from the environment, never from the image

Official documentation

• Playwright: Docker (image tags, version matching, –init and –ipc=host)
• Google: Sign in with app passwords
• Synology: DS916+ data sheet (CPU and RAM)

Synology’s own Knowledge Center pages for Container Manager’s Project feature did not return readable content at the time of writing (JavaScript-rendered). The absolute-path and folder-pre-creation behavior described under “Deploy on Synology” is confirmed against a detailed third-party walkthrough instead: WunderTech, “Synology Container Manager: How to Use Docker & Docker Compose” (published August 2026).

Keep going