Dependency End-of-Life Checker

Check whether the runtimes, frameworks and databases you depend on are still supported, with end-of-life and end-of-support dates and their source.

Uses an external data source

Your search term is sent to the public authority named on this page so the answer reflects current data.

Data source: endoflife.date

Products and versions, one per line "product version", "product@version" or a Package URL. Only product names are sent to the server; your versions are matched in this page.

Or drop an SBOM

CycloneDX or SPDX. Components whose package is a tracked product are checked; the SBOM itself stays in your browser.

End of life is a vulnerability you already have

When a runtime or framework reaches end of life, security fixes stop. The next vulnerability found in it will not be patched, however serious it is, and your scanner may not even report it, because no fixed version exists to recommend. Knowing which of your dependencies are on an unsupported release cycle, or about to be, is one of the cheapest risk reductions available.

How a version is matched

Lifecycle data comes from endoflife.date, a community-maintained, openly licensed record of release cycles for more than 400 products. Your version is matched to the release cycle it belongs to: 18.19.0 belongs to Node.js 18, and 22.04.3 to Ubuntu 22.04. The page then reports that cycle's dates: when active support ends, when security support ends, and the latest release in the cycle, so you can see whether you are merely behind on patches or on a cycle that is finished.

Unknown is never "supported"

Four situations produce Unknown rather than a comforting answer:

the product is not tracked by the source;
the version matches none of its published cycles;
no version was given;
the source could not be reached and no recent copy exists.

Only a matched cycle with a future end-of-life date is reported as supported. Lifecycle data is cached for 12 hours and shown with its fetch time. An outage serves the last good copy, clearly marked stale.

What is sent

Only product names, such as nodejs or django, go to this site's server, which fetches the public release cycles for those products. The versions you run, the rest of your list and any SBOM you drop never leave the browser. From an SBOM, only packages that are themselves a tracked product (Django, React, Spring Framework, Log4j and so on) are checked. The mapping is shown, never guessed.

Frequently asked questions

Why is "java 17" not tracked?

"Java" is several products with different lifecycles: Oracle, Eclipse Temurin, Amazon Corretto and others. Name the distribution, for example eclipse-temurin 17.0.10.

My vendor supports this version longer than the date shown.

Extended or commercial support is not the same as the upstream lifecycle. Where the source publishes extended support it is noted; your contract may go further.

Why are most packages in my SBOM skipped?

endoflife.date tracks runtimes, frameworks, databases and operating systems, not every library. A skipped package is listed with the reason. It is not reported as supported.

Source and licence

endoflife.date API. Data by endoflife.date contributors, MIT licence.

Related tools

What this tool can and cannot tell you. It reports what the named source held when it was queried. Where that source has no record, the answer is unknown rather than safe - an absent entry is not evidence of absence.

Security guidance here follows current published sources - OWASP, MDN, the relevant RFCs, NIST, CISA, FIRST and MITRE - which are linked beside the specific claims they support.