Artifact Keeper: A Rust Registry That Trades Simplicity for Breadth

What Problem It Solves and Who It Is For

Artifact Keeper is aimed at teams that manage artifacts across many ecosystems and want to replace a commercial registry like JFrog Artifactory or Sonatype Nexus with an open-source, self-hosted option. The core pitch is breadth: 45+ package formats, from Maven and NPM to Docker/OCI, Helm, Terraform, and even HuggingFace models. If your organization builds with Java, Python, and Rust, and also ships containers and Helm charts, you might otherwise need several registries or a costly commercial product. Artifact Keeper consolidates those into one backend with a unified API and a single storage layer. The README emphasizes native protocol support, meaning each format handler speaks the package manager's own wire protocol, so clients like pip or cargo should work without special configuration. This is for engineers who already operate infrastructure and are willing to run a Rust service plus PostgreSQL, OpenSearch, and optional scanners, not for small teams looking for a quick local cache.

Architecture: A Middleware Pipeline and a Mesh of Peers

The system architecture diagram shows a clear separation of concerns. Clients (CLI tools, package managers, or a frontend) hit a backend written in Rust using the Axum web framework. That backend routes to format-specific handlers, one per package ecosystem. The backend stores metadata in PostgreSQL 16 and artifacts on the filesystem or S3. OpenSearch provides full-text search across repositories and artifacts. For security, the backend calls Trivy, Grype, and OpenSCAP. The request flow goes through a middleware pipeline: CORS, authentication (JWT, OIDC, LDAP, SAML, API keys), rate limiting, tracing and metrics, and a demo mode guard. After that, a router with over 50 route groups dispatches to format handlers or core handlers for repos, artifacts, users, and auth. The README also describes Borg Replication, a recursive peer mesh with swarm-based artifact distribution and P2P transfers. That suggests a design where multiple Artifact Keeper instances can form a network and share artifacts directly, rather than a simple master-slave replication. The exact replication protocol is not detailed in the README, so you would need to read the docs or source to understand consistency guarantees.

Security Scanning: Dual Scanners and a Policy Engine

Every artifact upload goes through a security pipeline, according to the README. The flow starts with SHA-256 deduplication. If the artifact is new, both Trivy (filesystem scanner) and Grype (dependency scanner) analyze it. If it was already scanned, results are cached. The findings are combined into a vulnerability score from A to F, based on severity and count. That score feeds a policy engine, which either allows the artifact to be stored or quarantines it. Policies are configurable, so you can block or quarantine based on your own rules. The dual-scanner approach is a real strength: Trivy covers filesystem and container analysis, while Grype handles dependency trees. The README also mentions OpenSCAP for compliance scanning, though it is not described in detail. One important caveat is around container images. The base docker-compose.yml wires TRIVY_URL for legacy Trivy server filesystem scanning only. To get proper Trivy container-image reports, you must set TRIVY_ADAPTER_URL and enable the scanner-adapter service. Without that, images are still covered by Grype in registry mode, but you lose the dedicated Trivy image report. This is a concrete configuration trap that you must handle during setup.

WASM Plugins: Extending Formats Beyond the Built-In 45

The WASM plugin system is one of the most distinctive features. It uses WebAssembly with a WIT-based interface and the Wasmtime runtime. This means you can write custom format handlers in any language that compiles to WASM, without rebuilding the core Rust backend. The README explicitly says custom formats can be added via this plugin system. For teams with internal or niche package formats, this is a genuine differentiator compared to Artifactory or Nexus, where extending formats often requires writing Java plugins or using generic repository types. However, the README does not provide examples of how to write a WIT interface or how to package and deploy a plugin. You would need to consult the documentation or source code. The plugin system also introduces a security boundary: WASM runs in a sandbox, but you still need to trust the plugin author. The trade-off is clear: flexibility comes at the cost of learning a new plugin API and managing a separate build and deployment process for plugins.

Getting It Running: Docker Compose and Environment Variables

