Pulp: the 100% open source artifact manager

Pulp is a fully open source artifact manager (GPL-2.0 licence) that centralises, caches and distributes your packages: RPM, DEB, Python, npm, Ansible, container images and more. This page explains what Pulp is, its content model, and why it is the genuinely free competitor to Nexus and Artifactory. Intended audience: administrators and DevOps teams who want to host their dependencies with no EULA and no quota. You will find the positioning, the key vocabulary and the path to getting started.

Unlike Nexus (Community edition under EULA with quotas) and Artifactory (a proprietary product with a restricted free version), Pulp is published under GPL-2.0 for the core and the plugins, and Apache-2.0 for its web interface. No licence to accept, no limit on components or requests: it is free software in the strict sense, governed by an open community.

What you will learn

• Understand the role and the content model of Pulp.
• Tell apart the notions of remote, repository, publication and distribution.
• Place Pulp against Nexus and Artifactory (licence, formats, security).
• Identify the artifact formats supported by the plugins.

What is Pulp?

Pulp is an artifact management platform built around a core, pulpcore, and plugins specialised by format. You do not install a fixed repository: you enable the plugins you need (pulp_rpm, pulp_deb, pulp_python, pulp_container, pulp_ansible, pulp_npm, pulp_maven...), and each one brings the know-how of one content type.

An artifact manager acts as a single point between public repositories (PyPI, Docker Hub, an RPM mirror) and your machines: it caches what you download, hosts your internal packages, and exposes everything through stable URLs for your pipelines. The result: faster builds, controlled provenance and independence from public repositories.

A mature project, not a toy

Pulp has existed for more than ten years and powers major platforms: Red Hat Satellite and Foreman/Katello rely on Pulp to distribute packages at scale. The current pulpcore version is 3.114 (2026).

The content model: the vocabulary to know

Pulp does not think in monolithic "repositories" the way Nexus does. It splits the lifecycle of an artifact into four objects, which is confusing at first but gives you immutable versioning and great flexibility.

Object	Role
Remote	Describes a remote source to sync (URL, filters, policy)
Repository	Holds the artifacts; every change creates an immutable version
Publication	Freezes a repository version in a consumable format (index, metadata)
Distribution	Exposes a publication at a stable URL

Swipe to see more

This separation lets you roll back instantly, by pointing a distribution at another version, and publish several views of the same repository without duplicating files.

Two ways to feed a repository

A repository is filled either by synchronisation from a remote, in mirror or proxy mode for a public repository, or by direct upload of your own artifacts, in hosting mode. Both modes coexist on the same instance.

Why Pulp rather than Nexus or Artifactory

The three tools do the same job: centralise multi-format artifacts for CI/CD. The choice comes down to the licence, the format coverage and the security model.

Criterion	Pulp	Nexus	Artifactory
Licence	GPL-2.0 / Apache-2.0 (free)	Community under EULA + quotas	Proprietary (restricted free tier)
Formats	RPM, DEB, Python, npm, Ansible, containers, Maven, gem, OSTree...	Broad	Broad
Proxy / cache	Yes (remotes + pull-through)	Yes	Yes
RBAC	Fine-grained (roles per plugin)	Depends on edition	Depends on edition
Interface	REST API + CLI + UI (young)	Full UI	Full UI
Model	Remote / Repository / Publication / Distribution	Repositories (proxy/hosted/group)	Repositories (local/remote/virtual)

Swipe to see more

The deciding point: if software independence and the absence of a commercial licence matter (public sector, sovereignty, homelab, tight budget), Pulp is the only one of the three that is genuinely free. In return, its graphical interface is still young and its content model takes some getting used to; the pulp CLI and the REST API are the main entry point.

What Pulp does not do natively

Pulp does not ship automatic quarantine of vulnerable packages, unlike the application firewall of Nexus or the curation of Artifactory Xray. Security filtering is built with external components.

Supported formats

Each format is a plugin. The official pulp/pulp image enables almost all of them out of the box, so you can host your system packages, your application libraries and your container images in a single instance.

• System: pulp_rpm (RPM/YUM/DNF), pulp_deb (APT), pulp_ostree.
• Development: pulp_python (PyPI), pulp_npm (npm), pulp_maven (Java), pulp_gem (Ruby).
• DevOps: pulp_container (OCI/Docker registry), pulp_ansible (collections and roles).
• Raw files: pulp_file for any binary artifact.

This multi-format coverage in a single tool is exactly what positions Pulp as a serious competitor to Nexus and Artifactory, without their licence constraints.

Where to start

The thread of this section follows the order in which the notions build on each other. You start by installing Pulp in a single container, with its CLI and its interface, then you run the full cycle of an artifact in publish and consume: a file repository filled by hand, then a PyPI proxy consumed by a real pip install.

Next come the two uses that give an internal repository its value. The container registry puts Docker Hub in a cache and plugs in a Trivy scan where the decision is really made, in the integration chain. The securing Pulp page sets up RBAC, content-guards and intake filters, and says frankly what Pulp does not do: automatic quarantine of vulnerable packages.

The last three pages cover what you only look at once the repository is in production. Signing artifacts distinguishes client-side signing with Cosign from server-side signing with a GPG signing service. Backup and restore shows why an incomplete backup gives a broken restore, since Pulp's data lives in three distinct places. And air-gapped and self-signed TLS covers the closed network case: serving HTTPS without a public authority, and getting content in without Internet.

One page stands apart, for those who already run a cluster: deploying on Kubernetes, with the official operator and its custom resource.

Key points

• Pulp is a 100% open source artifact manager (GPL-2.0 / Apache-2.0), with no EULA and no quota.
• Its architecture rests on a pulpcore kernel and plugins per format (RPM, DEB, Python, containers...).
• The Remote → Repository → Publication → Distribution content model brings immutable versioning and instant rollbacks.
• Against Nexus (EULA + quotas) and Artifactory (proprietary), Pulp is the choice of software independence.
• It has no native CVE quarantine: security is built with a scanner such as Trivy and RBAC.

Knowledge check

Six questions on the vocabulary that throws people off at first and on what it buys you: the four objects of the content model, the instant rollback, and what Pulp does not do on its own.

Knowledge check

Check what you have learned with this interactive quiz

6 questions

6 min

70% to pass

How it works

• The timer starts when you click Start
• Multiple choice, true/false and short answer questions
• You can move between questions
• Detailed results are shown at the end

Start the quiz

Starts the quiz and the timer

FAQ: frequently asked questions about Pulp

What is Pulp?

Is Pulp really open source, with no commercial licence?

What is the difference between Pulp, Nexus and Artifactory?

How do I install Pulp quickly?

Can Pulp act as a container registry and scan images?

Does Pulp quarantine vulnerable packages?

×

See in the glossary →