FerroRepo
Repositório universal de artefatos nativo em Rust
Um repositório universal de artefatos nativo em Rust que roda como um único binário autocontido e fala os wire protocols do Sonatype Nexus Repository 3 e do JFrog Artifactory, para que clientes Maven, npm, pip, cargo, docker e helm existentes funcionem sem alterações. Sem JVM e sem banco de dados externo para operar (SQLite embutido + volume local ou object storage), com boot em bem menos de um segundo.
Uma implantação clássica de Nexus ou Artifactory precisa de uma JVM, gigabytes de heap e um banco de dados externo antes de servir um único artefato; o modo de binário único do FerroRepo substitui isso por um binário hardened distribuído como uma AMI autocontida. A v0.1.0 atende 12 de 18 protocolos de pacotes totalmente conectados com testes de conformidade in-tree — Maven, npm, OCI / Docker Registry v2, PyPI (família PEP 503), Cargo (sparse index), proxy de módulos Go, Raw/Generic, NuGet v3, RubyGems, Helm (classic + OCI), APT e YUM/DNF — além de uma superfície administrativa compatível com Nexus REST v1 e Artifactory. O storage é em camadas (hot/warm/cold), com deduplicação por endereçamento de conteúdo e backends de blob plugáveis S3 / GCS / Azure / MinIO. A autenticação vem ativada por padrão: leituras anônimas são permitidas, enquanto toda escrita e ação administrativa exige um principal autenticado.
O problema
Repositórios de artefatos clássicos, como o Sonatype Nexus Repository 3 e o JFrog Artifactory, exigem uma JVM, gigabytes de heap e um banco de dados externo para operar antes de servirem a um único artefato. Eles são pesados para inicializar e trazem uma sobrecarga operacional real. As equipes desejam um repositório mais leve e fácil de executar, mantendo inalteradas suas ferramentas existentes do Maven, npm, pip, cargo, docker e helm.
Como funciona
- 1
Inicie um único binário autocontido
O FerroRepo é executado como um único processo, sem JVM e sem banco de dados externo, persistindo os metadados no SQLite incorporado e os blobs em um volume local ou armazenamento de objetos. Ele inicia em bem menos de um segundo em uma instância pequena e é distribuído como uma AMI protegida e autocontida.
- 2
Aponte os clientes existentes para ele sem alterações
O FerroRepo implementa os protocolos HTTP de rede do Nexus Repository 3 e do Artifactory, permitindo que clientes Maven, npm, pip, cargo, docker, helm e apt/yum apontem para ele sem alterações. A versão v0.1.0 tem 12 de 18 protocolos totalmente integrados, com testes de conformidade in-tree.
- 3
Armazenamento em camadas e desduplicação de blobs
O armazenamento é em camadas (hot/warm/cold) com desduplicação de blobs endereçada por conteúdo. O backend de blobs é plugável entre S3 / GCS / Azure / MinIO via object_store, e a autenticação fica ativa por padrão — leituras anônimas são permitidas, enquanto qualquer escrita e ação administrativa exige um principal autenticado com o escopo correto.
Destaques
Compatível no wire protocol com Nexus 3 + Artifactory — ferramentas de build existentes (Maven / npm / pip / cargo / docker / helm) funcionam sem alterações.
Binário único sem JVM e sem DB externo; boot sub-segundo, com SQLite + storage de blobs plugável S3 / GCS / Azure / MinIO.
12 de 18 protocolos conectados com testes de conformidade; autenticação ativada por padrão (leitura anônima, escrita autenticada).
O que está incluído
- AMI autocontida baseada no Amazon Linux 2023 (Graviton / arm64, executada em instâncias das classes t4g, c7g, m7g e r7g)
- Servidor de binário único, sem JVM e sem banco de dados externo (metadados no SQLite incorporado, blobs em volume local ou armazenamento de objetos, inicialização em menos de um segundo)
- 12 de 18 protocolos totalmente integrados (Maven, npm, OCI / Docker Registry v2, PyPI (família PEP 503), índice esparso do Cargo, proxy de módulo Go, Raw/Generic, NuGet v3, RubyGems Compact Index, Helm classic + OCI, APT, YUM/DNF) mais uma interface de administração compatível com Nexus REST v1 e Artifactory
- Armazenamento em camadas hot/warm/cold com desduplicação de blobs endereçada por conteúdo
- Backends de blob plugáveis para S3 / GCS / Azure / MinIO via object_store
- Autenticação ativa por padrão (leituras anônimas permitidas; qualquer escrita e ação administrativa exige autenticação; usuários integrados ou federação OIDC; senha de administrador aleatória e exclusiva gerada no primeiro boot)
- Suporte da abyo software ([email protected], primeira resposta em até um dia útil; a categoria Enterprise via Private Offer adiciona um SLA 24/7 com resposta em uma hora para problemas críticos)
Casos de uso
Equipes que desejam substituir o Nexus ou o Artifactory por um único binário que não requer JVM nem banco de dados externo para funcionar
Quem deseja um repositório de artefatos compatível a nível de protocolo que funcione com clientes Maven, npm, pip, cargo, docker e helm existentes sem alterações
Um registro de pacotes de nó único com inicialização rápida e baixo overhead para pipelines de CI/CD
Operação de um repositório compatível com espelhamento público que permite leituras anônimas enquanto protege escritas por meio de autenticação
FAQ
Quais ecossistemas de pacotes são suportados?
A v0.1.0 tem 12 de 18 protocolos totalmente integrados com testes de conformidade in-tree: Maven, npm, OCI / Docker Registry v2, PyPI (família PEP 503), Cargo (sparse index), Go module proxy, Raw/Generic, NuGet v3, RubyGems (Compact Index), Helm (clássico + OCI), APT e YUM/DNF. Os seis restantes (Conan, Conda, CRAN, Hex, CocoaPods, Bazel) têm escopo declarado e retornam 501 hoje. Sinceramente, esses protocolos não implementados ainda não funcionam.
Realmente não precisa de JVM nem de banco de dados externo?
Correto. O FerroRepo roda como um processo único sem JVM, persistindo metadados em um banco de dados SQLite incorporado e blobs em um volume local ou object storage. Não há banco de dados externo para gerenciar. Onde um Nexus ou Artifactory clássico precisa de uma JVM, gigabytes de heap e um banco de dados externo antes de servir um único artefato, o FerroRepo substitui isso por um único binário protegido que inicializa em bem menos de um segundo em uma instância pequena.
Como o armazenamento é organizado?
O armazenamento é dividido em camadas hot/warm/cold com desduplicação de blobs endereçados por conteúdo. O backend de blobs é plugável entre S3 / GCS / Azure / MinIO via object_store, enquanto os metadados residem no SQLite incorporado.
Como funciona a autenticação?
A autenticação vem ativada por padrão com uma postura segura por padrão. Leituras anônimas são permitidas, enquanto toda escrita e ação de administrador exige um principal autenticado com o escopo correto. Suporta usuários integrados ou federação com um emissor OIDC externo, e uma senha de administrador aleatória e exclusiva é gerada na primeira inicialização — nunca uma senha padrão ou compartilhada.
É possível escalar em múltiplos nós?
Atualmente não. A topologia suportada é single-node (single-binary) com metadados SQLite e a camada de blobs no S3. Uma topologia multi-node escalada horizontalmente com metadados Postgres está no roadmap e ainda não é suportada. Sinceramente, configurações multi-node não são oferecidas no momento.
Modelo de precificação
Taxa horária de software + EC2 (classe t4g / c7g / m7g / r7g, Arm). Medição por tipo de instância.
Outros produtos S4
S4 — Squished S3
Gateway transparente de compressão S3 com GPU
S4 Logs
Arquive CloudWatch Logs em S3 com zstd
S4 Metrics
Controle a cardinalidade de métricas do CloudWatch