FerroRepo
Rust-natives universelles Artifact Repository
Ein Rust-natives universelles Artifact Repository, das als einzelnes, eigenständiges Binary läuft und die Wire-Protokolle von Sonatype Nexus Repository 3 und JFrog Artifactory spricht, sodass bestehende Maven-, npm-, pip-, cargo-, docker- und helm-Clients unverändert funktionieren. Kein JVM und keine externe Datenbank zu betreiben (eingebettetes SQLite + lokales Volume oder Object Storage), Start deutlich unter einer Sekunde.
Ein klassisches Nexus- oder Artifactory-Deployment benötigt ein JVM, Gigabytes an Heap und eine externe Datenbank, bevor es ein einzelnes Artefakt ausliefert; der Single-Binary-Modus von FerroRepo ersetzt dies durch ein gehärtetes Binary, das als eigenständige AMI geliefert wird. v0.1.0 bedient 12 von 18 Package-Protokollen vollständig verdrahtet mit In-Tree-Conformance-Tests — Maven, npm, OCI / Docker Registry v2, PyPI (PEP 503-Familie), Cargo (Sparse Index), Go Module Proxy, Raw/Generic, NuGet v3, RubyGems, Helm (classic + OCI), APT und YUM/DNF — plus eine Nexus REST v1- und Artifactory-kompatible Admin-Oberfläche. Storage ist gestuft (hot/warm/cold) mit content-adressierter Deduplizierung und austauschbaren S3 / GCS / Azure / MinIO Blob-Backends. Authentifizierung ist standardmäßig aktiv: anonyme Reads sind erlaubt, während jeder Write und jede Admin-Aktion einen authentifizierten Principal erfordert.
Das Problem
Klassische Artefakt-Repositories wie Sonatype Nexus Repository 3 und JFrog Artifactory benötigen eine JVM, Gigabytes an Heap und eine externe Datenbank, um überhaupt betrieben werden zu können, bevor sie auch nur ein einziges Artefakt ausliefern. Sie starten schwerfällig und bringen spürbaren Betriebsaufwand mit sich. Teams wünschen sich ein leichteres, einfacher zu betreibendes Repository, bei dem sie ihre bestehenden Tools wie Maven, npm, pip, cargo, docker und helm unverändert weiternutzen können.
Funktionsweise
- 1
Ein einzelnes, in sich geschlossenes Binary starten
FerroRepo läuft als ein Prozess ohne JVM und ohne externe Datenbank und persistiert Metadaten in einem eingebetteten SQLite sowie Blobs auf einem lokalen Volume oder Objektspeicher. Es startet in deutlich unter einer Sekunde auf einer kleinen Instanz und wird als gehärtetes, in sich geschlossenes AMI ausgeliefert.
- 2
Bestehende Clients unverändert darauf ausrichten
FerroRepo spricht die On-the-Wire-HTTP-Protokolle von Nexus Repository 3 und Artifactory, sodass Maven-, npm-, pip-, cargo-, docker-, helm- und apt/yum-Clients unverändert darauf ausgerichtet werden können. In v0.1.0 sind 12 von 18 Protokollen mit In-Tree-Konformitätstests vollständig angebunden.
- 3
Speicher-Tiering nutzen und Blobs deduplizieren
Der Speicher ist gestuft (hot/warm/cold) mit inhaltsadressierter Blob-Deduplizierung. Das Blob-Backend ist über object_store für S3 / GCS / Azure / MinIO austauschbar, und die Authentifizierung ist standardmäßig aktiviert — anonymes Lesen ist erlaubt, während jeder Schreibvorgang und jede administrative Aktion einen authentifizierten Principal mit dem passenden Scope erfordert.
Highlights
Nexus 3 + Artifactory wire-kompatibel — bestehende Build-Tools (Maven / npm / pip / cargo / docker / helm) funktionieren unverändert.
Einzelnes Binary ohne JVM und ohne externe DB; Start unter einer Sekunde, mit SQLite + austauschbarem S3 / GCS / Azure / MinIO Blob Storage.
12 von 18 Protokollen mit Conformance-Tests verdrahtet; Auth standardmäßig aktiv (anonymer Read, authentifizierter Write).
Lieferumfang
- In sich geschlossenes Amazon Linux 2023 AMI (Graviton / arm64, läuft auf Instanzen der Klassen t4g, c7g, m7g und r7g)
- Single-Binary-Server ohne JVM und ohne externe Datenbank (eingebettete SQLite-Metadaten, Blobs auf einem lokalen Volume oder Objektspeicher, startet in unter einer Sekunde)
- 12 von 18 Protokollen vollständig angebunden (Maven, npm, OCI / Docker Registry v2, PyPI (PEP 503-Familie), Cargo sparse index, Go module proxy, Raw/Generic, NuGet v3, RubyGems Compact Index, Helm classic + OCI, APT, YUM/DNF) plus eine Nexus REST v1- und Artifactory-kompatible Admin-Oberfläche
- Gestufter Hot/Warm/Cold-Speicher mit inhaltsadressierter Blob-Deduplizierung
- Austauschbare S3- / GCS- / Azure- / MinIO-Blob-Backends über object_store
- Authentifizierung standardmäßig aktiviert (anonymes Lesen ist erlaubt; jeder Schreibvorgang und jede Admin-Aktion erfordert eine Authentifizierung; integrierte Benutzer oder OIDC-Federation; ein eindeutiges, zufälliges Admin-Passwort wird beim ersten Booten generiert)
- Support von abyo software ([email protected], erste Rückmeldung innerhalb eines Arbeitstags; das Enterprise-Tier über Private Offer ergänzt ein 24/7-SLA mit einstündiger Reaktionszeit für kritische Probleme)
Anwendungsfälle
Teams, die Nexus oder Artifactory durch ein einzelnes Binary ersetzen möchten, das für den Betrieb keine JVM und keine externe Datenbank benötigt
Wunsch nach einem wire-kompatiblen Artefakt-Repository, das mit bestehenden Maven-, npm-, pip-, cargo-, docker- und helm-Clients unverändert funktioniert
Eine schnell startende Single-Node-Paket-Registry mit geringem Overhead für CI/CD-Pipelines
Betrieb eines public-mirror-freundlichen Repositorys, das anonyme Lesevorgänge zulässt, während Schreibzugriffe durch eine Authentifizierung geschützt sind
FAQ
Welche Paket-Ökosysteme werden unterstützt?
v0.1.0 hat 12 von 18 Protokollen mit In-Tree-Konformitätstests vollständig angebunden: Maven, npm, OCI / Docker Registry v2, PyPI (PEP 503-Familie), Cargo (Sparse Index), Go module proxy, Raw/Generic, NuGet v3, RubyGems (Compact Index), Helm (Classic + OCI), APT und YUM/DNF. Die verbleibenden sechs (Conan, Conda, CRAN, Hex, CocoaPods, Bazel) sind im Scope deklariert und geben derzeit 501 zurück. Ehrlich gesagt funktionieren diese nicht implementierten Protokolle noch nicht.
Werden wirklich keine JVM und keine externe Datenbank benötigt?
Richtig. FerroRepo läuft als einzelner Prozess ohne JVM und speichert Metadaten in einer eingebetteten SQLite-Datenbank sowie Blobs auf einem lokalen Volume oder Object Storage. Es muss keine externe Datenbank betrieben werden. Während ein klassisches Nexus oder Artifactory eine JVM, Gigabyte an Heap und eine externe Datenbank benötigt, bevor es auch nur ein einziges Artefakt ausliefern kann, ersetzt FerroRepo dies durch ein einziges gehärtetes Binary, das auf einer kleinen Instanz in deutlich unter einer Sekunde startet.
Wie ist der Storage organisiert?
Der Storage ist in Hot/Warm/Cold unterteilt und bietet eine inhaltsadressierte Blob-Deduplizierung. Das Blob-Backend ist über object_store zwischen S3 / GCS / Azure / MinIO austauschbar, während die Metadaten in einer eingebetteten SQLite-Datenbank liegen.
Wie funktioniert die Authentifizierung?
Die Authentifizierung ist standardmäßig aktiviert und folgt einem Secure-by-Default-Ansatz. Anonyme Lesevorgänge sind zulässig, während jede Schreib- und Administratoraktion einen authentifizierten Principal mit dem passenden Scope erfordert. Integrierte Benutzer oder eine Föderation mit einem externen OIDC-Issuer werden unterstützt, und beim ersten Start wird ein eindeutiges, zufälliges Admin-Passwort generiert — niemals ein Standard- oder gemeinsam genutztes Passwort.
Kann es über mehrere Nodes skaliert werden?
Derzeit nicht. Die unterstützte Topologie ist Single-Node (Single-Binary) mit SQLite-Metadaten und der Blob-Ebene auf S3. Eine horizontal skalierte Multi-Node-/Postgres-Metadaten-Topologie steht auf der Roadmap und wird noch nicht unterstützt. Ehrlich gesagt werden Multi-Node-Konfigurationen zum jetzigen Zeitpunkt nicht angeboten.
Preismodell
Stündliche Softwaregebühr + EC2 (t4g / c7g / m7g / r7g-Klasse, Arm). Abrechnung pro Instance-Typ.
Weitere S4-Produkte
S4 — Squished S3
Transparenter GPU S3-Komprimierungs-Gateway
S4 Logs
CloudWatch Logs nach zstd S3 archivieren
S4 Metrics
CloudWatch Metric-Cardinality steuern