Artifact Keeper：面向多生态制品管理的自托管仓库

项目定位

Artifact Keeper 是一个采用 MIT 许可证的开源通用制品仓库，目标是为团队集中托管软件包、容器镜像、基础设施模块和其他构建产物。项目仓库未被归档，README 将其定位为基于 Rust 构建的多格式 registry，并列出 Maven、PyPI、NPM、Docker/OCI、Cargo、Go、Helm 等协议。对于同时维护 Java、Python、JavaScript、容器和系统包的组织，这种统一入口比为每个生态分别维护服务更容易形成一致的权限、审计和发布流程。

已知功能

README 声称支持 45 种以上包格式，覆盖语言运行时、容器与基础设施、系统包、配置管理、机器学习模型、编辑器扩展和通用文件。项目还提供基于 WebAssembly、WIT 和 Wasmtime 的插件系统，用于扩展自定义格式处理器。不过，实际采用时应逐一核对目标格式的协议覆盖范围、边界行为和版本支持，不能仅根据总数推断所有格式具有相同成熟度。

安全相关功能包括 Trivy 和 Grype 扫描、策略引擎与隔离流程，部分 Debian、RPM、Alpine、Pacman 和 Conda 处理器还集成了 GPG 或 RSA 签名。README 特别说明：要获得一等的 Trivy 容器镜像报告，需要额外配置 TRIVY_ADAPTER_URL；未配置时，镜像仍可由 Grype 以 registry 模式覆盖，但不会产生 Trivy 镜像报告。这是部署设计中的实际限制，而不是可以忽略的可选细节。

项目架构还列出 PostgreSQL、文件系统或 S3 存储，以及 OpenSearch 全文搜索。README 同时描述了 Borg 复制、对等网状分发、多种认证方式和 Artifactory 迁移工具。上述能力适合需要跨团队复用依赖、建立内部镜像、管理多类构建产物，或计划从既有 Artifactory 环境迁移的团队。

采用前的限制与部署考虑

Artifact Keeper 并不是单一进程即可完整体现全部能力的轻量工具。数据库、对象或文件存储、搜索服务，以及扫描器和可选的镜像扫描适配器，都会影响部署拓扑、备份策略、网络连通性和运维成本。来源没有提供最低硬件配置、容量建议或性能数据，因此不能据此规划规模；部署者需要根据制品数量、并发上传、保留策略和扫描频率自行压测与设计。

扫描链路尤其需要验证。README 提到适配器必须能从自身容器网络访问后端，且应使用独立的 Trivy 缓存卷；错误的地址或卷权限可能导致扫描失败。还应明确哪些扫描器适用于哪些格式，并把隔离策略、误报处理、签名密钥保管和升级回滚纳入流程。项目页面列出多种认证方式，但来源没有证明某一配置天然安全，也没有提供完整的安全评估结论。

截至来源所示，1.11.6 是一个维护版本，发布说明称没有数据库迁移和新的设置，升级属于常规镜像更新；主要变化集中在 PyPI 年龄门控的 PEP 440 等价版本匹配，并更新了 ctutils 依赖。生产环境仍应阅读对应变更记录，在备份和回滚方案具备后再升级。

资料来源

• GitHub repository metadata
• Project README
• Official release
• Official project page

资料核对日期：2026-10-24