cloudparts

Artifact Keeper

A self-hosted artifact registry written in Rust that speaks the protocols of more than 45 package formats, with proxying, promotion, retention rules and vulnerability scanning all in one MIT-licensed release.

Type
Open source
Made by
Brandon Geraci and contributors
License
MIT
Facts checked
24 October 2026

What it is

Artifact Keeper is a server that package managers and container tools talk to directly: pip, npm, cargo, go, helm and docker connect to it with their own wire protocols. It has handlers for more than 45 formats, from Maven, npm, PyPI, Cargo and Go modules to Docker/OCI images, Helm charts, Debian, RPM and Alpine packages, Terraform modules, Hugging Face models and VS Code extensions, and a WebAssembly plugin system for formats it doesn’t know. The backend is Rust (Axum, SQLx, Tokio) with a React frontend; it keeps metadata in PostgreSQL 16, artifacts on the filesystem or in S3-compatible storage, content-addressed by SHA-256, and a search index in OpenSearch.

It uses the repository model of Artifactory. A local repository holds what you upload; a remote repository is a pull-through cache of an upstream registry that rechecks cached content after a TTL, 24 hours by default; a virtual repository combines local and remote ones behind one URL and checks members by priority, so a package found in the private repository means the public one “is never consulted”. Uploads are staged and promoted to a release repository through an API, with quality gates, CVE policies and licence policies able to block the promotion. Lifecycle policies delete artifacts by age, keep the newest N versions per package, remove ones nobody downloaded in N days, or evict by size quota.

Every upload is scanned with Trivy and Grype, given an A to F score and either stored or quarantined by a policy engine; OpenSCAP checks compliance, and SBOMs go to Dependency-Track. Instances replicate to each other as a peer mesh without a central coordinator. Brandon Geraci, a lead DevOps engineer in Austin, built it in his own time, saying on launch that he wrote it in about three weeks using Claude Code, and the project positions itself as a replacement for Artifactory and Nexus with no paid edition.

Why teams pick it

  • No open-core split: scanning, SSO (OIDC, LDAP, SAML), replication and plugins are in the MIT-licensed release that anyone can run
  • Very wide format coverage, including system packages, Helm, Terraform, Hugging Face and editor extensions, in one server
  • Built-in migration tools for moving repositories, artifacts and permissions from Artifactory or Nexus
  • Promotion gated by scans and licence rules, and retention policies by age, count, downloads or quota, without extra products

Watch out for

  • Very young: first released in February 2026, with frequent releases and little evidence yet of large production deployments
  • Largely one person’s project, written quickly with an AI coding agent; how well 45 protocol handlers match real clients at scale is still being found out
  • Several moving parts to run: PostgreSQL, OpenSearch, scanners and storage, plus an optional scanner adapter for Trivy image reports
  • Lifecycle policies only soft-delete matched artifacts, so storage is reclaimed in a separate step

Alternatives

What all artifact registries have in common →Compare side by side →

How it fits with other technologies

A virtual PyPI repository: internal packages first, the PyPI cache second · bash

curl -X POST "$AK_URL/api/v1/repositories/python/members" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"member_key":"pypi-internal","priority":1}'

curl -X POST "$AK_URL/api/v1/repositories/python/members" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"member_key":"pypi-cache","priority":2}'

# Recheck the PyPI cache every hour instead of every 24 hours
curl -X PUT "$AK_URL/api/v1/repositories/pypi-cache/cache-ttl" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"cache_ttl_seconds": 3600}'

See it in a real stack

No architecture uses Artifact Keeper yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2026

Brandon Geraci, a software engineer who kept being pulled into DevOps work, created the GitHub repository on January 15, 2026 and posted it as a Show HN on February 5. His reason was the open-core pattern of existing registries: “GitLab, JFrog, Harbor, and others ship a limited ‘community’ edition and then hide the features teams actually need behind some paywall.” He wanted to show that a full registry could be open source with “every feature. No exceptions.”

He said the features came from his own pain points: slow search in Artifactory, scanning that needs a separate enterprise licence, and replication that needs a central coordinator. He also said he built it in about three weeks with Claude Code, that the design decisions were his, and that he was running it at home rather than at work. The 1.0.0 release candidates followed within days; search later moved from Meilisearch to OpenSearch in version 1.2.

The project then released at a fast pace, with a minor version every few weeks and 1.11.6 on October 24, 2026. It grew a CLI, a web UI, a macOS app, a Kubernetes Helm chart, migration from Artifactory and Nexus, and hardened container images built on Red Hat UBI 9.

Why it’s built this way

Everything in one MIT release
The author’s complaint about existing registries was paid tiers for scanning, SSO and replication. Putting all features under MIT, with no enterprise edition, was the point of the project.
Artifactory’s repository model and a migration tool
Teams leaving Artifactory or Nexus already think in local, remote and virtual repositories; keeping the same model and importing their repositories and permissions lowers the cost of switching.
A peer mesh for replication
He wanted replication “that didn’t need a central coordinator”, so any node can replicate to any other.
WebAssembly plugins for new formats
With dozens of ecosystems, some will always be missing; a WASM plugin can add a format handler without forking the Rust backend.

Timeline

  1. 2026

    Repository created (January 15); Show HN (February 5); 1.0.0 release candidates (February 9–11)

  2. 2026

    1.1.0 (April 2); 1.2.0 (June 2) moves search to OpenSearch

  3. 2026

    1.11.6 released (October 24)

Sources7 · facts checked 24 October 2026

Improve this page on GitHub