Nexus 平替项目 kkRepo 开源风波

我们把 kkRepo 开源了。

• https://github.com/klboke/kkrepo
• https://gitee.com/kailing/kkrepo

kkRepo 是 Nexus 的开源平替项目，完全兼容 Nexus 的客户端使用方式，并支持从现有 Nexus Repository 实例一键平迁到 kkRepo。迁移后，原有仓库地址、客户端配置和权限模型保持不变，让业务侧无感切换。

这次开源并不是一个单纯的技术发布。它还伴随着一次命名风波：kkRepo 最早并不叫 kkRepo，而叫 nexus-plus。

nexus-plus 商标侵权，改成 kkRepo

最初取名 nexus-plus，是因为我们的目标很直接：做一个 Nexus 的开源平替，让已经在使用 Nexus 的团队可以用最小成本迁移过来。

后来，我们收到了来自 Nexus 相关商标权益方的商标侵权提醒邮件。这封邮件促使我们重新审视项目命名：作为一个独立开源项目，我们可以兼容 Nexus，可以帮助用户从 Nexus 迁移，但不应该把 Nexus 当成自己的项目品牌。

所以，我们决定把 nexus-plus 改名为 kkRepo。

这次改名不是只改一个 README。我们同步调整了项目名称、代码包名、配置前缀、环境变量、Docker 镜像名、脚本文案和公开文档，让项目从品牌到工程表面都统一到 kkRepo。

我们也在公开文档中补充了商标声明：Sonatype、Nexus 和 Nexus Repository 是 Sonatype, Inc. 的商标；kkRepo 是独立开源项目，不隶属于 Sonatype, Inc.，也未获得其认可、赞助或背书。后续文档里继续出现 Nexus 相关表述时，只用于说明兼容性、迁移和互操作场景。

为什么要做 Nexus 平替

制品仓库平时不显眼，但它是研发链路里非常关键的一环。Maven、npm、PyPI、Go、Helm、Docker、NuGet、RubyGems、Yum 等依赖和制品，每天都会被 CI/CD、开发环境和发布流程反复读取。

我们长期使用 Nexus。随着业务规模增长，制品仓库逐渐从“能用就行”的工具，变成了影响构建、发布和上线稳定性的核心基础设施。

在这个过程中，我们遇到过老版本稳定性、升级、恢复、容量、迁移成本等问题。尤其是当一个制品仓库承载大量业务构建之后，任何一次异常都会放大成研发链路问题。

我们需要一个更符合当下使用场景的选择：

• 能完整承接现有 Nexus 的客户端使用方式。
• 能一键平迁现有 Nexus 数据和配置。
• 能让业务侧不用逐个修改构建脚本和客户端配置。
• 能降低后续运维、升级和恢复成本。
• 能作为开源项目被更多团队验证和参与。

这就是 kkRepo 的起点。

kkRepo 能做什么

kkRepo 面向常见制品仓库场景，当前支持 Maven、npm、PyPI、Go、Helm、Docker/OCI、NuGet、RubyGems、Yum 和 Raw 等制品类型。

对使用方来说，最重要的不是底层实现细节，而是迁移后怎么用：

• Maven settings 可以继续指向原来的仓库地址。
• npm registry 可以继续使用原来的配置。
• PyPI index-url 可以继续沿用。
• Go proxy、Helm repo 等客户端配置可以保持原有形态。
• 权限模型和仓库路径保持兼容。
• 原来的 /repository/<repo>/... 使用方式保持兼容。

也就是说，kkRepo 的目标不是让业务重新适配一个新系统，而是让原来使用 Nexus 的团队可以平滑迁移到 kkRepo。

一键平迁是核心能力

kkRepo 把迁移做成了产品能力，而不是一次性脚本。

管理员可以在 kkRepo 后台配置源 Nexus 信息，先做迁移检查，再迁移用户、角色、权限、仓库配置和制品数据。迁移过程支持续跑、重试和校验，适合在正式切换前多轮同步。

最终切换时，只需要把原制品仓库域名指向 kkRepo。对大多数业务来说，构建配置不需要修改，使用方式不需要变化。

我们内部已经完成过 0 停机迁移。迁移完成后，CI 继续使用原来的 Maven settings、npm registry、PyPI index-url、Go proxy、Helm repo 等配置，业务侧没有明显感知。

这也是我们认为 kkRepo 有开源价值的原因：很多团队不是不想换，而是换不起。真正困难的不是部署一个新服务，而是让成百上千个构建任务和业务项目不受影响地完成迁移。

AI 参与开发，但上线靠验证

kkRepo 也是一个 AI 参与开发的项目。

主体代码是在 AI 编程助手帮助下快速完成的。人主要负责产品目标、兼容性要求、关键决策、问题定位和代码 Review。

但基础设施软件不能靠“看起来实现了”上线。为了保证兼容性，我们专门用真实 Nexus 参考实例做对照测试，持续验证常用客户端、仓库路径、权限、上传下载和迁移结果。

AI 帮我们提高了开发速度，但 kkRepo 能不能被真正使用，最终还是要靠测试、迁移验证和真实场景反馈来证明。

谁适合关注 kkRepo

如果你的团队正在使用 Nexus，并且遇到以下问题，kkRepo 可能值得试一下：

• 现有 Nexus 版本升级困难。
• 制品数量或请求量持续增长。
• 希望降低制品仓库的运维和恢复成本。
• 希望从 Nexus 迁移，但不想大规模改客户端配置。
• 希望迁移过程可以检查、续跑、重试和回滚。
• 希望使用一个开源、可参与、可持续演进的 Nexus 平替项目。

如果你的 Nexus 部署规模很小、运行稳定，也没有迁移和扩容压力，继续使用现有方案当然也没问题。kkRepo 更适合那些已经把制品仓库当作核心基础设施，并且开始认真考虑迁移、稳定性和长期维护成本的团队。

开源之后

kkRepo 使用 Apache License 2.0 开源。

接下来，我们会继续完善更多协议兼容性、一键迁移体验、迁移报告、失败诊断、部署文档和生产使用案例，也会继续扩展更多仓库格式支持。

这场“开源风波”对我们来说也是一次提醒：做开源平替项目，不仅要解决技术问题，也要处理好品牌边界和社区沟通。我们会继续把 Nexus 作为兼容参考，而不是项目品牌；也会继续把 kkRepo 做成一个独立、可迁移、可验证、可持续演进的开源制品仓库项目。

项目地址

• https://github.com/klboke/kkrepo
• https://gitee.com/kailing/kkrepo