@pc10201 感谢补充，你说的这个项目，我们在遇到 Nexus 限制的时候，调研过，为什么没直接用，而是开发了一个新的，有以下原因：1 、artifact-keeper 不是纯开源的（生称代码开源），他也有商业计划，类似 Nexus 一样 。2 、他依赖了 OpenSearch 做做全文索引，相当于又需要多维护一个组件 3 、最重要一点，他支持 Nexus 支持的仓库类型，在权限、Path 上不兼容，意味着从 Nexus 迁移到 artifact-keeper ，不仅需要解决私有包的迁移，大量的客户端、CI 都需要一起跟着调整。 这个是不可接收的。 而 kkRepo 的定位，很明确，简单已部署、多副本高可用。一键迁移 Nexus ，而客户端 、CI 都不需要改了。连 Nexus 的用户+权限都可以整套搬迁到 kkRepo ，这个就是 kkRepo 区别与其他制品仓库的意义。

@moyuge 非常赞，纯代理路线和 kkRepo 稍微有点不一样

@mMartin conda 在实施的路线图了，现在已经有 pypi 了 。现在底座已经打好了，目标是最终支持所有的仓库类型

@oldManNewThought 多谢，对于真实的一线需求会优先安排，预计下个版本就可以支持了

@xuecan 感谢提醒，制品仓库是动态 API 的资源，不太适合挂 CDN

@oldManNewThought 我理解这个需求，是在配置 kkRepo 的 Docker proxy 仓库的时候，添加几个 proxy 属性，走代理回源上游的 Docker 仓库吧？ 如果方便的话，可以提个 issue 。这个确实也是非常重要的功能点。

@KevinGreen maven 仓库有三种类型，自托管的私有包仓库 ： https://kkrepo.cn/repository/maven-hosted/ ，纯代理中央仓库 ： https://kkrepo.cn/repository/maven-proxy/ ，还有一个聚合私有+代理的聚合仓库： https://kkrepo.cn/repository/maven-group/ 。你说的 fastion 搜索不到，是因为还没有拉过这个依赖，可以用 https://kkrepo.cn/repository/maven-group/ 、或者 https://kkrepo.cn/repository/maven-proxy/ 配置到项目里，构建下项目，如果有依赖 fastion 的话，就会被自动缓存住，首次会回源到中央仓库拉包，下次就会走缓存加速。类似 CDN 加速

@PeiXyJ 感谢支持

项目地址 : https://github.com/klboke/kkRepo

@alleluya 感谢支持

@66z 可以看下 https://github.com/klboke/kkRepo ，可以完全平替 Nexus ，参考案例： https://my.oschina.net/klblog/blog/19717500

@redial39 这种方式用的还好吗？有兴趣迁移到 kkRepo： https://github.com/klboke/kkRepo 吗，几乎没有迁移成本。

发布详情： https://www.oschina.net/news/470744/kkrepo-0-2-0-released

@yijiangchengming Rust 的 Cargo 已经支持了

@yijiangchengming 在开发计划中了

@han1988 懂了，这个需求先收了，我先了解了解

@han1988 kkRepo 已经支持 Docker/OCI 仓库了，已经包含了 docker login 、docker pull 、docker push 、manifest 、blob 、tag 、OCI referrers 、hosted/proxy/group 这些能力

kkRepo 是为了解决 sonatype nexus3 痛点问题而开发开源的，解决的问题包括但不限于：
1 、nexus 内嵌 OrientDB 、ElasticSearch ，进程很重，容易崩溃
2 、nexus 不支持多副本高可用部署
3 、nexus 最新的免费版本限制了维护的包个数，也限制每天的请求量，几乎没法用 。
另外，Nexus 源代码是不开放的，PRO 版本也非常贵。

@sprinng 纯好奇，你的项目是需要商业授权的，会有人找你要商业授权吗