前言

kkRepo （ https://github.com/klboke/kkRepo ）一个对标 Nexus ，解决 Nexus 社区版本限制痛点的开源制品仓库项目，目前已经支持了 Maven, npm, PyPI, Go, Helm, Cargo/Rust, Docker/OCI, NuGet, RubyGems, Yum, and Raw 这些仓库，下一步打算支持华为的鸿蒙 ohpm 仓库。

主动出击，寻找痛点用户

项目发布后，我就在 Google 搜索 “nexus 社区版限制” 这个关键词。找到了

• https://wiki.eryajf.net/pages/b6b711/#%E5%89%8D%E8%A8%80

这个博文，因为我发现类似的内容，这个博文在 Google 的 SEO 排名第一。然后在博文下跟帖回复了。

你好，我们开发了一个可以平替 Nexus 的软件，代码完全开源，也支持一键从 Nexus 迁移到 nexus-plus ，且我们已经在生产环境运行很久了。想调研下，因为 Nexus 的开源免费功能部分限制的越来越多的情况下，是否有兴趣切到 nexus-plus 来。附项目地址： https://github.com/klboke/nexus-plus

7 天之后，就有用户看到了我的评论，然后成功互加到微信。在微信上全力协助他，解答各种疑问。从加微信到他们生产落地不到一周时间。从 Nexus 开始迁移到 kkRepo 只用了 1 天时间。

以下来自对方的真实切换背景

我们是一家光伏制造企业，研发团队超过 500 人，覆盖 50 多个项目，内部多条产品线共用统一的 CI/CD 流水线。制品仓库作为构建基础设施的核心组件，承担着 Maven 、npm 、pypi 等多种制品的托管与分发职责，是整个研发体系的关键基础设施。

过去几年，我们一直使用 Sonatype Nexus Repository 3.78.2-04 （ Community Edition ），通过 Docker Compose 部署，底层数据库使用 PostgreSQL ，制品 blob 存储使用 OSS 。随着业务规模扩大，Nexus Community Edition 的一些限制逐渐暴露出来，最终促使我们启动了制品仓库的平替与迁移工作。

迁移到 kkRepo 后，实际效果：

不再有组件数量和请求量上限，不用担心触发硬性封顶 支持多副本部署和滚动升级，升级不再需要停服 可以按需扩容，支持弹性伸缩 元数据在 MySQL 中，blob 在 OSS 中，数据备份和恢复更方便 CI 配置和客户端全部无需修改，切换后业务侧没有收到任何失败反馈

后记

kkRepo 从开源到现在，不到一个月的时间，中间还经历了改项目名称这么狗血的事情,然后能在这么短时间内在 500 人研发团队规模的企业落地，安全平稳的从 Nexus 迁移到了 kkRepo ，完全超出了我的预期。这证明了 kkRepo 这个项目有真实的项目价值，以及落地场景。希望 kkRepo 这个项目能帮助到更多的企业，发挥更大的价值。