Pulp is one of those projects that solves a real, unglamorous problem — getting software packages to machines that can’t just reach out to the internet — and has been doing it quietly and reliably for over a decade. Dennis Kliban, a contributor with ten years on the project, walks through what Pulp actually is: an open source content management system for mirroring, organizing, and distributing software repositories on-prem or in the cloud.

The architecture is refreshingly honest about its complexity. You get a REST API, a content app, workers, a reverse proxy, PostgreSQL, Redis, and pluggable storage backends (filesystem, S3, GCS). Not a weekend project to stand up, but the deployment options — Kubernetes operator, single container, Compose, or RPM packages — cover most organizational realities. Dennis’s preference for environment variables over config files in OpenShift deployments is the kind of practical opinion that comes from actual production scars.

The demo walks the core loop: create a remote, create a repository, sync, create a distribution, serve content. Simple in concept, but the details matter. Download policies alone reveal how much thought went into the tradeoffs — immediate sync, on-demand lazy fetch, or streamed (never cached). Repository versioning means every change is a new immutable version, and distributions can pin to any of them. That’s snapshot semantics baked into the core model, not bolted on.

Two things stand out. First, package deduplication across repositories — the same artifact stored once on disk regardless of how many repos reference it. Second, the Pulp 2 → Pulp 3 migration story: MongoDB data quality issues made it painful enough that the honest recommendation is just to re-sync from scratch.

Against Artifactory, Pulp’s position is clear: fully open source, no open-core licensing games, but no polished UI either — a basic one only recently landed, inherited from Ansible Automation Platform.