Choosing between ProGet and JFrog Artifactory
Uncover the major differences between ProGet and JFrog Artifactory in this helpful comparison guide
Inedo’s ProGet and JFrog Artifactory each offer a private repository solution—but they are not equal. Compared to the artifact mindset, ProGet’s package mindset offers control and peace-of-mind through data.
ProGet is a package repository built to manage packages like NuGet, npm, Chocolatey, and more, and Docker containers, all in one place.
JFrog Artifactory is a universal artifact repository that manages all file types.
Both products have the same purpose but with different file management approaches.
JFrog Artifactory takes the artifacts approach. Artifacts can be any type of file such as .jar., .war, .dll, .rpm, .zip, .jpg, etc. While an artifact server understands each individual file type’s properties, you have to configure the rules you want to apply to files uploaded to enforce naming conventions and file scans.
On the other hand, ProGet takes the packages approach. Packages have a standards-defined format like NuGet, PyPi, Helm, and so on. Your NuGet packages can only be in NuGet feeds, for example, segregated from other package types.
Just like a Blu-ray player doesn’t allow you to play a VHS tape, this strict formatting gives organizations more control over the code entering or leaving different feeds.
What Does This Mean for You?
An artifact repository is a collection of files, much like a normal share drive, which also manages your end-to-end artifact lifecycle when building. While this does make it easy to move, copy, and share files, it’s outdated because any and every file type is allowed. More files with less metadata make an auditing nightmare.
ProGet’s modern approach is a better fit for modern development. Because it’s not an open-ended format, package-minded solutions like ProGet help organizations enforce separation while allowing collaboration between teams. And ProGet is far superior for handling NuGet packages, as it was originally developed to support this popular development format.
Can Artifact Servers Handle Packages?
Yes and no. As an artifact server, JFrog Artifactory can technically handle any file type, like .nupkg. But the problem with handling everything is that you specialize in nothing.
JFrog Artifactory lags in their support for NuGet. A quick search on their public NuGet issues tracker reveals a plague of NuGet-related bugs. And it takes some time for JFrog to fix these issues, even the critical ones.
Can Package Servers Handle Artifacts?
Yes, they can. Artifacts are just files, after all. It was easy to get ProGet “think in artifacts” to support Maven or any other type of artifact. Both, Maven Feeds and Asset Directories have seen next to no bugs in ProGet for years.
What about Source and Symbol Serving for NuGet?
Debugging with symbol and source serving is a must-have feature when developing your own packages. How do ProGet and JFrog Artifactory compare?
ProGet has always supported Source and Symbol Serving for NuGet, since day one, right out of the box.
Despite being one of Artifactory’s top-requested features for 8 years, there’s still no indication JFrog intends to support symbol serving in their product.
Metadata Storage for Packages versus Artifacts
Metadata helps you identify the properties of each file when auditing and moving them. ProGet’s approach to metadata far exceeds JFrog Artifactory’s antiquated method.
Embedded Metadata
As packages are moved and downloaded, this metadata moves with them. Auditing and tracking down bugs are simpler, because information is independent of individual employees.
Server-side Metadata
No embedded manifest means information is lost in the development process. Tracking down bugs and auditing becomes next to impossible because records are only on the JFrog Artifactory server. It’s up to each individual employee who downloaded or moved each individual artifact to remember information about it.
Top 4 Problems with Artifacts
1. Artifacts don’t give information when and where you need it.
When key production systems go down, finding what software changed on the server is vital to rolling back fast. Packages offer superior information storage to artifacts.
With artifacts, all you have is bare files. When the files were copied to the server or why or by whom is not included. And even thorough change logs still miss contextual information – why was the file changed? To get this information, you’ll have to talk with every employee who might have worked on this file on this server.
With packages on ProGet, you can see what was recently installed or updated on the server quickly. Embedded metadata lets you see the who, what, and when for each package. Following a package’s trail back after a problem is straightforward, making resolution faster and easier.
2. Artifacts are almost impossible to audit.
Auditing is stressful enough without being unable to answer an auditor’s questions (“Where did this file come from?” “Why is this file on the production server?”). When a program is more than a few months old, you may never be able to find that answer, because artifacts are files with no context.
With packages, you know exactly what programs are installed on each server. You know the versions and who installed them. And with a tool like Otter, you can remotely monitor the packages on the servers, to see what’s installed without ever having to log in. Auditing with ProGet is simple.
3. Artifacts have no built-in chain-of-custody.
The applications and components developed in-house go through many validation and testing stages before being released to a production environment. Deploying applications built with an artifact mindset is simple enough: just copy the files from the artifact repository to the target server.
But when you look at these artifacts, there’s no way to know where the files came from, who built them, what’s been tested, or even if they are production-ready. Quality, testing, and verification become a guessing game.
In ProGet, at each stage of testing, you can securely “repackage” your packages. Quality, testing, and verification are built right in. Repackaging adds metadata to trace testing, ensuring only production-ready packages make it to production.
4. Artifacts can’t be migrated.
Migration to a new server is common practice but is hard when working with artifacts. Because they’re tied to a server, every artifact on a server must be moved at the same time—and there can be a ton of artifacts on a single server. It’s very possible to lose the link between an artifact and its metadata when migrating servers. If this happens, you’ve lost the data forever.
Migrating to a new server is simple with packages and ProGet. Packages aren’t tethered to a server but are self-contained. As long as your packages are backed up, you have all the data you need for a successful, fuss-free migration.
Here is a visual representation of the major differences between ProGet and JFrog Artifactory:
 |  | |
|---|---|---|
| Supports Packages | |  |
| Supports Artifacts | | |
| Fast Bug Fixes | | |
| Supports Source/Symbol Serving | | |
| Embedded Metadata Manifest | | |
Already using Jfrog Artifactory?
Migrating your packages from Jfrog Artifactory to ProGet is fast and easy. Read our guide on Migrating Artifactory to ProGet to learn more.
