How to Easily Set Up a Private NuGet Server for Your NuGet Packages for Free
When you store your NuGet packages on a public third-party platform like NuGet you are choosing convenience while sacrificing three critical elements:
When a third party owns and curates your packages, your team’s unrestricted package access can introduce major problems to your code. And the third-party NuGet Gallery cannot keep your private packages private.
While setting a basic NuGet server (like NuGet.Server) is possible, it’s almost useless for larger teams/IT organizations since it only supports a single feed.
Below I’ll outline how to set up your own private NuGet server using ProGet for free that allows multiple feeds, enables managers to control access, caches locally, and much more.
Set Up Your Private NuGet Server: Free, Fast, Easy
Step 1: Install ProGet
Download ProGet, which will install the lightweight Inedo Hub. Depending on your Internet connection, you can have ProGet installed in as little as two minutes. Don’t have a license key? Let ProGet know when you install it, and you’ll be prompted to create one after installation. And don’t worry about extra costs: you can create as many NuGet feeds as you want in the free-forever version of ProGet.
Step 2: Create a “Private” Feed
Navigate to “Feeds” and add a new feed. Name it and select “Private.” Once you click, “Create Feed,” you can upload your scripts to your heart’s content.
That’s it! Take things to the next level by configuring security and access controls, vulnerability scanning, and more—all designed to keep your .NET5+ packages are both safe and accessible.
Why Set Up a Private NuGet Server
Private NuGet server solutions like ProGet help you keep proprietary NuGet packages both private and easily accessible for internal use. ProGet provides a single home for all feeds, while still keeping them separate, and its access controls add extra security.
The list of benefits that come with having your own private NuGet server is long. You can read more about it here. But I’ll quickly review some of the most important highlights here:
Keeping your proprietary production-ready and -unready packages totally separate help you stay organized and avoid human error introducing problems in Production. ProGet offers different NuGet feed types to indicate package quality:
• Public (for third-party, production-unready packages)
• Private (for first-party packages)
• Validated (for approved, production-ready packages)
When developers go to the NuGet Gallery and find a creative solution to solve a specific problem, they can inadvertently introduce new problems. Assign permissions to add security and reduce risk.
Feed-level privilege controls in ProGet give granular control over development assets. Plus, integrate with AD/LDAP to use existing teams and roles to define per-feed permissions.
ProGet can act as your NuGet proxy and get developers the packages they need while following organizational rules for security and privacy by letting management filter out unacceptable packages. ProGet can “stand in front of” NuGet as your proxy to get 100% of the NuGet packages you need with 0% direct contact with the site.
Package Promotion & Repackaging
Promoting a package in ProGet copies a package between feeds in just three clicks. And a package promotion pipeline restricts the ‘promote to’ feed, adding an extra layer of privilege controls.
Using ProGet, you can also further indicate production-ready packages while keeping packages immutable with repackaging. Once a package has passed pre-release testing, ProGet lets you easily repackage it as release-quality—so that exactly what was tested goes to production.
Setting up your own private NuGet server for your NuGet packages is easy and free with ProGet. I only mentioned a few in this article, but the list of reasons to use ProGet as your private repository is long:
- Control access
- Increased security
- Increased quality control
- Vulnerability scanning
- License detection and blocking
- Deployment records
While the list of reasons to keep your packages public and stick with using NuGet.org is quite short:
- It’s convenient
Having a private NuGet server for your IT organization is the first step in solving (or preventing) your .NET development frustrations.