Scott Hanselman

How to host your own NuGet Server and Package Feed

April 13, 2016 Comment on this post [39] Posted in NuGet | NUnit
Sponsored By

Local NuGet FeedHosting your own NuGet Server, particularly when you're a company or even a small workgroup is a super useful thing. It's a great way to ensure that the build artifacts of each team are NuGet Packages and that other teams are consuming those packages, rather than loose DLLs.

A lot of folks (myself included a minute ago) don't realize that Visual Studio Team Services also offers private NuGet Feeds for your team so that's pretty sweet. But I wanted to try out was setting up my own quick NuGet Server. I could put it on a web server in my closet or up in Azure.

From the NuGet site:

There are several third-party NuGet Servers available that make remote private feeds easy to configure and set-up, including Visual Studio Team Services, MyGet, Inedo's ProGet, JFrog's Artifactory, NuGet Server, and Sonatype's Nexus. See An Overview of the NuGet Ecosystem to learn more about these options.

File Shares or Directories as NuGet Server

Starting with NuGet 3.3 you can just use a local folder and it can host a hierarchical NuGet feed. So I head out to the command line, and first make sure NuGet is up to date.

C:\Users\scott\Desktop>nuget update -self
Checking for updates from
Currently running NuGet.exe 3.3.0.
NuGet.exe is up to date.

Then I'll make a folder for my "local server" and then go there and run "nuget init source dest" where "source" is a folder I have full of *.nupkg" files.

This command adds all the packages from a flat folder of nupkgs to the destination package source in a hierarchical layout as described below. The following layout has significant performance benefits, when performing a restore or an update against your package source, compared to a folder of nupkg files.

There's two ways to run a "remote feed" handled by a Web Server, rather than a "local feed" that's just a file folder or file share. You can use NuGet.Server *or* run your own internal copy of the NuGet Gallery. The gallery is nice for large multi-user setups or enterprises. For small teams or just yourself and your CI (continuous integration) systems, use NuGet.Server.

Making a simple Web-based NuGet.Server

From Visual Studio, make an empty ASP.NET Web Application using the ASP.NET 4.x Empty template.

New Empty ASP.NET Project

Then, go to References | Manage NuGet Packages and find NuGet.Server and install it. You'll get all the the dependencies you need and your Empty Project will fill up! If you see a warning about overwriting web.config, you DO want the remote web.config so overwrite your local one.

Nuget install NuGet.Server

Next, go into your Web.config and note the packagesPath that you can set. I used C:\LocalNuGet. Run the app and you'll have a NuGet Server!

You are running NuGet.Server v2.10.0

Since my NuGet.Server is pulling from C:\LocalNuGet, as mentioned before I can take a folder filled with NuPkg files (flat) and import them with:

nuget init c:\source c:\localnuget

I can also set an API key in the web.config (or have none if I want to live dangerously) and then have my automated build push NuGet packages into my server like this:

nuget push {package file} -s http://localhost:51217/nuget {apikey}

Again, as a reminder, while you can totally do this and it's great for some enterprises, there are lots of hosted NuGet servers out there. MyGet runs on Azure, for example, and VSO/TFS also supports creating and hosting NuGet feeds.

