Private NuGet Repository: How to Set One Up in 2026

The public NuGet gallery is great for open-source packages. But the moment you need to distribute proprietary code, internal tooling, or commercial libraries, you need a private NuGet repository.

This guide covers every way to set one up in 2026. It compares self-hosted servers, cloud-hosted feeds, and managed platforms so you can pick the option that fits your team and budget.

1. Why you need a private NuGet repository

A private NuGet repository is a NuGet feed that only authorized users can access. Instead of publishing packages to the public nuget.org gallery, you push them to your own feed and control who can install them.

Teams and companies set up private repositories for a few common reasons:

• Internal shared libraries. You have utilities, data access layers, or framework code that multiple projects depend on. A private feed lets every team install them with dotnet add package instead of copying DLLs or referencing project files across repos.
• Commercial distribution. You sell a .NET library and need to control who can use it. Some vendors publish on nuget.org and enforce access through runtime license key checks. This maximizes discoverability but means your binaries are publicly downloadable, and you need to build and maintain the license validation code. A private feed takes the opposite approach: only paying customers can download the package in the first place. No license key infrastructure required, and your binaries stay private.
• IP protection. Your code contains proprietary algorithms or business logic. Publishing it to nuget.org, even unlisted, means anyone with the URL can download it. A private repository requires authentication.
• Compliance and auditing. Regulated industries need to control which packages enter their build pipeline. A private repository lets you vet, approve, and cache third-party packages before developers use them.

2. Your options at a glance

There are three broad categories of private NuGet repository solutions. Each involves different trade-offs around cost, maintenance, and features.

• Self-hosted means you run the NuGet server on your own infrastructure. Full control, full responsibility.
• Cloud-hosted means you use a NuGet feed feature built into a larger platform (Azure DevOps, GitHub, etc.). Low setup, but limited NuGet-specific features.
• Managed platforms are dedicated package hosting services. More features, less maintenance, but usually a subscription cost.

3. Self-hosted: BaGet and NuGet.Server

BaGet

BaGet is an open-source, lightweight NuGet server written in ASP.NET Core. It is the most popular self-hosted option and supports the full NuGet V3 API. You can back it with SQLite for small teams or PostgreSQL/MySQL for production use.

Pros:

• Free and open-source
• Runs anywhere .NET runs (Linux, Windows, Docker)
• Simple to set up for basic use cases
• Supports package search and autocomplete

Cons:

• No built-in authentication or access control (you need a reverse proxy)
• No web UI for managing packages
• No longer actively maintained (last release was 2021)
• You handle backups, uptime, and scaling

NuGet.Server

NuGet.Server is Microsoft's own lightweight NuGet server. It runs as an ASP.NET application and stores packages on disk. It only supports the older NuGet V2 API, which means no dotnet nuget CLI features that depend on V3.

Pros:

• Official Microsoft project
• Simple file-based storage
• API key authentication for push operations

Cons:

• V2 API only, no V3 support
• Requires .NET Framework (Windows only)
• No per-user access control
• Minimal features compared to modern alternatives

4. Cloud-hosted: Azure Artifacts, GitHub Packages, MyGet

Azure Artifacts

Azure Artifacts is the NuGet feed feature built into Azure DevOps. If your team already uses Azure DevOps for CI/CD, this is the path of least resistance.

Pros:

• Deep Azure DevOps integration (pipelines, permissions, etc.)
• Upstream sources (proxy and cache nuget.org packages)
• Free tier: 2 GB storage included with Azure DevOps

Cons:

• Authentication uses Azure AD or PATs, which can be complex for external users
• Not practical for distributing packages to customers outside your organization
• Pricing scales with storage and users across all of Azure DevOps

GitHub Packages

GitHub Packages lets you host NuGet packages alongside your GitHub repositories. Authentication uses GitHub personal access tokens.

Pros:

• Integrated with GitHub Actions and repository permissions
• Free for public repositories
• Familiar for teams already on GitHub

Cons:

• Consumers need a GitHub account and PAT to restore packages
• No caching of public nuget.org packages (developers use nuget.org directly alongside your private feed)
• Limited package management UI
• Storage and transfer limits on free plans

MyGet

MyGet is a dedicated package hosting service that has been around since 2011. It supports NuGet, npm, and other package formats.

Pros:

• Mature product with a long track record
• Pre-release feed support (push CI builds automatically)
• Upstream source mirroring

Cons:

• Paid plans start at $40/month
• No built-in payment or subscription management
• You manage customer access manually
• UI and feature set have not changed significantly in years

5. Managed platforms: ProGet, Feedz, pkgstore

ProGet (Inedo)

ProGet is an enterprise package management server from Inedo. It supports NuGet, npm, Docker, and many other formats. It can run self-hosted or as a cloud service.

Pros:

