skip to content

How would you decide between the official Playwright image and `playwright install --with-deps` on a CI runner?

level: principalimportance: should knowfreq 36%

answer

  1. Same problem, two ownership models
  2. Who owns the environment
  3. Pinned tag versus per-job install
  4. Extra tooling forces the question
  5. Extending the official image is common

basics

~20 s

Choose the image when the environment should be pinned and the job needs nothing else; choose your own base plus an install step when it needs other tooling. Often the answer is an image built from the official one.

solid answer

~50 s

Both routes solve the same problem: getting version-matched browsers and their system libraries onto the runner. The official image pins all of it in one tag, removes a slow package-manager step from every job, and needs no root at run time — but it dictates the OS and toolchain, is large, and still leaves container-runtime concerns like `--ipc=host` to you. Your own base plus `npx playwright install --with-deps chromium` keeps the toolchain yours and downloads only what you launch, at the cost of an install step per job, elevated privileges for the package manager, and a version pin that lives in `package.json` rather than in a visible tag. Decide on whether the job needs other tools, whether you control privileges, and how often you re-run old commits. Building your own image FROM the official one usually wins.

code

bash · 2 lines
bash
npx playwright install --with-deps chromium
npx playwright test --project=chromium

go deeper

for a junior

Know both routes exist: run inside the official image, or install browsers and their system packages yourself on a plain runner before the suite starts.

for a middle

Explain the concrete difference — a pinned tag with nothing to install versus an install step that needs privileges and network to the distro mirrors.

for a senior

Argue from constraints you have actually hit: privileges on the runner, extra tooling in the job, cold setup time, and reproducing an old run months later.

for a principal

Own the standard across teams, including the hybrid image built from the official one, and name the mechanism that keeps browsers and library version locked together.

## The two shapes of the same job There are two ways to get browsers onto a CI machine for a payroll regression suite. **Run in the official image.** The job executes inside `mcr.microsoft.com/playwright:v1.63.0-noble`, which already contains the browser builds for that Playwright version, in `/ms-playwright`, plus every system library they link against, plus a `pwuser` account. There is no browser-install step at all. **Bring your own base.** The job runs on a plain runner or your own image, and an explicit step runs `npx playwright install --with-deps` (optionally naming just the browsers you use) before the suite. Both are legitimate. The decision is about who owns the environment, and how the version pin is enforced. ## What the image buys - **One artefact for the whole environment**: browsers, OS libraries and their versions move together, so "works on my machine" and "works in CI" mean the same build. - **No package-manager step in the job**, which removes a slow, network-dependent, occasionally flaky operation from every run and from every re-run of an old commit. - **No root needed at run time** for library installation, because it happened at image build time. - **A hard version pin** that is visible in one string: the tag has to be bumped alongside `@playwright/test`, so drift is a reviewable diff rather than a silent cache state. ## What the image costs - **The toolchain is theirs, not yours.** The image ships a particular OS and Node line. If the suite also needs a database client, a JDK, a private CA bundle or an internal CLI, you either add layers on top or you are back to owning an image. - **It is large**, carrying three engines' binaries and their libraries even if you only run Chromium. - **It couples upgrades.** Moving Playwright forward now means moving the base OS whenever the tag you need is only published on a newer base. - **Container-runtime detail leaks into your CI config anyway**, most notably `--ipc=host` for Chromium's shared memory — the image does not remove that requirement. ## A decision order that holds up 1. **Does the job need anything else in the same environment?** If yes, the image is a base you extend or a route you skip; if no, the image wins on effort alone. 2. **Do you control the runner's privileges?** `--with-deps` needs elevated rights to install OS packages. Where you cannot get them, the pre-built image is not a preference, it is the only route. 3. **How often do you re-run old commits?** The stronger that need, the more you want the environment pinned in a tag rather than reassembled from whatever the package mirrors serve today. 4. **How much does cold setup time cost you?** Pulling a large image once per runner beats a per-job install; a cache that already holds the browsers can beat both. 5. **Only then**: how many browsers do you really run? A Chromium-only suite on your own base with `npx playwright install --with-deps chromium` is a genuinely small, fast setup. | | Official image | Own base + `--with-deps` | |---|---|---| | Version pin | The image tag | Whatever `package.json` resolves to at install time | | Setup step in job | None | An install step per job unless cached | | Extra tooling | Add layers on top | Already yours | | Root needed at run time | No | Yes, for the OS packages | ## The hybrid, and the rule that survives either choice The common mature answer is neither pure option: build **your own image FROM the official one**, add the two or three tools the suite needs, and pin that in your registry. You keep the matched browser/library pair and get your toolchain back, at the price of owning a build. Whatever you pick, one rule does not move: the browser builds must match the installed Playwright version, and something in version control must make that true — a tag bumped in the same commit as `package.json`, or an install step that runs against the version the lockfile just installed. A team that cannot point at where that is enforced does not have a choice between two strategies; it has an accident that has not happened yet.

  • What tips the decision toward the image regardless of preference?
    Not controlling the runner's privileges. Installing OS packages needs root or sudo, so where you cannot get them the pre-built image is the only route that produces launchable browsers. A strong need to re-run old commits reliably pushes the same way, because a tag pins the environment that a package mirror no longer serves.
  • What does extending the official image cost you?
    You own a build and a registry entry, and you take on rebuilding whenever the upstream tag moves — so the version bump becomes two changes rather than one. In exchange you keep the matched browser and library pair while adding the database client, CA bundle or internal CLI the suite actually needs.
  • Which requirement survives either choice?
    The browser builds must match the installed Playwright version, and something in version control has to make that true: a tag bumped in the same commit as package.json, or an install step run against the version the lockfile just resolved. A team that cannot point at where that is enforced has an accident waiting rather than a strategy.

saying these in an interview costs you the question

  • Assumes the image removes every container concern
  • Picks the image without checking other tooling needs
  • Installs three engines when only one is launched
  • Expects to install OS packages without privileges
  • Cannot say where the version pin is enforced