FerroRepo
Référentiel universel d’artefacts natif Rust
Un référentiel universel d’artefacts natif Rust qui s’exécute comme un binaire unique autonome et parle les protocoles filaires de Sonatype Nexus Repository 3 et JFrog Artifactory, afin que les clients Maven, npm, pip, cargo, docker et helm existants fonctionnent sans modification. Pas de JVM ni de base de données externe à opérer (SQLite embarqué + volume local ou object storage), avec un démarrage largement inférieur à une seconde.
Un déploiement Nexus ou Artifactory classique nécessite une JVM, des gigaoctets de heap et une base de données externe avant de servir un seul artefact ; le mode binaire unique de FerroRepo remplace cela par un binaire durci livré comme AMI autonome. v0.1.0 sert 12 des 18 protocoles de packages entièrement câblés avec des tests de conformité in-tree — Maven, npm, OCI / Docker Registry v2, PyPI (famille PEP 503), Cargo (sparse index), proxy de modules Go, Raw/Generic, NuGet v3, RubyGems, Helm (classic + OCI), APT et YUM/DNF — plus une surface d’administration compatible Nexus REST v1 et Artifactory. Le stockage est hiérarchisé (hot/warm/cold) avec déduplication adressée par contenu et backends blob S3 / GCS / Azure / MinIO enfichables. L’authentification est activée par défaut : les lectures anonymes sont autorisées, tandis que chaque écriture et action d’administration exige un principal authentifié.
Le problème
Les dépôts d'artefacts classiques comme Sonatype Nexus Repository 3 et JFrog Artifactory nécessitent une JVM, des gigaoctets de heap et une base de données externe pour fonctionner avant de pouvoir servir un seul artefact. Ils sont lourds au démarrage et imposent une réelle surcharge opérationnelle. Les équipes souhaitent un dépôt plus léger et plus simple à exécuter tout en conservant leurs outils Maven, npm, pip, cargo, docker et helm existants inchangés.
Fonctionnement
- 1
Démarrer un seul binaire autonome
FerroRepo s'exécute en un seul processus sans JVM ni base de données externe, persistant les métadonnées dans un SQLite embarqué et les blobs sur un volume local ou un stockage d'objets. Il démarre en bien moins d'une seconde sur une petite instance et est fourni sous la forme d'une AMI autonome et sécurisée.
- 2
Pointez vos clients existants vers lui sans modification
FerroRepo implémente les protocoles HTTP réseau de Nexus Repository 3 et d'Artifactory, ainsi les clients Maven, npm, pip, cargo, docker, helm et apt/yum pointent vers lui sans modification. La version v0.1.0 propose 12 des 18 protocoles entièrement fonctionnels avec des tests de conformité intégrés (in-tree).
- 3
Hiérarchiser le stockage et dédupliquer les blobs
Le stockage est hiérarchisé (hot/warm/cold) avec une déduplication des blobs par adressage de contenu. Le backend de blobs est interchangeable (S3 / GCS / Azure / MinIO) via object_store, et l'authentification est activée par défaut — les lectures anonymes sont autorisées, tandis que chaque écriture et action d'administration nécessite un principal authentifié disposant du scope approprié.
Points forts
Compatible filaire Nexus 3 + Artifactory — les outils de build existants (Maven / npm / pip / cargo / docker / helm) fonctionnent sans modification.
Binaire unique sans JVM ni DB externe ; démarrage en moins d’une seconde, avec SQLite + stockage blob S3 / GCS / Azure / MinIO enfichable.
12 des 18 protocoles câblés avec tests de conformité ; auth activée par défaut (lecture anonyme, écriture authentifiée).
Ce qui est inclus
- AMI Amazon Linux 2023 autonome (Graviton / arm64, s'exécutant sur les instances des classes t4g, c7g, m7g et r7g)
- Serveur à binaire unique sans JVM ni base de données externe (métadonnées SQLite embarquées, blobs sur volume local ou stockage d'objets, démarrage en moins d'une seconde)
- 12 des 18 protocoles entièrement configurés (Maven, npm, OCI / Docker Registry v2, PyPI (famille PEP 503), index Cargo sparse, proxy de module Go, Raw/Generic, NuGet v3, RubyGems Compact Index, Helm classique + OCI, APT, YUM/DNF) en plus d'une interface d'administration compatible Nexus REST v1 et Artifactory
- Stockage hiérarchisé hot/warm/cold avec déduplication des blobs par adressage de contenu
- Backends de blobs S3 / GCS / Azure / MinIO interchangeables via object_store
- Authentification activée par défaut (lectures anonymes autorisées ; chaque écriture et action d'administration nécessite une authentification ; utilisateurs intégrés ou fédération OIDC ; un mot de passe administrateur aléatoire unique généré au premier démarrage)
- Support par abyo software ([email protected], première réponse sous un jour ouvrable ; le niveau Enterprise via Private Offer ajoute un SLA 24/7 avec un temps de réponse d'une heure pour les incidents de niveau Critical)
Cas d'usage
Équipes remplaçant Nexus ou Artifactory par un binaire unique ne nécessitant ni JVM ni base de données externe pour fonctionner
Souhaiter un dépôt d'artefacts wire-compatible fonctionnant avec les clients existants Maven, npm, pip, cargo, docker et helm sans modification
Un registre de paquets mono-nœud à démarrage rapide et à faible surcharge pour les pipelines CI/CD
L'exploitation d'un dépôt compatible avec les miroirs publics qui autorise les lectures anonymes tout en protégeant les écritures par authentification
FAQ
Quels écosystèmes de paquets sont pris en charge ?
La version v0.1.0 propose 12 des 18 protocoles entièrement connectés avec des tests de conformité in-tree : Maven, npm, OCI / Docker Registry v2, PyPI (famille PEP 503), Cargo (sparse index), Go module proxy, Raw/Generic, NuGet v3, RubyGems (Compact Index), Helm (classic + OCI), APT et YUM/DNF. Les six restants (Conan, Conda, CRAN, Hex, CocoaPods, Bazel) sont déclarés dans le périmètre et renvoient un code 501 aujourd'hui. Pour être honnête, ces protocoles non implémentés ne fonctionnent pas encore.
N'a-t-il vraiment pas besoin de JVM ni de base de données externe ?
C'est exact. FerroRepo fonctionne comme un seul processus sans JVM, persistant les métadonnées dans une base de données SQLite intégrée et les blobs dans un volume local ou un stockage d'objets. Il n'y a aucune base de données externe à exploiter. Alors qu'un Nexus ou un Artifactory classique nécessite une JVM, des gigaoctets de heap et une base de données externe avant de servir le moindre artefact, FerroRepo les remplace par un seul binaire sécurisé qui démarre en bien moins d'une seconde sur une petite instance.
Comment le stockage est-il organisé ?
Le stockage est hiérarchisé en niveaux hot/warm/cold avec déduplication des blobs par adressage de contenu. Le backend de blobs est interchangeable entre S3 / GCS / Azure / MinIO via object_store, tandis que les métadonnées résident dans une base SQLite intégrée.
Comment fonctionne l'authentification ?
L'authentification est activée par défaut avec une posture sécurisée par défaut. Les lectures anonymes sont autorisées, tandis que chaque action d'écriture et d'administration requiert un principal authentifié doté du scope approprié. Les utilisateurs intégrés ou la fédération avec un émetteur OIDC externe sont pris en charge, et un mot de passe administrateur aléatoire unique est généré au premier démarrage — jamais de mot de passe par défaut ou partagé.
Peut-il passer à l'échelle sur plusieurs nœuds ?
Pas pour le moment. La topologie prise en charge est mono-nœud (binaire unique) avec des métadonnées SQLite et le niveau blob sur S3. Une topologie multi-nœud à mise à l'échelle horizontale avec métadonnées Postgres est sur la feuille de route et n'est pas encore prise en charge. Pour être honnête, les configurations multi-nœuds ne sont pas proposées pour le moment.
Modèle de tarification
Frais logiciel horaires + EC2 (classe t4g / c7g / m7g / r7g, Arm). Facturation à l’usage par type d’instance.
Autres produits S4
S4 — Squished S3
Gateway transparent de compression S3 par GPU
S4 Logs
Archiver CloudWatch Logs vers S3 zstd
S4 Metrics
Gouverner la cardinalité des métriques CloudWatch