• Enterprise features: vulnerability scanning, license detection, retention policies
• Multi-format support (NuGet, npm, Docker, PyPI, etc.)
• Free tier available for small teams

Cons:

• Enterprise pricing for advanced features ($5,000+/year)
• Complex setup for self-hosted deployments
• Designed for internal package management, not commercial distribution

Feedz

Feedz is a lightweight, developer-friendly NuGet hosting service. It focuses on simplicity and integrates well with CI/CD pipelines.

Pros:

• Clean, modern interface
• Simple per-feed access tokens
• Affordable pricing for small teams

Cons:

• No built-in payment processing
• No public-facing product pages for commercial distribution
• Manual credential management for external users

pkgstore

pkgstore is built specifically for distributing private NuGet packages, both for internal teams and for commercial sales. It combines NuGet hosting with Stripe-powered payments and automated credential management.

Pros:

• Push packages with the standard NuGet CLI
• Built-in Stripe payments for commercial distribution
• Automatic credential provisioning: customers pay and immediately get feed access
• Public listing pages for product discovery and SEO
• Subscription support, synced with payment status
• Free access grants for open-source or beta testers

Cons:

• NuGet only (no npm, Docker, or other formats)
• No caching of public nuget.org packages (developers use nuget.org directly alongside your private feed)
• Newer platform compared to established alternatives

6. Feature comparison table

7. Step-by-step setup

Here is how to get a private NuGet feed running with three different approaches.

Option A: Azure Artifacts

Best if your team already uses Azure DevOps.

1. Go to your Azure DevOps project and select Artifacts from the sidebar.

2. Click Create Feed. Give it a name and set visibility to your organization or specific users.

3. Click Connect to Feed and select NuGet.exe or dotnet. Follow the instructions to add the feed URL and credentials to your nuget.config.

4. Push a package:

dotnet nuget push MyPackage.1.0.0.nupkg \
  --source https://pkgs.dev.azure.com/yourorg/_packaging/yourfeed/nuget/v3/index.json \
  --api-key az

Azure Artifacts handles authentication through Azure AD or personal access tokens. Access is managed through Azure DevOps permissions, which makes it straightforward for internal teams but difficult for external customers.

Option B: BaGet (self-hosted)

BaGet is an open-source NuGet server you run on your own infrastructure. Note that the project has not been updated since 2021, so you should only consider it if you specifically need a self-hosted solution and are comfortable maintaining an unmaintained dependency.

1. Create a docker-compose.yml using the BaGet repository as a reference. Configure storage (SQLite or PostgreSQL) and set an API key.

2. Start the server with docker compose up -d.

3. Push a package:

dotnet nuget push MyPackage.1.0.0.nupkg \
  --source http://localhost:5000/v3/index.json \
  --api-key your-secret-api-key

This gives you a working feed, but you still need to configure authentication (via a reverse proxy like nginx or Caddy), set up TLS, and handle backups yourself.

Option C: pkgstore

The fastest way to get a private NuGet feed running. No infrastructure to manage, and if you sell packages commercially, payments and access control are built in.

1. Create a publisher account on pkgstore.

2. Create a product and add a NuGet feed to it.

3. Generate a push key from your publisher dashboard.

4. Push your package:

dotnet nuget push MyPackage.1.0.0.nupkg \
  --source https://www.pkgstore.io/api/nuget/yourname/yourproduct \
  --api-key YOUR_PUSH_KEY

That is it for internal teams. Your colleagues add the feed and start restoring packages immediately.

For commercial distribution, there are a few more steps:

5. Connect your Stripe account and create a product offering with a yearly price.

6. Share your product page. When customers subscribe, they automatically receive NuGet credentials.

7. Customers add your feed:

dotnet nuget add source \
  https://www.pkgstore.io/api/nuget/yourname/yourproduct/index.json \
  --name yourproduct \
  --username [email protected] \
  --password THEIR_CREDENTIAL

No server to maintain, no manual credential management, no payment integration to build. If a customer cancels their subscription, their feed access is automatically revoked.

8. Which option should you pick?

The right choice depends on your use case:

• Most teams: pkgstore. You get a private NuGet feed in minutes with no infrastructure to manage. It works for internal teams sharing libraries and for commercial distribution. If you need to sell packages, it is the only option that handles payments and access control together.
• Already on Azure DevOps or GitHub: Azure Artifacts or GitHub Packages are convenient if your entire team is already on one of these platforms and you do not need to share packages outside your organization.
• Enterprise compliance: ProGet gives you vulnerability scanning, license detection, and retention policies. Worth the price if regulatory requirements demand it.
• Self-hosted requirement: BaGet with Docker, if you specifically need to run a NuGet server on your own infrastructure. Keep in mind that the project has not been updated since 2021, so plan for maintaining it yourself.

Whatever you choose, the important thing is to stop distributing .NET libraries through zip files, shared drives, or email attachments. Your consumers expect dotnet add package. Give them that.