一个人维护十几项目，他想一次看清所有过期依赖

开发者社区最近一周出现了一个叫 Spryly 的项目，作者同时维护着很多项目，同时维护着很多项目跨越不同技术栈。他吐槽维护多个项目时最烦的事情之一就是「哪些包的依赖过期了」——必须一个仓库一个仓库地检查，加上 CMS 安装和插件也要单独跟，老项目就容易悄悄跑偏。

Spryly 最开始是他自己的工具，用着用着觉得很好用就放出来了。使用流程是：连接 GitHub 或 GitLab 账号，选要追踪的仓库，Spryly 自动扫描依赖清单，跟对应 registry 比对，告诉你哪些过期。所有项目和包在一个面板里一目了然。

作者特别强调一件事——Spryly 只读清单文件，不会主动开 PR 或修改仓库。他判断 Dependabot 和 Renovate 已经在「自动版本升级」这件事上做得很好了，Spryly 解决的是不同问题：跨所有项目一次性看清过期状态，包括那些你没在主动维护的。

Spryly 还做了一个「Services」面板，可以追踪项目依赖的服务（比如 Cloudflare、AWS 等），在某个服务出故障时发提醒。这是把「依赖」从代码库扩展到运行时基础设施的一个小动作。

收费方面，免费版可以连接一个 GitHub 或 GitLab 账号，追踪最多 5 个仓库。Pro 版包含无限账号、无限仓库、加上预发布版本追踪。

技术栈层面，作者说他用 Next.js + Supabase 搭起来的。

这个项目有意思的地方在于作者明确画了一条边界——「我不做自动修复，只做可视化」。这句话背后的判断是：自动化修复的市场已经被 Dependabot、Renovate 占领，新玩家再做没意义。但「跨项目跨服务一次性看清」这件事还缺一个干净的工具，作者填的就是这个空。

另外作者对「个人工具→公开产品」这件事的态度也值得参考。他不是一开始就规划要做什么 SaaS，是先解决自己手头的痛点，用着觉得好再决定放出来。这种「内部工具外溢」的路子比「先做商业计划再写代码」更接近真实需求。

创业找资源，上乌鸦部落。