2026.10.24
Artifact Keeper: A Self-Hosted Registry for Multiple Artifact Ecosystems
Artifact Keeper combines many package protocols, scanning, search, and replication in one open-source registry, while deployment still requires careful dependency planning.
Project scope
Artifact Keeper is an MIT-licensed, open-source universal artifact registry for teams that need to host packages, container images, infrastructure modules, and other build outputs in one place. The repository is not archived. Its README describes a Rust-based registry with native protocol support for Maven, PyPI, NPM, Docker/OCI, Cargo, Go, Helm, and other ecosystems.
This model may suit organizations that maintain several language stacks and want a common repository, authentication model, and publishing workflow. It can also be relevant to teams building an internal mirror or considering migration from Artifactory. The project page lists built-in migration tooling for repositories, artifacts, and permissions from JFrog Artifactory, although migration scope should be validated against the source installation before committing to a cutover.
Documented capabilities
The README claims support for more than 45 package formats, spanning language runtimes, containers, infrastructure, system packages, configuration-management ecosystems, machine-learning artifacts, editor extensions, schemas, and generic files. A WebAssembly plugin system based on WIT and Wasmtime is described for adding custom format handlers. The format count should not be treated as proof that every handler has identical maturity or behavior; teams should test the protocols they actually use.
Security-related features include Trivy and Grype scanning, a policy engine, and quarantine workflows. GPG or RSA signing is integrated into the Debian, RPM, Alpine, Pacman, and Conda handlers according to the README. A significant deployment caveat concerns container images: first-class Trivy image reports require TRIVY_ADAPTER_URL. Without that adapter, the README says images remain covered by Grype in registry mode, but no Trivy image report is produced.
The documented architecture includes PostgreSQL, filesystem or S3 storage, and OpenSearch for full-text search. It also describes Borg-based peer replication, peer-to-peer distribution, multiple authentication methods, and migration support. These features make the project more relevant to platform teams than to users seeking a minimal, single-service package cache.
Limits and deployment considerations
A complete installation is not just one executable. Database, artifact storage, search, scanners, and the optional image-scanning adapter affect topology, backups, network access, and operational work. The supplied sources do not confirm minimum hardware, capacity guidance, or performance results, so those figures should not be assumed. Operators should size and test the deployment using their artifact volume, upload concurrency, retention policy, and scan frequency.
The scanning path deserves specific validation. The README notes that the adapter must reach the backend from its own container network and should use its own Trivy cache volume; incorrect addressing or reused volume permissions can cause failures. Operators should also define how policies handle quarantine, false positives, signing-key custody, and rollback. Although several authentication methods are listed, the sources do not establish that any configuration is inherently secure or provide a complete security assessment.
The supplied release record identifies 1.11.6, published on October 24, 2026, as a maintenance release. Its notes state that it introduces no schema migrations or new settings; the main functional change improves PyPI age-gate matching for PEP 440-equivalent version spellings, alongside a ctutils dependency update. Production operators should still review the release notes, back up data, and retain a rollback plan before upgrading.
Sources
Sources checked: 2026-10-24