artifact-keeper

What Artifact Keeper replaces and why it exists

Artifact Keeper is described in its README as an enterprise grade, open source artifact registry built with the Rust language. The project positions itself as a drop in alternative to commercial registries such as Artifactory and Nexus, which means a team can run one service instead of paying for or maintaining those proprietary tools. The README states the registry supports 45 or more package formats, which covers most of the ecosystems a software team is likely to use in daily work. The stated goal is to give organizations a single place to store build artifacts, containers, and language specific packages while keeping the deployment fully self hosted. Because the code is open source under the MIT license, companies can read it, modify it, and run it on their own infrastructure without per seat fees. The README also links to a documentation site, a live demo, and the project website, which suggests the maintainers ship real deployment documentation rather than a bare prototype. For teams already operating Artifactory or Nexus, the drop in framing means a migration can target a compatible workflow. The badge row in the README shows continuous integration, a SonarCloud quality gate, a security rating, a vulnerability count, and a lines of code metric, all of which indicate the maintainers track code quality and known vulnerabilities as part of normal development.

Package formats and protocol support

The README lists native protocol support for more than 45 package formats and names several directly. Maven, PyPI, NPM, Docker and OCI images, Cargo, Go modules, and Helm charts are called out in the highlights, with the README noting that 38 additional formats are also covered. This breadth matters because most engineering organizations publish across several ecosystems at once, and a single registry that speaks each protocol natively avoids running a separate server per language. The Docker and OCI support means container images can live next to traditional packages, which simplifies a supply chain that would otherwise span a container registry and several language registries. Cargo and Go support let Rust and Go teams use the same backend their Java and Python colleagues use. The Helm support is relevant to teams that deploy on Kubernetes and want charts stored alongside the images they pull. By handling these protocols natively rather than by wrapping external tools, the registry can present a consistent API surface and a single set of access controls. The README presents these formats as the first highlight of the project, which signals that format coverage is the primary reason a team would choose Artifact Keeper over a narrower or commercial option.

The WebAssembly plugin system

Artifact Keeper includes a plugin system based on WebAssembly, which the README describes as a way to extend the registry with custom format handlers. The design uses the WebAssembly Interface Type (WIT) standard and runs plugins on the Wasmtime runtime. WIT is the interface definition system from the component model effort, and Wasmtime is a standalone WebAssembly runtime, so plugins are compiled to WebAssembly and executed in a sandboxed environment rather than as native code inside the main process. That approach lets third parties add support for a package format the core project does not ship, or change how an existing format is handled, without forking the registry. Because the plugins are WebAssembly, they are portable across the operating systems the registry supports and are isolated from the host process for a degree of safety. A team that needs to store a niche or internal package type can write a small WIT described module and load it, rather than waiting for upstream support. The README lists this plugin system as a headline feature alongside format coverage and security scanning, which shows the maintainers expect extension to be a common need rather than an edge case. The combination of a standard interface and a mature runtime keeps the extension path documented and reproducible.

Security scanning and edge replication

Two further features appear in the README highlights: automated security scanning and edge replication. The security scanning is described as automated vulnerability detection, which implies the registry checks stored artifacts for known problems as they are added or on a schedule, instead of relying on developers to scan locally. For a registry that acts as a single source of truth for many teams, built in scanning reduces the chance that a vulnerable dependency spreads silently through the organization. The edge replication feature lets the registry spread artifacts across locations, which the README frames as edge replication. A team with developers in several regions can keep copies close to where builds run, reducing pull latency and providing resilience if one site goes offline. Together these features move the registry from a passive storage bucket toward an active supply chain control point. The README groups them with format support and the plugin system as the four headline capabilities, which tells a reader that operations and security teams are a primary audience, not only build engineers. The presence of a security rating and vulnerability badge in the README header reinforces that scanning is treated as a first class concern rather than an optional add on.

Editorial conclusion

Artifact Keeper is written in Rust and published under the MIT license. Its README documents 45 or more package formats, a WebAssembly plugin system, and built in security scanning as core features.