DevOpsGroup has joined Sourced, an Amdocs company. Read more about this partnership and what this means for the future in our blog.

DevOpsGroup Blog NuGet-as-a-Service


In a previous post, we mentioned NuGet as great way to package up code for deployment, and that got us thinking about NuGet feeds.

NuGet Overview

In just about every Visual Studio project we create today, we will eventually find a need for a 3rd party library of some kind.

Managing these libraries has traditionally been a cumbersome process. It can be difficult to find available libraries, although Google does a good job, but it’s hard to find the latest version of libraries you’ve used and keep them updated.

That’s when NuGet comes to the rescue. NuGet is a Visual Studio extension that makes it easy to add, remove, and update libraries and tools in Visual Studio projects that use the .NET Framework.

What’s great about NuGet is that we can use it to package our own applications for publishing, which means it becomes a good tool for deployment.

This post won’t cover using NuGet, there’s some great information at, but we are going to explore some options for publishing NuGet packages once they’ve been created.

Public Publishing at

The public NuGet Gallery is the best place to publish if you’re producing a library, component or framework you want others to use. If however, you’ve just developed a bespoke website for a new client this not the place to publish to.

The NuGet Gallery currently boasts more than 10,000 packages and claims over 42 million downloads, so if you have something to share this will be your publishing target.

Publishing to this feed is pretty straight-forward, you need to

  1. Register for an account at
  2. Grab the API Key, located in the “My Account” page. This is generated for you.
  3. Open a command console and run the command: nuget setApiKey Your-API-Key
  4. Confirm you can view your NuGet package in the NuGet Gallery using the search or in the NuGet Package Manager in Visual Studio.

That’s it. There is however a word of caution, and here it is direct from Microsoft; does not support permanent deletion of packages, because that would break anyone who is depending on it remaining available. This is particularly true when using the workflow that restores packages on build.
Instead, supports a way to ‘unlist’ a package, which can be done in the package management page on the web site. When a package is unlisted, it no longer shows up in search and in any package listing, both on and from the NuGet Visual Studio extension (or nuget.exe). However, it remains downloadable by specifying its exact version, which is what allows the Restore workflow to continue working.
If you run into an exceptional situation where you think one of your packages must be deleted, this can be handled manually by the NuGet team. e.g. if there is a copyright infringement issue, or potentially harmful content, that could be a valid reason to delete it.


  1. Easy to setup.
  2. Publicly available.


  1. does not support permanent deletion of packages.
  2. Publicly available without a mechanism to restrict packages.

Hosting your own NuGet Feeds

There are several reasons you may want to host your own NuGet feed, but the most common two are;

  1. You want to restrict access to the packages/libraries that your development team can use. E.g. filter the public NuGet gallery by creating your own.
  2. You want to publish your own packages, but not have them publicly available.

If this is the case, then you’re going to want to consider creating your own NuGet Feed. To do this, you have a couple of options;

1. Shared Folders

Download packages from the NuGet gallery or package your own code with NuGet and then put the packages (.nupkg files) in a shared folder location. Network drives, DropBox or any other document sharing tool are great for this.  Then, simply add the shared folder location to the list of available package sources in NuGet package manager in Visual Studio.

2. Feed Server

Using IIS you can create and host your own internal or remote feed on a server. By adding the NuGet.Server package to an empty website project you enable the site to serve up the package feed using Open Data Protocol (OData).

Once you’ve deployed the site to an IIS server you can then access the oData feed by using a URL. e.g. http://yourdomain/nuget/

Then, simply add the feed server URL to the list of available package sources in NuGet package manager in Visual Studio.

Detailed instructions on both of these methods can be found at Hosting your Own NuGet Feeds.


  1. Allows you to control/protect what packages are in the NuGet feed.
  2. Ensures that packages are not available in the NuGet Gallery
  3. Additional packages can be added and deleted from the feed using NuGet.exe


  1. Requires additional configuration and some development.
  2. Shared network drives will work, but are not ideal.
  3. Only supports one NuGet feed, so all packages are available in one feed.

JetBrains TeamCity as a NuGet Server

In Version 7 of TeamCity, JetBrains added native support for the NuGet Server.

Enabling the NuGet Server is easy. Select the “NuGet Server” option from the “Administration” section and click  the “Enable” button.

Once enabled the NuGet server URL’s will be shown.

The public feed URL is only shown if the “Allow to login as a guest user” setting in “Global Settings” is ticked.

The final step is to add a build step, with a runner type of NuGet Pack. The NuGet Pack build runner allows you to create a NuGet package from a given nuspec file.

Then, simply add the feed server URL to the list of available package sources in NuGet package manager in Visual Studio.


  1. NuGet package creation becomes part of the build process.
  2. NuGet server is integrated into TeamCity. No custom configuration or development is required.
  3. Supports both authenticated and unauthenticated access to the NuGet server allowing for greater control.


  1. Requires TeamCity.
  2. Only supports one NuGet feed, so all packages are available in one feed.
  3. Multiple feeds would require multiple TeamCity instances.


MyGet is a hosted NuGet feed, NuGet-as-a-Service (NaaS). The product has some really nice features, allowing you to create public and private feeds, apply fine-grained user security and also has a range of package management features, such as retention policy.

There is a free plan, but as with all -as-a-service offerings there is a price to pay, ranging from $7 USD/month to $599 USD/year for the Enterprise plan.

We’ve done some basic tests and the product works well. They certainly, consider themselves a SaaS provider, hosting on Windows Azure and making Uptime Status reports available, which is great to see.

What interested us most are two BETA features MyGet are currently running; Build Services and Package Sources.

Build Services

MyGet build services allows you to add packages to your feed by providing Git, Mercurial or Subversion repo details. MyGet servers download the code, build the package, create the package and  publish it.

Currently this service supports Microsoft.NET framework up to Version 4.5 and supports build hooks (commit build triggers) which can be linked to GitHub or BitBucket repositories and will trigger a new build using a HTTP POST.

Package Sources

Package sources are upstream repositories for your MyGet feed. You can aggregate package sources in a single MyGet feed, filter each of them individually, and even proxy upstream package sources to include them in your feed queries.


  1. Supports multiple feeds, so packages can be separated into distinct groups.
  2. Fine-grained security
  3. Hosted solution means you don’t have to set up your own infrastructure
  4. Extended feature set. Features and more in beta.


  1. Private feeds are not free as shown in Pricing Plans.
  2. Unsure of customer uptake.

Inedo ProGet

ProGet is an on-premise NuGet package repository server.

This product has some nice features which include multiple feed support, feed filtering (only in Enterprise), granular security and package caching.

The product has 3 licensing options;

  1. Free, with limited support and some feature limitations.
  2. Enterprise Annual $395 USD/year.
  3. Enterprise Perpetual $995 USD/ 1st year, with additional support at $195 USD /year.


  1. Supports multiple feeds, so packages can be separated into distinct groups.
  2. Fine-grained security
  3. Additional features when compared to the roll-your-own server solution.


  1. Requires additional infrastructure to setup, including SQL Server, but will run using SQL Express.
  2. Feature limitation in free edition, as shown in licensing.

NuGet Summary

We hope that gives you a flavor of the NuGet package hosting solutions available. Each solution has advantages and disadvantages, but our advice would be;

  1. If you’re creating a library to be used by developers in the public domain, choose NuGet Gallery.
  2. If you’re using TeamCity, use the inbuilt NuGet Server. It’s real easy.
  3. The choice between Local Feed Servers, MyGet and Inedo ProGet is a close call, but our winner was MyGet. The beta features,  Build Services and Package Sources made it our choice.

6 thoughts on “NuGet-as-a-Service

  1. Nice post guys. One thing I would add is that, if you are creating a NuGet repository to host packages for Octopus, you may run into performance problems once you accrue a large number of packages, especially if the packages themselves are large.
    One solution which has worked for many people is to use this fork of NuGet which uses Lucene to index the packages:

  2. is jacking up prices. Just got an email from them saying they want almost $4,000 instead of $600 we paid last year. Please beware.

    1. Just wanted to post an update to my previous comment. MyGet is experimenting with a new pricing structure for their Enterprise plan. We seems to have gotten a large renewal bill because of a large number of read-only users, some of them non-developers, who need to be able to pull packages from the feed to build solutions. I want to compliment the guys for listening to and addressing our concerns. Our issue has been resolved, and it looks like are tweaking their Enterprise Plan to make sure people with fringe cases like us aren’t stuck with a large bill.

Leave a Reply

Your email address will not be published. Required fields are marked *