Docker Base Image EOL Check vs. Checking End-of-Life Dates by Hand
A manual check works: open each FROM line's project page and read its support policy. It gets slow the moment there is more than one line to check -- a multi-stage build, a handful of services, or a monorepo full of Dockerfiles. This free tool reads every FROM line you paste at once, in your browser, against a small dated table that names its own source for each entry.
What each approach is for
Checking by hand means finding, for each base image tag, the right page to read -- the
project's own release notes or end-of-life policy -- and working out whether today's
date is past the line it names. For one Dockerfile with one FROM line this can be the fastest
route, and it is the only way to reason about an image outside any curated table.
This checker reads the text of every Dockerfile you paste, pulls out every FROM
line across every build stage, and checks each release line against a small table checked into the tool --
no pull, no build, no browser tab per line. Every finding says whether the date is the project's own
published end date (confirmed) or inferred from its stated support-length policy (estimated), and the table
carries a snapshot date so you know how fresh it is.
| Situation | Better fit |
|---|---|
| One Dockerfile, one FROM line, and you already know the project's policy. | Checking by hand -- often faster than opening this page at all. |
| A multi-stage build, several services, or a monorepo with many Dockerfiles. | This checker -- it reads every FROM line at once instead of one tab per line. |
The base image is outside this tool's curated table, or tagged latest. | Checking by hand -- the tool reports these as unknown rather than guessing. |
| A finding this tool marks estimated, and you want the project's own words. | Both -- re-verify the specific finding against the upstream page rather than re-checking everything. |
Treat this checker as the first pass across many FROM lines, and a manual read of the upstream page as the second pass on whichever findings matter enough to double-check. This page names no product or company being compared against -- checking a project's own release page by hand is a method, not a competitor.
Common questions
Why not just look up each base image's end-of-life date myself?
You can, and for one Dockerfile with one FROM line it may be faster than pasting it in here. It stops scaling once there is more than one: a multi-stage build can name a different release on every FROM line, a monorepo can hold dozens of Dockerfiles, and each lookup means finding and reading the right project's own release notes or end-of-life policy correctly. This tool reads every FROM line in every file you paste at once and reports all of them against one dated table.
Is a manual lookup on the project's own release page more accurate than this tool's table?
It can be, since it is live and this tool's table is a checked-in snapshot with its own as-of date shown in the results. The tradeoff is throughput and consistency: a manual pass across many FROM lines takes one browser tab and one careful read per line, and it is easy to skip a stage in a multi-stage build or misread a policy page. This tool checks every line the same way, every time, and tells you plainly which findings are the project's own confirmed date versus an estimate inferred from its policy -- a distinction a quick manual read can blur.
Does this replace reading the base image's own release page?
No, and the page says so: re-verify any finding against the upstream project's own page before relying on it, especially an estimated one. What this tool replaces is doing that lookup for every FROM line in every Dockerfile, every time you want to know -- it narrows the manual work to the findings worth double-checking instead of every line you have.
What does a manual check catch that this tool cannot?
A base image or private-registry reference outside this tool's curated table, and a tag of latest, are both reported as unknown rather than guessed at -- a manual reader who knows the project can sometimes reason about those where the table stays silent. A manual reader can also catch a policy change the table's snapshot has not picked up yet, which is exactly why the results carry a snapshot date and a re-verify note.