I run a handful of side projects on npm and pnpm and the "run npm outdated, open the changelog in another tab, run the update, something breaks" loop the maker describes is exactly my life. What I liked most in practice: it shows the literal command before running anything, and it refuses to touch a dirty repo instead of quietly stashing or overwriting. The per-project update history with the actual backup files is the part that made me trust it enough to run it on a real project instead of just a throwaway test repo.
Monorepo support is there but I'd like to see per-package granularity in the update history view rather than just workspace root and packages lumped together - useful when only one package in a large monorepo actually changed.
I'd been just eyeballing package.json diffs manually before this and looked briefly at Dependabot/Renovate, but those are CI-side bots for opening PRs, not a local tool for the "I want to bump things on my laptop right now and be able to undo it" case.
I manage several active web projects, and Bumply solved a maintenance problem I had accepted as “just part of the job”: knowing which projects have drifted, which updates are safe, which ones need review, and whether an advisory actually requires action.
What I like most is that it does not treat every update the same. It clearly separates compatible updates, outside-range changes, major releases, and security advisories. That made a real difference for me.
In actual use, I updated Next.js, React, React DOM, Node types and other dependencies safely, while deliberately keeping ESLint 9 and TypeScript 5 after testing showed that ESLint 10 and TypeScript 7 were not yet compatible with the current tooling stack.
Project Checks are also excellent. Bumply automatically found my lint and build scripts and gave me a simple pass/fail validation after dependency changes.
The workflow has become:
Scan → review → update → project checks → security audit → commit
That is much more useful to me than simply showing npm outdated.
The biggest opportunity is helping users remember decisions, not just versions.
For example, I tested ESLint 10 and TypeScript 7 and deliberately rolled them back because of current ecosystem incompatibilities. I would love to mark those major lines as intentionally deferred, with a required reason, so Bumply remembers why I chose not to update and does not keep presenting the same decision as unfinished work.
I would also love a final project-level verdict: something that answers,
“Is there anything here that still requires my attention, or can I stop thinking about dependency maintenance for this project?”
And longer term, a portfolio view showing which projects are healthy, drifting, intentionally deferred, or need attention would be extremely valuable when managing many repos.
One other thing worth mentioning: I reported an issue during real-world testing, and the developer reproduced it immediately and shipped a fix very quickly. That responsiveness gave me a lot of confidence in the product.
Mostly the usual combination of npm outdated, npm audit, GitHub Dependabot, Renovate, and manual package.json review.
Those tools are useful, but they solve slightly different problems.
Dependabot and Renovate are great at creating updates. npm gives me the raw information. What I wanted was a local maintenance cockpit that helps me decide what actually needs attention across multiple projects without turning every package release into another PR or notification.
Bumply fits that workflow much better for me.
Thank you. This is some of the most useful feedback I've had, and most of it is in 1.10, out today.
Deferring is now a first-class decision. You can mark a major line as intentionally deferred with a required reason, and Bumply stops presenting it as unfinished work. Projects holding a decision have their own filter, and one view gathers every decision across every project, so your note about ESLint 10 is still findable in six months.
The portfolio view is there too. The menu bar now shows attention, majors, deferred and up to date across every project, with the full list underneath.
The project-level verdict you describe already exists: the card at the top of each project page answers exactly "is there anything left here for me". If it isn't reading that way for you, say so and I'll fix the wording rather than add another card.
Thanks for the detailed write-up, and for running it on a real repo rather than a throwaway.
Your point about monorepos is fair, and it's in 1.10, out today.
The update history now has a package selector: workspace root, or any single package on its own, so you can read only the one that actually changed. It appears only on projects that really have workspaces, so a single-package repo looks exactly as before.
If it still lumps together something you'd want separated, tell me. You're the reason it exists