Create your own hosted NuGet server in Azure

By | January 7, 2015

Some time ago I wrote about how you could create your own local (private) NuGet server by simply putting your .nupkg files out on a server share to which you had access. But there’s a better way still!

As more than one of my readers commented, this isn’t optimal as not only does a proper NuGet server serve up packages, it also has indexing and searching optimizations to help it perform more efficiently when you’re looking for and pulling down packages from within Visual Studio.

With that in mind, I set out to see how easy it would be to create a NuGet server for myself in Azure.

The meat to doing this is pretty straightforward and present in the NuGet documentation. The interesting part is doing it in Azure, which is just a hop, skip, and a jump once you’ve got the site all set up in Visual Studio.

Come back when you’ve followed all those instructions.

Welcome back!

Now that you have your NuGet website set up within VS, it’s time to push it to Azure. It really is amazing what they’ve done within VS to make this as painless as possible. I was pretty dumbfounded at first.

Right click your Web Application project and click “Publish…”


Next, choose “Microsoft Azure Websites”


Sign in to your Azure account, and then click New…

Pick something (available) for your site name and choose the Azure Subscription to which to tie it. You don’t need a database, so leave that as “No database”


Click ‘Create’ and VS will talk to Azure and create the website for you, right on the spot.


Once that’s done you’ll move to the next step in the wizard, with everything pre-filled for you (how nice!)


From here you can hit ‘Publish’ and up it goes!


As an added bonus, since Azure Websites gives everybody SSL certs, you get https access to your server as well.

And that’s IT. You have a fully-functional NuGet server that you can push to, pull from, and utilize in your build processes. If you’ve set an API key on it, then only those who know the key can push to it. If you want, you can lock down access to be able to pull using any of the myriad IIS Web Site security methods by simply editing the web.config that’s in the site and re-publishing it. For instance, at my workplace we have done this and set the web.config to allow only IP addresses belonging to the public block assigned to our network. It’s secure enough.

The best part? Run this process again with a different website name and you’ve got a chocolatey server as well!

  • Pingback: Serve up Debug Symbols for your NuGet packages? Heck yeah! | .Netitude | .Net development with an edge()

  • Jensen Somers

    Interesting approach, but how do you make sure the packages are persisted? If a role recycles, you lose the locally stored data, if I’m not mistaken. How do you make sure the packages are still available?

    • I can tell you that I have my nuGet & Chocolatey servers on an Azure *free* website instance and have yet to lose any of the packages. This is (as you can no doubt infer by the timestamp on this post) months after initial spin-up and push of the first package.
      If you’re concerned about this, I would venture to say that you can upgrade it to a Standard instance and you won’t have to worry about the recycling & losing packages. I have another instance that is on Standard and have had no issues there as well.

    • My good buddy @timgabrhel found this on technet ( :
      I want to upload files to my Windows Azure Web Site, what is the best way to do this?

      Files uploaded to the site folder in Windows Azure Web Sites will be stored in persistent storage, and are resilient from process recycling and site reimaging. A better option for storing files is to use Blobs in Windows Azure Storage.