Every client repo, one screen.
How many years behind each project has drifted, what is already end-of-life, and what is genuinely dangerous right now. Across every client organisation you work in, without adding a single pull request to anyone’s queue.
Why this keeps happening
of application dependencies stay un-upgraded for more than a year, even though a newer version exists.
Sonatype, State of the Software Supply Chain
of commercial codebases audited contained components more than four years out of date.
Black Duck OSSRA 2025
of the time a vulnerable component is installed, a fixed version was already published.
Sonatype, State of the Software Supply Chain
The tools already tell you a package is outdated. They tell you one repository at a time, and they tell you by opening pull requests nobody has time to read. The problem was never detection.
What Libyears does
One number per project, and a trend
Libyears behind, major versions behind, and whether the gap is opening or closing. The number a delivery lead can put in front of a client, not another alert feed.
What is dangerous today
Critical vulnerabilities that already have a fix, packages being actively exploited, end-of-life runtimes and frameworks, and dependencies whose maintainers walked away.
Plan the upgrade before it becomes a project
What breaks, in what order, and roughly how long it takes. Export the brief to whichever coding agent you already use, or hand it to a developer.
What it deliberately does not do
- It never opens a pull request or changes a line of your code.
- It reads your manifests and lockfiles. Not your source, and it never clones a repository.
- Private package names never leave the system, so nothing of yours reaches a third-party API.