Introduction

Installing Chromium into a Node Alpine image is straightforward if you accept the version currently available in that Alpine repository. Installing exactly Chromium 73 is harder, because Alpine package versions are tied to specific Alpine releases and old package versions eventually disappear from normal repositories. The real answer is usually either "use the matching Alpine repository snapshot" or "switch to a base image where exact browser pinning is easier."

Why Exact Chromium Version Pinning Is Hard on Alpine

Alpine packages come from the repositories associated with a specific Alpine release. A Node image such as node:12-alpine inherits that Alpine base. If Chromium 73 is no longer present in the active repository for that release, apk add chromium=73... will fail even though the syntax is technically correct.

So there are two separate problems:

• installing Chromium on Alpine at all
• pinning one exact historical Chromium build

The first is easy. The second is fragile.

Install the Repository Version of Chromium

If you only need Chromium and do not require exactly version 73, use the version provided by the current image repository.

1FROM node:12-alpine
2
3RUN apk add --no-cache     chromium     nss     freetype     harfbuzz     ca-certificates     ttf-freefont
4
5ENV CHROME_BIN=/usr/bin/chromium-browser

This is the practical solution for many Puppeteer- or headless-browser-style containers.

If You Truly Need Chromium 73

If the requirement is specifically Chromium 73, you need a repository that still contains that package build or a custom package source you control. That typically means one of these approaches:

• use an old Alpine repository snapshot that still carries the package
• copy in a known APK and its matching dependencies
• stop using Alpine for this container and move to a base image with easier historical package availability

That is why exact old-browser pinning on Alpine is usually a maintenance problem, not a Dockerfile syntax problem.

Why a Different Base Image Is Often Better

If exact browser version matters, Debian- or Ubuntu-based images are often easier to manage because the browser ecosystem and third-party package tooling are friendlier to version pinning.

For many teams, the best practical fix is to stop fighting Alpine for this use case.

A Debian-style example:

FROM node:12-bullseye

RUN apt-get update && apt-get install -y chromium && rm -rf /var/lib/apt/lists/*

This still does not guarantee Chromium 73 specifically, but it usually gives a more predictable browser packaging experience than Alpine.

Puppeteer Considerations

A lot of Node plus Chromium questions actually come from Puppeteer. If that is your case, remember that Puppeteer versions often expect specific Chromium revisions. Mismatching Puppeteer and browser versions can create runtime errors even after the package installs successfully.

So the full compatibility question is often:

• Node version
• Alpine version
• Chromium version
• Puppeteer version

Solving only one of those can still leave the container broken.

Runtime Flags Often Needed in Containers

Even after Chromium installs, containers frequently need runtime flags such as these:

chromium-browser --headless --no-sandbox --disable-gpu --remote-debugging-port=9222

The --no-sandbox flag is common in containers, though it should be used with clear security understanding. Installation success does not guarantee runtime success.

Keep the Image Maintainable

If you decide to pin an old browser manually, document why. Otherwise a future maintainer will only see a difficult Dockerfile and a brittle package source.

Good questions to answer in comments or documentation:

• why Chromium 73 specifically is required
• which app dependency depends on that version
• how the package source is expected to stay available

Without that context, the image becomes hard to upgrade safely.

Common Pitfalls

• Assuming apk add chromium=<version> will work forever against a normal Alpine mirror.
• Treating Alpine package availability as if it were a permanent historical archive.
• Solving the install step without checking Puppeteer or runtime compatibility.
• Using Alpine for strict browser version pinning when another base image would be easier to maintain.
• Forgetting the additional runtime libraries and flags needed after installation.

Summary

• Installing the current Chromium package on Alpine is easy, but pinning exactly Chromium 73 is not.
• Exact old-version pinning usually requires a matching old repository snapshot or a custom package source.
• If browser-version control is critical, a Debian-based image is often easier than Alpine.
• Check browser, Node, and automation-library compatibility together, not separately.
• For long-term maintainability, document why the exact Chromium version is required before freezing the container around it.