Storage & data

FerroRepo

Rust-native universal artifact repository

Single binary, no JVM / DB AWS service it replaces: Sonatype Nexus / JFrog Artifactory

A Rust-native universal artifact repository that runs as a single self-contained binary and speaks the wire protocols of Sonatype Nexus Repository 3 and JFrog Artifactory, so existing Maven, npm, pip, cargo, docker, and helm clients work unchanged. No JVM and no external database to operate (embedded SQLite + local volume or object storage), and it boots in well under a second.

A classic Nexus or Artifactory deployment needs a JVM, gigabytes of heap, and an external database before it serves a single artifact; FerroRepo's single-binary mode replaces that with one hardened binary that ships as a self-contained AMI. v0.1.0 serves 12 of 18 package protocols fully wired with in-tree conformance tests — Maven, npm, OCI / Docker Registry v2, PyPI (PEP 503 family), Cargo (sparse index), Go module proxy, Raw/Generic, NuGet v3, RubyGems, Helm (classic + OCI), APT, and YUM/DNF — plus a Nexus REST v1 and Artifactory-compatible admin surface. Storage is tiered (hot/warm/cold) with content-addressed de-duplication and pluggable S3 / GCS / Azure / MinIO blob backends. Authentication is on by default: anonymous reads are allowed while every write and admin action requires an authenticated principal.

The problem

Classic artifact repositories like Sonatype Nexus Repository 3 and JFrog Artifactory need a JVM, gigabytes of heap, and an external database to operate before they serve a single artifact. They are heavy to boot and carry real operational overhead. Teams want a lighter, easier-to-run repository while keeping their existing Maven, npm, pip, cargo, docker, and helm tooling unchanged.

How it works

1
Boot one self-contained binary

FerroRepo runs as one process with no JVM and no external database, persisting metadata to embedded SQLite and blobs to a local volume or object storage. It boots in well under a second on a small instance and ships as a hardened, self-contained AMI.
2
Point existing clients at it unchanged

FerroRepo speaks the on-the-wire HTTP protocols of Nexus Repository 3 and Artifactory, so Maven, npm, pip, cargo, docker, helm, and apt/yum clients point at it unchanged. v0.1.0 has 12 of 18 protocols fully wired with in-tree conformance tests.
3
Tier storage and de-duplicate blobs

Storage is tiered (hot/warm/cold) with content-addressed blob de-duplication. The blob backend is pluggable across S3 / GCS / Azure / MinIO via object_store, and authentication is on by default — anonymous reads are allowed, while every write and admin action requires an authenticated principal with the right scope.

Highlights

Nexus 3 + Artifactory wire-compatible — existing build tools (Maven / npm / pip / cargo / docker / helm) work unchanged.

Single binary with no JVM and no external DB; sub-second boot, with SQLite + pluggable S3 / GCS / Azure / MinIO blob storage.

12 of 18 protocols wired with conformance tests; auth on by default (anonymous read, authenticated write).

What's included

Self-contained Amazon Linux 2023 AMI (Graviton / arm64, running on t4g, c7g, m7g, and r7g class instances)
Single-binary server with no JVM and no external database (embedded SQLite metadata, blobs on a local volume or object storage, boots in under a second)
12 of 18 protocols fully wired (Maven, npm, OCI / Docker Registry v2, PyPI (PEP 503 family), Cargo sparse index, Go module proxy, Raw/Generic, NuGet v3, RubyGems Compact Index, Helm classic + OCI, APT, YUM/DNF) plus a Nexus REST v1 and Artifactory-compatible admin surface
Tiered hot/warm/cold storage with content-addressed blob de-duplication
Pluggable S3 / GCS / Azure / MinIO blob backends via object_store
Auth on by default (anonymous reads allowed; every write and admin action requires authentication; built-in users or OIDC federation; a unique random admin password generated on first boot)
Support from abyo software ([email protected], first response within one business day; the Enterprise tier via Private Offer adds a 24/7 SLA with one-hour response for Critical issues)

Use cases

Teams replacing Nexus or Artifactory with a single binary that needs no JVM and no external database to operate

Wanting a wire-compatible artifact repository that works with existing Maven, npm, pip, cargo, docker, and helm clients unchanged

A fast-booting, low-overhead single-node package registry for CI/CD pipelines

Running a public-mirror-friendly repository that allows anonymous reads while protecting writes behind authentication

FAQ

Which package ecosystems are supported?

v0.1.0 has 12 of 18 protocols fully wired with in-tree conformance tests: Maven, npm, OCI / Docker Registry v2, PyPI (PEP 503 family), Cargo (sparse index), Go module proxy, Raw/Generic, NuGet v3, RubyGems (Compact Index), Helm (classic + OCI), APT, and YUM/DNF. The remaining six (Conan, Conda, CRAN, Hex, CocoaPods, Bazel) are scope-declared and return 501 today. Honestly, those unimplemented protocols do not work yet.

Does it really need no JVM and no external database?

Correct. FerroRepo runs as one process with no JVM, persisting metadata to an embedded SQLite database and blobs to a local volume or object storage. There is no external database to operate. Where a classic Nexus or Artifactory needs a JVM, gigabytes of heap, and an external database before serving a single artifact, FerroRepo replaces that with one hardened binary that boots in well under a second on a small instance.

How is storage organized?

Storage is tiered hot/warm/cold with content-addressed blob de-duplication. The blob backend is pluggable across S3 / GCS / Azure / MinIO via object_store, while metadata lives in embedded SQLite.

How does authentication work?

Authentication is on by default with a secure-by-default posture. Anonymous reads are allowed, while every write and admin action requires an authenticated principal with the right scope. Built-in users or federation to an external OIDC issuer are supported, and a unique random admin password is generated on first boot — never a default or shared password.

Can it scale across multiple nodes?

Not today. The supported topology is single-node (single-binary) with SQLite metadata and the blob tier on S3. A horizontally scaled multi-node / Postgres-metadata topology is on the roadmap and is not yet supported. Honestly, multi-node configurations are not offered at this time.