Pulp : le gestionnaire d'artefacts 100% open source

Pulp est un gestionnaire d'artefacts entièrement open source (licence GPL-2.0) qui centralise, met en cache et distribue vos paquets : RPM, DEB, Python, npm, Ansible, images de conteneurs et plus encore. Cette page vous explique ce qu'est Pulp, son modèle de contenu, et pourquoi c'est le concurrent réellement libre de Nexus et Artifactory. Public visé : administrateurs et équipes DevOps qui veulent héberger leurs dépendances sans EULA ni quota. Vous y trouverez le positionnement, le vocabulaire clé et le parcours de prise en main.

Contrairement à Nexus (édition Community sous EULA avec quotas) et Artifactory (produit propriétaire à version gratuite bridée), Pulp est publié sous GPL-2.0 pour le cœur et les plugins, Apache-2.0 pour son interface web. Aucune licence à accepter, aucune limite de composants ou de requêtes : c'est un logiciel libre au sens strict, gouverné par une communauté ouverte.

Ce que vous allez apprendre

• Comprendre le rôle et le modèle de contenu de Pulp.
• Distinguer les notions de remote, repository, publication et distribution.
• Situer Pulp face à Nexus et Artifactory (licence, formats, sécurité).
• Repérer les formats d'artefacts pris en charge par les plugins.

Qu'est-ce que Pulp ?

Pulp est une plateforme de gestion d'artefacts articulée autour d'un noyau, pulpcore, et de plugins spécialisés par format. Vous n'installez pas un dépôt figé : vous activez les plugins dont vous avez besoin (pulp_rpm, pulp_deb, pulp_python, pulp_container, pulp_ansible, pulp_npm, pulp_maven...), et chacun apporte le savoir-faire d'un type de contenu.

Un gestionnaire d'artefacts sert de point unique entre les dépôts publics (PyPI, Docker Hub, un miroir RPM) et vos machines : il met en cache ce que vous téléchargez, héberge vos paquets internes, et expose le tout via des URLs stables pour vos pipelines. Résultat : des builds plus rapides, une provenance maîtrisée et une indépendance vis-à-vis des dépôts publics.

Un projet mûr, pas un jouet

Pulp existe depuis plus de dix ans et anime des plateformes majeures : Red Hat Satellite et Foreman/Katello s'appuient sur Pulp pour distribuer des paquets à grande échelle. La version courante de pulpcore est la 3.114 (2026).

Le modèle de contenu : le vocabulaire à connaître

Pulp ne raisonne pas en « dépôts » monolithiques comme Nexus. Il découpe le cycle de vie d'un artefact en quatre objets, ce qui déroute au début mais offre un versionnement immuable et une grande souplesse.

Objet	Rôle	Analogie
Remote	Décrit une source distante à synchroniser (URL, filtres, politique)	La commande de réappro chez un fournisseur
Repository	Contient les artefacts ; chaque changement crée une version immuable	L'entrepôt et son historique d'inventaire
Publication	Fige une version du dépôt dans un format consommable (index, métadonnées)	Le catalogue imprimé d'un état de stock
Distribution	Expose une publication à une URL stable	La vitrine où le client vient se servir

Glissez pour voir

Cette séparation permet de revenir en arrière instantanément (une distribution pointe vers une autre version) et de publier plusieurs vues d'un même dépôt sans dupliquer les fichiers.

Deux façons d'alimenter un dépôt

Un repository se remplit soit par synchronisation depuis un remote (mode miroir ou proxy d'un dépôt public), soit par upload direct de vos propres artefacts (mode hébergement). Les deux cohabitent dans le même dépôt.

Pourquoi Pulp face à Nexus et Artifactory

Les trois outils font le même métier : centraliser des artefacts multi-formats pour la CI/CD. Le choix se joue sur la licence, la couverture de formats et le modèle de sécurité.

Critère	Pulp	Nexus	Artifactory
Licence	GPL-2.0 / Apache-2.0 (libre)	Community sous EULA + quotas	Propriétaire (gratuit bridé)
Formats	RPM, DEB, Python, npm, Ansible, conteneurs, Maven, gem, OSTree...	Large	Large
Proxy / cache	Oui (remotes + pull-through)	Oui	Oui
RBAC	Fin (rôles par plugin)	Selon édition	Selon édition
Interface	API REST + CLI + UI (jeune)	UI complète	UI complète
Modèle	Remote / Repository / Publication / Distribution	Dépôts (proxy/hosted/group)	Dépôts (local/remote/virtual)

Glissez pour voir

Le point décisif : si l'indépendance logicielle et l'absence de licence commerciale comptent (secteur public, souveraineté, homelab, budget contraint), Pulp est le seul des trois à être réellement libre. En contrepartie, son interface graphique reste jeune et son modèle de contenu demande un temps d'adaptation ; la CLI pulp et l'API REST sont la porte d'entrée principale.

Ce que Pulp ne fait pas nativement

Pulp n'embarque pas de mise en quarantaine automatique des paquets vulnérables (contrairement au pare-feu applicatif de Nexus ou à la curation d'Artifactory Xray). Le filtrage de sécurité se construit avec un scanner externe comme Trivy dans la CI, complété par les rôles RBAC et content-guards. C'est un choix d'architecture, pas un oubli.

