NuGet
NuGet Server Comparison Guide for 2023
So, you set up a local NuGet feed on a network file share for your team small. But as you and the team add more and more packages to your feed, things start slowing down. It’s also a bit inconvenient to use a network share when everything is web-based, especially over a VPN.
Local NuGet feeds are simple: it’s just a file share! While they work great at the start, eventually you need to move to a private NuGet server. But which one? There are LOTS of options for teams looking to set up their own private NuGet server, which is part of the challenge in migrating. Surely you don’t need anything too fancy, just something a “little better…” right?
The simplest choice is to go with ProGet. It’s free, easy to install, and has all the features you’ll ever need. But it’s not the only option. In fact, there are five types of NuGet servers out there:
- NuGet.Server-based
- Community/Hobby Projects
- Package Hosting Services
- Built-in Feeds
- Enterprise-Grade Servers
In this article, I’ll explain each of these types, and how to decide what server is right for you and your team.
What can a Private NuGet Server do?
Before you dive deep into the five types of servers available, it’s important to consider features your team might want or need. All NuGet servers can do a whole lot more than a basic local feed:
- Restricted feeds; allow administrators to control who can view, publish or promote packages
- Proxy/Mirror NuGet.org; sit between your team and NuGet.org (and other sources) to act as a sort of proxy or mirror
- Open-source Package Verification; automatically scans and block packages that have vulnerabilities or unwanted licenses
- Host Non-NuGet Packages; as your team expands beyond .NET, you may have a need for packages like npm/nodejs
- Package promotion; integrated workflows that help standardize the package review/approval process, and your software development lifecycle.
Keep these features in mind as you browse for a private NuGet server and consider what features you can and cannot compromise on before fully implementing a new server.
Type 1: NuGet.Server-based Servers
Many teams may initially lean towards using NuGet.Server as a replacement for their local feed. It’s a NuGet package that you can use to build a Web application that hosts a simple NuGet feed. It’s a small step up from a local feed.
Microsoft has clear documentation on how to build and set up a server, and there are many community posts to help if you get stuck. You can even also purchase a pre-built server from NuGetServer.net for a few dollars to save you the trouble of creating it yourself.
⚠ NuGet.Server Isn’t Recommended
Given the many free alternatives available now, I don’t recommend using NuGet.Server anymore. There are just too many limitations, and it has none of the features that other NuGet servers have.
The biggest limitation is the lack of restricted feeds. At best, you can set up a feed to be read-only. A restricted feed is important since it lets an administrator control who can view, publish, etc. to a feed. Being able to restrict a feed is a basic feature that helps manage teams and the quality of packages in their feeds as they grow.
Type 2: Community/Hobby Projects
Community/Hobby Project servers are open-source, still-under-construction private feeds available for anyone to use. Community projects come with the benefit of, well, a community. What I mean is you can easily check the project’s GitHub, contribute to it if you’d like, search past posts from community members to help with troubleshooting, or learn how others optimized the server’s functions.
These options are usually just a side-project of a group or individual, however, so no commercial support is available. We recommend these options for individuals or small teams.
| ✔ Sleet | a “simple static NuGet package feed generator,” Sleet is serverless which means you can create feeds directly on AWS for example. However, it’s static, which means it’s read-only and you can’t publish packages to it. |
| BaGet ⚠ Inactive | pronounced just like the bread, is “a lightweight NuGet and Symbol Server” that is still actively maintained with continued features/improvements, and is our recommended community/hobby project. However, it appears no longer updated with the last notable update in April, 2023. |
| LiGet ⚠ Inactive | a “NuGet server created with a Linux-first approach,” LiGet is a fork of BaGet that started with good intentions. However, it’s no longer actively developed – likely because BaGet has caught up, and works on Linux with dotnet Core. |
| Klondike ⚠ Inactive | lightweight and performs better than the standard NuGet.Server, Klondike is easier to set up, and has the ability to “automatically restore packages sourced from 3rd party feeds, such as the nuget.org public feed.” However, the last commit was in 2016 and it’s no longer updated. |
| SlimGet ⚠ Inactive | a “lightweight implementation of a NuGet and symbol server, powered by ASP.NET Core 2.2, designed to be ran in Docker”. Currently appears no longer updated, with the last commit made in 2020. |
While none of the projects support restricted feeds, both BaGet and Klondike support NuGet.org proxy/mirroring, which allows the servers to “stand in front of” nuget.org, mirroring the site to get 100% of the NuGet packages you need with 0% direct contact with the site.
However, community/hobby projects are not really designed for anything more than storing your in-house packages. As you use more open-source packages from NuGet.org, you’ll notice a major feature missing: integrated license and vulnerability scanning – a necessary feature for many teams looking to work with public packages built by someone else.
Ignoring this and using the wrong license could lead to serious legal trouble. Likewise, vulnerabilities are an inevitability when working with third-party packages. Having an integrated automated scanning solution can save you time and prevents headaches from an unintentional vulnerability making it to production.
Type 3: Package Hosting Services
True to its name, these are the service options that host packages, a.k.a “Packages as a Service.” Unlike the first two types of NuGet servers, these are fully managed by the hosting service, which means it’s really easy to sign-up and get started.
There are currently only three services that provide NuGet hosting:
| MyGet | a hosted universal package registry that “integrates with your existing source code ecosystem and enables end-to-end package management.” They also offer Build Services, which is continuous integration for your packages. |
| Cloudsmith | a “cloud-native, hosted, package management service” that helps you “manage, trace and control the software used within your development and deployment pipelines, or when you distribute it to your customers.” |
| Feedz.io | a “Package Hosting and Distribution that lets you “Store and distribute your private NuGet and npm packages with no user limit and transparent pricing” |
Both MyGet and Cloudsmith provide support for NuGet.org Proxy/Mirroring which allows your hosted feed to “stand in of” nuget.org so that you can combine third-party, open-source packages with our own. And more importantly, they support automated vulnerability and license scanning for those third-party, free, and open-source packages.
They also have some other important features: restricted feeds and the ability to host non-NuGet packages.
While package hosting services are the easiest to get started with, they often aren’t an ideal choice for scaling teams or large enterprises.
First and foremost, your packages are stored on the cloud, which may not be appropriate for the type of code you create. In addition, as a cloud service, the cost depends on how much you use, so pricing can be confusing and unpredictable.
Type 4: Built-in Package Registries
A “Built-in Package Registry” is a feed that is built into another tool — generally a “monolithic platform” — and tightly integrated with the projects you build there. Monolithic platforms are the “all-in-one” tools/services that handle everything from project management to issue tracking to build automation to deployment.
Since a built-in feed is a feature of another tool, it’s like a pair of scissors on a Swiss army knife: convenient, but not suitable for every situation. And unlike Swiss army knives, the package registry feature (along with most of the other features in the platform) was an afterthought, and often feels immature and bolted on.
There are currently five built-in package NuGet package registries out there:
These tools are powerful, but their focus is not on packages. They’re complex and expensive — and unless you’re already using them, they’re not worth it for packages alone. In fact, many organizations using these monolithic tools have found the built-in feed to be too complex and not robust enough — so they end up with another option, anyways.
One of the major reasons: monoliths are focused on building your software, and don’t really take into consideration that developers will be accessing and using open-source packages from NuGet.org. Most do not support NuGet.org Proxy/Mirroring, let alone open-source package validation.
Type 5: Enterprise-Grade Repositories
Designed to be the home of all your software assets, packages, and Docker containers, this type of NuGet server has a ton of features surrounding package management, including high availability and replication across servers.
There are enterprise repositories on the market – Artifactory, Nexus, and ProGet – and they all have both free and paid versions available. But when it comes to hosting NuGet feeds, ProGet is hands-down the best option. And I’m not just saying that because I work for Inedo.
ProGet was always designed around NuGet. Take Source and Symbol Serving for example — debugging with symbol and source serving is a must-have feature when developing your own packages. ProGet has always supported Source and Symbol Serving for NuGet since day one, right out of the box. Artifactory also support symbol server, however this is still relatively new, only just being introduced to the service in August 2022 despite it being one of the top-requested features for 8 years. It also only supports the latest symbol server format, whereas ProGet additionally supports legacy formats such as .symbols.nuget and Microsoft PDB.
ProGet also has great features built around developing NuGet packages using CI/CD pipelines, tracking which applications are using which packages, and creating a package review process.
Don’t get me wrong — Artifactory and Nexus are fine tools — but if you’re looking for NuGet, there’s really no competition here.
So why not just immediately jump into ProGet? While it’s free and easy to install, it has a lot more features than most teams are looking for right now. That can intimidate some, but if you’re like me — it’s hard to not use a feature if I see it. And that means building processes around these new features takes time and effort.
There’s also the question of server requirements – all of the enterprise-grade repositories require a bit more server resources than a basic NuGet.Server feed… but they will scale much better when you need them.