The README references a docker-compose.yml as the primary way to get started. It wires together the backend, PostgreSQL, OpenSearch, and the scanners. The key environment variable mentioned is TRIVY_URL for the legacy Trivy server, and TRIVY_ADAPTER_URL for the dedicated container image scanner. To enable container image scanning, you uncomment the TRIVY_ADAPTER_URL line and the scanner-adapter service in docker-compose.yml. The scanner-adapter implements the Harbor Pluggable Scanner API and pulls images back from the registry, so it must be given an address of the backend that is reachable from the adapter. That sentence is truncated in the README, but the implication is clear: you need to configure the backend URL that the adapter can use to reach the registry. The README also mentions a demo instance at demo.artifactkeeper.com and documentation at artifactkeeper.com/docs. For a production deployment, you would likely need to set up PostgreSQL 16 and OpenSearch separately or use the compose file as a base. The README does not list all configuration keys, so you must rely on the docs for details like storage backend selection, authentication providers, and policy rules.

Limitations and Failure Modes

The most obvious limitation is operational complexity. Running Artifact Keeper means managing PostgreSQL, OpenSearch, Trivy, Grype, and optional OpenSCAP, plus the backend itself. That is a significant infrastructure footprint compared to a single-binary registry like Gitea or a simple S3-backed proxy. The README does not mention a lightweight mode or a SQLite option, so every deployment requires a full database and search engine. Another failure mode is the container scanning configuration trap. If you forget to set TRIVY_ADAPTER_URL, you get a false sense of security because images are still scanned by Grype, but the README says no Trivy image report is produced. That could lead to gaps in vulnerability coverage. The README also does not specify how the policy engine behaves when scanners fail or time out. If Trivy or Grype goes down, does the upload fail, get quarantined, or proceed without a score? The documentation would need to clarify that. Finally, the 45+ formats claim is broad, but the README lists aliases like Yarn and Bower under NPM, which may mean those clients are supported through the NPM protocol, not as separate native handlers. That is fine, but you should verify that your exact client version works with the current release.

Alternatives: Artifactory, Nexus, and the Open-Source Middle Ground

The obvious commercial alternatives are JFrog Artifactory and Sonatype Nexus Repository Pro. Both support a wide range of formats, but they are proprietary and require licensing fees. Artifactory has a strong migration story, and the README even includes built-in tooling to migrate from Artifactory, which is a direct acknowledgment of that competitor. Nexus has a smaller format list but is also widely used. On the open-source side, you could use a combination of format-specific registries: Harbor for containers, PyPI server for Python, and a simple static file server for Maven. That approach avoids the operational weight of Artifact Keeper but requires multiple services and no unified search or policy engine. Another open-source option is Gitea with its built-in package registry, which supports a handful of formats (npm, PyPI, Maven, etc.) but far fewer than 45+. The key difference is scope: Gitea is a lightweight forge with a package registry as a side feature, while Artifact Keeper is a dedicated registry with a plugin system and scanning pipeline. If you only need a few formats, the simpler tools may be easier to maintain. If you need broad coverage and a single control plane, Artifact Keeper's approach is different from assembling multiple tools.

Maintenance and Upgrade Cost, and License Implications

The project is licensed under MIT, which is permissive and allows commercial use, modification, and redistribution with attribution. That is a low-license-friction choice. The repository is actively maintained, with recent releases v1.8.1 and v1.7.8 in August 2026, and the default branch is main. The release cadence suggests regular updates. However, the README does not provide a migration guide for upgrades between versions, nor does it mention a database migration tool. Given the complexity of the schema (PostgreSQL with OpenSearch indexes), upgrading could involve careful coordination of backend, database, and search index versions. The WASM plugin system also means that plugin compatibility with the host runtime must be maintained across releases. The README mentions hardened containers based on Red Hat UBI 9, non-root execution, and no shell or package manager in the runtime image, which is good for security but also means you cannot exec into the container to debug easily. You would rely on logs and metrics. The documentation and demo are available, but the README is the primary source here, and it is sparse on operational details like backup and restore procedures. You should verify those before relying on Artifact Keeper in production.

Editorial conclusion

Adopt Artifact Keeper if you need a single registry for many package formats, especially if you already run PostgreSQL and OpenSearch and want built-in Trivy and Grype scanning without stitching separate services. Skip it if you need only one or two formats and prefer a smaller operational footprint, or if you require a stable, long-term commercial support contract. Before adopting, verify that your specific package managers' wire protocols work against the current version, that your storage backend (filesystem or S3) meets your scale needs, and that the WASM plugin system supports the custom formats you need. Also confirm the TRIVY_ADAPTER_URL setup for container image scanning, because without it you get only Grype registry-mode coverage for images.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes