Our team is setting up a software package manager and initially looked at Nexus, but the free edition has limits that block requirements such as SSO, while the paid license is currently outside our budget. Artifactory is another familiar option, but we are exploring Pulp as an open-source alternative. We run workloads on EKS, and the initial Nexus deployment was fairly straightforward, although licensing prevented us from completing full testing. Pulp's operator looks promising for Kubernetes, but I have not used it before. For anyone with experience running Pulp, what are its main strengths, limitations, and operational gotchas? Does it hold up for package caching, versioned repositories, automation, and production use, or are there reasons you eventually wished you had paid for Nexus or Artifactory?
3 Answers
Pulp seems like a solid package repository and is worth evaluating, especially for caching build dependencies and maintaining versioned repositories. Its API-first design fits well with Kubernetes, GitOps, and automation. The project also appears to have strong backing and real-world adoption, so abandonment does not seem like a major concern. The biggest drawback we noticed was the user interface, which felt fairly rough compared with commercial products. We also found Nexus somewhat clunky for RPM caching and versioned repositories.
I would deploy Pulp in a spike and test the workflows you actually need: package uploads and downloads, repository versioning, cleanup, authentication, SSO integration, backups, upgrades, and Kubernetes recovery. It may meet the functional requirements well, but compare the engineering time required to operate it against the Nexus or Artifactory license cost. The lower software price does not necessarily mean zero ownership cost.
The main thing to evaluate is not just whether Pulp works technically, but who will own it once it becomes business-critical. With a standalone deployment, your team is responsible for upgrades, security fixes, compatibility, monitoring, and troubleshooting. If you want Pulp’s underlying technology without carrying all of that operational risk, an enterprise distribution built around Pulp may be worth considering because it can provide supported releases and escalation paths.
That is probably the approach I will take. Nexus Community Edition has been frustrating because several important requirements are gated behind the license, so I want to see whether Pulp handles the core workflows cleanly before making the case either way.