DOCKER BASE IMAGE EOL CHECK · RUNS IN YOUR BROWSER

Is your Dockerfile's base image still supported?

A base image reference can be pinned to an exact content digest and still start from a release line — node:18, python:3.9, ubuntu:20.04 — that its own publisher stopped patching months ago. Pinning stops the reference from being silently repointed; it says nothing about whether anyone is still shipping security fixes for what it points to. Paste your Dockerfile below and this page checks every FROM line's release line against a small, dated end-of-life table.

Nothing is uploaded. The Dockerfile you paste is read in this browser and never leaves your device, and this tool makes no network calls of its own — the end-of-life data is a checked-in snapshot, not a live lookup.

1. Paste one or more Dockerfiles

Copy the contents of each Dockerfile (or Dockerfile.* / *.dockerfile) you want checked.

Paste at least one Dockerfile above and click Check.

Prefer a CLI, or want this in your own CI?

Same logic, zero dependencies, one file:

python3 check.py                  # scan every Dockerfile under the current directory
python3 check.py /path/to/repo    # scan a specific checkout
python3 check.py --format json    # machine-readable
python3 check.py --fail-on-risk   # exit 2 if any base image is eol or deprecated-image
python3 check.py --warn-days 30   # narrow the eol-soon warning window

Get check.py from the repo — stdlib only, nothing to install, no network calls. Wire --fail-on-risk into your own CI to block a base image whose release line has already gone end-of-life.

Common questions

Isn't a pinned base image already safe?

Pinning (to a tag or a content digest) only stops the reference from being silently repointed to different bytes. It says nothing about whether the release line those bytes belong to is still receiving security patches from its publisher. A FROM line can be pinned to an exact digest and still be building on a Node, Python, or distro release that stopped getting fixes months ago -- pinning and end-of-life are independent questions.

See Docker Base Image Pin Check for the pinning question specifically.

Where does the end-of-life data come from?

A small, curated table checked into this tool, not a live lookup -- the page and the CLI make no network calls of their own. Each entry names the project whose own release schedule or stated support-length policy it was read from, and whether that date is the project's own published end date (confirmed) or inferred from its policy (estimated). Re-verify any finding against the upstream project's own page before relying on it, especially an estimated one, and especially long after the dataset's own snapshot date shown in the results.

Does a clean scan mean my image has no vulnerabilities?

No. This checks one specific thing: whether the base image's release line, as named by its tag, has passed its publisher's own end-of-life date. It is not a vulnerability scan, does not inspect installed packages, and makes no claim about CVEs present in a supported image.

What if my tag is latest, or I use a private registry image?

A tag of latest (or no tag at all, which resolves to latest) names no fixed release line, so it cannot be checked against a dated table -- it is reported as unknown-tag rather than guessed at. The same applies to any image outside this tool's curated table, including private-registry and custom images: reported as unknown-image, which is not evidence of anything either way.

More: how this compares to a vulnerability scanner, how it compares to checking end-of-life dates by hand, or what to do once a finding comes back end-of-life.