DEV Community

endoflife-ai
endoflife-ai

Posted on • Originally published at endoflife.ai

One badge that tells your users when your dependencies die

Every README makes claims about support. Almost none of them stay true.

"Requires Node 18+" — written in 2023, when Node 18 was the fresh LTS. Node 18 died in April 2025. The README didn't notice. Neither did most of the people reading it.

I run endoflife.ai, a site that tracks end-of-life dates for 488 products, and the most requested thing after the data itself has been: can my README just show this automatically? So we built badge endpoints for everything we track — here's what they look like and how to use them.

The badge

[![Node.js end of life](https://img.shields.io/endpoint?url=https%3A%2F%2Fendoflife.ai%2Fbadge%2Fnodejs.json)](https://endoflife.ai/nodejs)
Enter fullscreen mode Exit fullscreen mode

That renders a standard Shields.io badge showing the current support status of the newest Node.js release line — and it updates itself. When the status changes, the badge changes. Nobody edits the README.

Here's the live one:

Node.js end of life

Swap nodejs for whatever your project depends on: python, postgresql, django, spring-boot, php, kubernetes488 products have endpoints.

Pin it to the version you actually support

The more useful variant for most projects — badge your minimum supported version, so users can see when your floor goes EOL:

[![Python 3.10 EOL](https://img.shields.io/endpoint?url=https%3A%2F%2Fendoflife.ai%2Fbadge%2Fpython%2F3.10.json)](https://endoflife.ai/python/3.10)
Enter fullscreen mode Exit fullscreen mode

Python 3.10 EOL

Python 3.10 dies October 31, 2026. The day it does, that badge flips — and your issue tracker finds out why you should bump the floor before your users do.

There's also a risk-score version

[![EOL risk](https://img.shields.io/endpoint?url=https%3A%2F%2Fendoflife.ai%2Fbadge%2Fscore%2Fnodejs.json)](https://endoflife.ai/score/nodejs)
Enter fullscreen mode Exit fullscreen mode

This one renders a 0–100 EOL risk score (factors: days to EOL, CVE exposure, whether the version appears in CISA's exploited-vulnerabilities catalog). Useful for internal dashboards and platform-team wikis more than public READMEs.

How it works (nothing clever)

Each badge is a static JSON file in the Shields endpoint format, regenerated nightly from vendor lifecycle policies — the same dataset behind the site. No tracking, no API key, no rate limits beyond Shields' own caching. If you'd rather consume the raw data, every endpoint has a JSON API equivalent documented here.

The dates come from vendor policy pages and the endoflife.date community dataset (we're contributors), cross-checked nightly. When vendors change dates quietly — Microsoft moved a Windows 10 ESU date a full year with zero announcement in June — we correct loudly.

Why I think this matters

An EOL date in a README is a promise that decays. A badge is a promise that keeps itself. If your project pins a runtime, a framework, or a database version, your users deserve to know when that floor rots out from under them — preferably before the CVEs arrive with no patches behind them.

If a product you depend on is missing from the list, tell me and we'll add it.

Top comments (0)