Les formats pris en charge

Chaque format est un plugin. L'image officielle pulp/pulp les active presque tous d'emblée, ce qui permet d'héberger dans une même instance vos paquets système, vos bibliothèques applicatives et vos images de conteneurs.

• Système : pulp_rpm (RPM/YUM/DNF), pulp_deb (APT), pulp_ostree.
• Développement : pulp_python (PyPI), pulp_npm (npm), pulp_maven (Java), pulp_gem (Ruby).
• DevOps : pulp_container (registre OCI/Docker), pulp_ansible (collections et rôles).
• Fichiers bruts : pulp_file pour n'importe quel artefact binaire.

Cette couverture multi-formats dans un seul outil est exactement ce qui positionne Pulp comme un concurrent sérieux de Nexus et Artifactory, sans leurs contraintes de licence.

Par où commencer

Le parcours ci-dessous vous fait passer de l'installation à un dépôt sécurisé, chaque étape s'appuyant sur un lab reproductible.

Installer Pulp Déployer Pulp en un conteneur avec podman, la CLI et l'interface web.

Air-gapped et TLS auto-signé Servir Pulp en HTTPS auto-signé et transférer le contenu hors-ligne.

Déployer sur Kubernetes L'operator officiel et la custom resource Pulp, pas à pas.

Publier et consommer des artefacts Le cycle dépôt, publication, distribution, puis un pip install depuis Pulp.

Registre de conteneurs et scan Trivy Cache pull-through de Docker Hub et analyse des images avec Trivy.

Sécuriser Pulp RBAC, content-guards, filtres de synchronisation et signature de contenu.

Signer les artefacts (Cosign, GPG) Signer et vérifier images, RPM et collections avec Cosign et GPG.

Sauvegarder et restaurer Base, artefacts et clés : sauvegarde en conteneur et via PulpBackup sur K8s.

À retenir

• Pulp est un gestionnaire d'artefacts 100% open source (GPL-2.0 / Apache-2.0), sans EULA ni quota.
• Son architecture repose sur un noyau pulpcore et des plugins par format (RPM, DEB, Python, conteneurs...).
• Le modèle de contenu Remote → Repository → Publication → Distribution apporte un versionnement immuable et des retours arrière instantanés.
• Face à Nexus (EULA + quotas) et Artifactory (propriétaire), Pulp est le choix de l'indépendance logicielle.
• Il n'a pas de quarantaine CVE native : la sécurité se construit avec un scanner comme Trivy et le RBAC.

FAQ : Questions fréquentes sur Pulp

Qu'est-ce que Pulp ?

Pulp est un gestionnaire d'artefacts open source, construit autour d'un noyau pulpcore et de plugins par format (RPM, DEB, Python, npm, Ansible, conteneurs). Il synchronise, met en cache, versionne et distribue des paquets pour la CI/CD, comme une alternative libre à Nexus et Artifactory.

Pulp est-il vraiment open source, sans licence commerciale ?

Oui. pulpcore et ses plugins (pulp_rpm, pulp_container, pulp-cli) sont sous licence GPL-2.0, et l'interface web Pulp UI sous Apache-2.0. Il n'y a ni EULA, ni quota, ni open core : c'est un logiciel libre au sens strict, gouverné par une communauté ouverte.

Quelle différence entre Pulp, Nexus et Artifactory ?

Les trois centralisent des artefacts multi-formats pour la CI/CD. Pulp se distingue par sa licence 100% libre (GPL) et son modèle Remote/Repository/Publication/Distribution avec versions immuables. Nexus et Artifactory offrent une interface graphique plus mature mais imposent une licence.

Comment installer Pulp rapidement ?

L'image officielle pulp/pulp fait tourner toute la pile (API, workers, PostgreSQL, Redis, nginx) dans un seul conteneur. On la lance avec podman en publiant le port 80, on définit le mot de passe admin via pulpcore-manager, puis on pilote l'instance avec la CLI pulp.

Pulp peut-il servir de registre de conteneurs et scanner les images ?

Oui. Le plugin pulp_container fait de Pulp un registre OCI capable d'héberger vos images et de mettre Docker Hub en cache (pull-through). Le scan de vulnérabilités n'est pas natif : on branche un scanner externe comme Trivy dans la CI, qui analyse les images et bloque les CVE critiques.

Pulp met-il en quarantaine les paquets vulnérables ?

Non, pas nativement. Pulp n'a pas d'équivalent au pare-feu de Nexus ni à la curation d'Artifactory Xray. Il fournit les briques : filtres includes/excludes à la synchronisation, RBAC, content-guards et signature. La détection CVE se construit avec un scanner externe dans la CI.

Prochaines étapes

Installer Pulp Le lab conteneur, pas à pas.

Nexus Comparer avec le gestionnaire de Sonatype.

Artifactory Comparer avec la JFrog Platform.

Trivy Le scanner de vulnérabilités à brancher sur vos artefacts.

×

📖 Voir la documentation →