Aside: Some folks have said that they tried NuGet.Server (again, that's the small server, not the full gallery) a few years ago and found it didn't scale or it was slow. This new version uses the Expanded Folder Format and adds significant caching, so if you've only see the "folder full of flat nupkg files" version, then you should try out this new one! It's version 2.10+. How much faster is it? First request to /nuget (cold start, no metadata cache) before was 75.266 sec and after is 8.482 sec!

The main point is that if you've got an automated build system then you really should be creating NuGet packages and publishing them to a feed. If you're consuming another group's assemblies, you should be consuming versioned packages from their feeds. Each org makes packages and they flow through the org via a NuGet server.

Important! If you are using a Network Share with NuGet.Server, make sure you have the newest version because this file folder structure can give you MAJOR performance improvements!

How do YOU handle NuGet in YOUR organization? Do you have a NuGet server, and if so, which one?

Sponsor: Big thanks to RedGate and my friends on ANTS for sponsoring the feed this week!

How can you find & fix your slowest .NET code? Boost the performance of your .NET application with the ANTS Performance Profiler. Find your bottleneck fast with performance data for code & queries. Try it free

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Hosting By
Hosted in an Azure App Service
April 13, 2016 6:25
Been quite happy with Klondike (, but our choice in going that route was mostly due to Nuget.Server's awful performance. On our roadmap is moving off of Klondike and back to Nuget.Server once we evaluate the performance. Hopefully Nuget.Server will also get proxy support for local caching of our packages too.
April 13, 2016 6:28
I setup a ProGet server for our development team. Works great but I'm not going to lie the trickery I had to go through getting a CI process setup for it was challenging to say the least (TFS/MSBuild not ProGet). It has been great establishing this culture of reusable components to share across teams in our department.
April 13, 2016 6:36
Philip - Klondike looks cool! I'll check it out!
April 13, 2016 6:57
Is this just a packaged version of We are running a fork of the github project at work and I wonder if there is any benefit to running this version instead.
April 13, 2016 8:54
Nice article Scott !!
April 13, 2016 9:20
We have our nuget feed in Octopus, which is our choice of deployment tool.
April 13, 2016 9:33
We're using NuGet.Lucene, which is the base part of Klondike. We're using it because of the performance and the build-in symbol server.
April 13, 2016 9:45
Since 2014, We've gone exactly down the Empty project + NuGet.Server route. It's working well for us.

Shortly after we set that up, we set up a private symbol server also, using the SymbolSource.Server.Basic package inside another empty project.

We found we had issues trying to just use a single NuGet.Server host for both "normal" packages and symbol packages, since the server would accept both uploads but would then fall over when someone requested a package and it found it had two packages with the same name. (Plus the SymbolSource server actually unpacks the symbol packages and VS can retrieve symbols from it even when it's not aware that the DLLs originated from a NuGet package)
April 13, 2016 10:01
We've been using this approach (local folder on a local server) for a few years. It's a problem when we want to run builds in VSTS, since we've got a self issued SSL certificate on our NuGet server. We cannot install our certificate on the hosted build server, so we've started synching our local NuGet feed to the VSTS hosted NuGet feed. It would be great to have a VSTS hosted NuGet as fast as our own local server.
April 13, 2016 10:20
We use ProGet here - works fine as a NuGet-feed incl. a proxy for (we only use the ProGet feed in our projects and ProGet proxies requests to if it's not a "local package") and as a symbol server.
The tricky part for us was also getting MSBuild to create and deploy the packages during build - I ended up writing a small tool which is called in the post-build event which calls all the needed nuget pack/push commands and is configured via MSBuild parameters, because we also need to do some "version trickery" as our internal versioning schema is not directly compatible with NuGet's semver format.
April 13, 2016 10:27
We tried to set up a NuGet gallery ( to allow teams to publish their packages for internal use, but this was more complicated than we had expected, and we did not have time to bring it to life (it was a side project). It was over a year ago, and from what I remember, setting up a feed was rather simple. Unfortunately, the feed is not enough for cross-enterprise code reuse. To get most of internal NuGet, you'd need to set up the check-in policy, manage the UI, etc, so this is where the gallery comes handy, and we spent several weeks (like lunch time and extra hours here and there), trying to make it work. We made some progress, though, but not enough for actually making it work. I hope that some day we get back to it, and finish implementing the gallery with less effort.
April 13, 2016 12:05
Do NuGet.Server and/or TFS allow the hosting of symbol files? At the moment, we're using the free version of Inedo's ProGet because they provide the possibility to host the symbol packages.
April 13, 2016 13:08
We use TeamCity which has a NuGet Server option that will provide access to the NuGet Packages(which are build artifacts)

There are various NuGet build steps available like 'NuGet Pack' and 'NuGet Installer' which produces the NuGet Packages and can restore packages from different NuGet sources: the public NuGet feed( but also your own local TeamCity NuGet feed(%teamcity.nuget.feed.server%).
April 13, 2016 15:00
I used ProGet as a NuGet server AND Symbol Server. Nupkg are build within the MSBuild process(with a good PowerShell). The PowerShell update the nupkg version and if it's not from the master branch in git, then publish a pre-release version. The Symbol server Is really neat to debug our packages.

April 13, 2016 15:27
+1 for TeamCity's Nuget Server and the built in Nuget artifact support. Works a treat.
April 13, 2016 16:14
We tried the NuGet.Server package for a little while, but it was horribly slow when you had more than 100 packages/versions. This was back in the days of NuGet v2 though, so not sure if it's any faster in v3.

We're using MyGet now. It's working pretty well and we have a tonne of packages. Occasionally requests will fail, but probably no more failure rate than npm ;)
April 13, 2016 17:11
Having dealt with an internal ProGet server used for hosting a few local packages and otherwise being a proxy for the main Nuget feed, I'm afraid my experience was far from positive. Nuget seems to be slow at the best of times, and adding ProGet to the mix just made things even worse. This wasn't helped by the fact that our product probably wasn't complex enough to justify its being split into multiple packages in the first place.
April 13, 2016 20:24
We experimented with this previously using TeamCity but found it difficult to manage. VS's continued second-class support for NuGet certainly doesn't help. Whatever happened to making packages and DLLs both appear in a project's references list? Why is the NuGet pane still so slow and buggy? Why does the ASP .NET team push using alternative package managers instead of improving and consolidating around NuGet?

For now, it's much easier to add the projects you need to your solution and use project references.
April 13, 2016 22:41
+1 for ProGet. We run an instance at the Community level. It's hosted on an Azure VM that also doubles as our Jenkins server.

I don't recommend using ProGet as a proxy for the standard feeds. I've found several packages that simply don't show up through the proxy. I don't have any filtering on the feed (that I know of), but I also don't have the time to dig through the settings to see if I've done something wrong. But other than that, I'm extremely happy with it!
April 13, 2016 23:49
Philip Scott - I looked into this and there's been some VERY significant perf improvement in NuGet.Server. It's much much better (like near 10x) but you're right it won't search like Lucene. I think NuGet.Server is great for small groups.

Richard - I updated the post. The new NuGet.Server is WAY faster with v3.

Damian - Good catch. They fixed that in 2.10 by rejecting symbol-only packages. They also don't push symbol packages by default.
April 14, 2016 1:23
When we started NuGet, we created our own TFS Xaml template that packed and pushed packages to a 'poor mans package source' (shated folder). Having a lot of packages and a lot of versions of that packages, the folder got to a size that listing or installing packages from that source got very slow.
We improved our process in several step, which results in the following mechanism: We now have a MsBuild task that packs a NuGet package after every release build. On the build server, the Xaml template pushes every package that it can find for the project that has just been build (of cause only at check-in time / gated check-in) to our new ProGet server (free).
April 16, 2016 3:55
We just started hosting our internal NuGet feeds with TeamCity. For those that are using TeamCity, how do you handle versioning? Do you just manually change the production build configuration version when you're ready to release a library for production use? Or is there a better way to automate it?
April 16, 2016 8:40
How would you debug release a release compiled package (the dlls)?
April 16, 2016 12:07
Can I use ASP .NET Core to make the web based server?
Thank you
April 18, 2016 11:20
Is there a way to get the latest nuget package when building a project in Visual Studio 2015?
April 19, 2016 19:02

Never heard of NuGet Server and I guess you have shared a wonderful information about it

April 19, 2016 22:56
Anxiously awaiting a docker image that does this...
April 20, 2016 9:47
If you're interested, I wanted to extend the same experience for delivering custom Visual Studio extensions that your team might develop. So taking the NuGet Gallery as a fork I added support for the custom Atom feed VS requires and flowed extensions from it. This means you could use your NuGet workflows when building extensions too 😊
April 20, 2016 14:42
We started using Myget and so far we're happy with it - it's very easy to manage the packages including deleting a package or a particular version of a package, manage permissions, etc.
April 20, 2016 18:03
I've used both a directory-based and NuGet.Server
Pros and Cons of the directory-based:
Pros: You can set it up and have it running in seconds. LDAP-based security over the package repository.
Cons: Package indexing becomes extremely slow after packages start to pile on - roughly after 50.

Pros and Cons of the NuGet.Server:
Pros: a lot of control and high performance over every aspect of NuGet package hosting
Cons: When we used it, we were given a VM which was neglected (was shut down and not restarted automatically) and finally the VM became FUBAR so we had to opt out for the directory-based hosting.

Private NuGet feeds are a thing of beauty though - you can have digital content distribution for paying customers of your organization and its products.
April 21, 2016 7:00
I know that NuGet will look for the nuget.config in multiple places but does NuGet allow for an ordering of resolving depdendencies?

1) Look to a local folder (while developing) (pulled from %APPDATA%/Nuget/nuget.config)
2) Look to team NuGet server (From projects nuget.conf)
3) Look to public NuGet server (From projects nuget.confg)

April 30, 2016 14:29
Nice article thanks for sharing this article with us.
April 30, 2016 14:31
How Did you get an such idealistic information to express inn your postings.
May 02, 2016 2:01
really nice article.i follow your website every day.thank you
May 02, 2016 10:01
We used VSTS nuget feed which works great. Only thing missing is having a private symbolserver.
May 02, 2016 11:14
How did you get such a good information to post in your blog.
May 02, 2016 11:14
How did you get such a good information to post in your blog.
May 02, 2016 11:17
Nice and cool continue the postings.we are waiting for your posts to read.
May 13, 2016 17:19
To know the list of deep web links and what happens in the hidden internet.....
just click here ....Deep web links

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.