I propri pacchetti npm e immagini Docker, su un registry ospitato in proprio.

Repository ospitati, proxy e gruppi, quote, conservazione, audit delle dipendenze e scansione delle immagini: un binario Rust e un PostgreSQL. In produzione, il server e il suo database occupano insieme una cinquantina di MiB di memoria.

Apri ArtiFerris
$docker compose up -d --build

Nessun account presso terzi, nessuna telemetria inviata. Vedere l'architettura.

$ kubectl top pod -n artiferris --containers
POD                                    NAME             CPU(cores)   MEMORY(bytes)
artiferris-7f497fb86-pcft9             artiferris-api   2m           5Mi
artiferris-postgres-7f7784f89f-rcd4s   postgres         9m           48Mi
L'istanza di produzione, versione 0.6.1, su un cluster Kubernetes (amd64), misurata il 6 ottobre 2026, pochi minuti dopo il riavvio del server.

Casi d'uso

Quattro situazioni tipiche, e la risposta che ArtiFerris dà a ciascuna.

Le build scaricano le loro dipendenze da un registry pubblico, ogni volta.
Un repository proxy si mette davanti a registry.npmjs.org o Docker Hub: la prima richiesta recupera il pacchetto a monte, le successive lo servono da ArtiFerris. Un gruppo riunisce questo proxy e i propri pacchetti dietro un unico indirizzo.
Si ospitano i pacchetti di più team o di più clienti sulla stessa istanza.
Ogni organizzazione ha il suo sottodominio, i suoi repository, i suoi utenti, il suo marchio e il suo provider di identità. I suoi amministratori agiscono soltanto su di essa; un super-amministratore le vede tutte.
Si vuole sapere cosa contengono le immagini e i pacchetti che si distribuiscono.
Trivy analizza ogni immagine caricata, e la scansione si può rilanciare a mano. Le dipendenze di un pacchetto npm vengono verificate a ogni pubblicazione. I risultati compaiono sulla pagina dell'immagine o del pacchetto.
Si vuole che l'autenticazione a due fattori non dipenda dalla diligenza di ciascuno.
È obbligatoria per ogni account, locale o proveniente da LDAP o OIDC. Gli strumenti da riga di comando si autenticano con un token API, che l'amministrazione può elencare e revocare.

Panoramica del prodotto

Estratti dell'interfaccia reale, non bozzetti. L'interfaccia esiste in francese, inglese, spagnolo, italiano e tedesco.

L'elenco completo delle funzionalità

Architettura

Un processo, sei crate, un'architettura esagonale: il dominio non sa nulla del database, e ogni protocollo di registry ha il suo crate.

Il codice sorgente su GitHub

Architettura di un'istanza ArtiFerrisDisegno isometrico. Un client npm o Docker e un browser parlano con un unico binario Rust, artiferris-api, composto dai crate api, npm, docker, application, domain e infrastructure. Il binario conserva i dati in PostgreSQL e gli archivi e i blob su disco, interroga le directory LDAP e OIDC e il server SMTP, e i suoi proxy attingono da registry a monte. Una linea arancione segue un'installazione fino al registry a monte. Sette cerchi numerati portano ai riquadri della pagina.api npm docker application domain infrastructure artiferris-api: un unico binario Client npm o Docker HTTPS, token API npm, pnpm, yarn, docker, podman Browser console con accesso o catalogo pubblico api, npm, docker API REST, protocolli dei registry, interfaccia web domain entità e porte, senza I/O application casi d'uso infrastructure adattatori: PostgreSQL, file, SMTP, LDAP, OIDC, Trivy, proxy PostgreSQL account, repository, permessi, audit; migrazioni all'avvio Archiviazione archivi npm e blob Docker, su disco Registry a monte registry.npmjs.org, Docker Hub…: un proxy vi attinge e conserva Directory e e-mail LDAP, OIDC, SMTP npm install gruppo, poi proxy a monte

Fig. 1 Un'istanza. La linea arancione segue un'installazione, dal client fino al registry a monte che un proxy interroga.

  • richiesta o archiviazione
  • un'installazione, fino a monte
  • directory interrogata all'accesso
  • un riquadro numerato di questa pagina
  1. artiferris-domainEntità, oggetti valore e le porte da cui dipende il resto. Nessun input né output.
  2. artiferris-applicationI casi d'uso. Dipende soltanto dal dominio.
  3. artiferris-infrastructureAdattatori: PostgreSQL (SQLx), file, SMTP, LDAP, OIDC, Trivy, Argon2, JWT.
  4. artiferris-apiIl server Axum: rotte, assemblaggio e il frontend Angular. È lui il binario.
  5. artiferris-npmIl protocollo del registry npm.
  6. artiferris-dockerIl protocollo del registry Docker/OCI.

Cosa manca oggi

Da conoscere prima della distribuzione.

Soltanto due formati
npm e Docker/OCI. Maven, PyPI, NuGet, Cargo, Go, Helm e i repository raw sono nella roadmap.
Una sola replica
L'archiviazione è un file system locale: un volume, una replica. È previsto uno storage compatibile S3.
Niente SAML
Gli account provengono da ArtiFerris, da LDAP o Active Directory, o da un provider OIDC.
Niente firma dei pacchetti
La firma e la provenienza (Sigstore, npm provenance) sono nella roadmap.

Prospettive

Ciò che è previsto, ancora senza versione. Un punto viene spuntato solo quando è rilasciato.

  1. FormatiMaven, PyPI, NuGet, Cargo, Go, Helm e repository rawPrevisto
  2. ArchiviazioneUno storage a oggetti compatibile S3, per più replichePrevisto
  3. EsercizioAlta disponibilità e replica geograficaPrevisto
  4. ProvenienzaFirma e provenienza dei pacchettiPrevisto
  5. IdentitàSAMLPrevisto

Provare ArtiFerris, poi distribuire la propria istanza.

L'istanza pubblica permette di scoprire il prodotto. La propria istanza conserva i propri pacchetti.

Avviare lo stack con Docker Compose
git clone https://github.com/Masmarino/ArtiFerris.git
cd ArtiFerris
cp .env.example .env
# set POSTGRES_PASSWORD, JWT_SECRET, SECRETS_ENCRYPTION_KEY, PUBLIC_URL and the first admin in .env
docker compose up -d --build