Use packages reliably with upstreams for VSTS feeds

Software packages are a crucial part of development in languages ranging from C# to JavaScript to Python to Go. They help you iterate faster, avoid solving a problem that’s been solved many times before, and allow you to focus on your unique value. But, they can also add uncertainty and risk to your development process. Packages are sometimes removed from the public registries, or those registries are down. Even packages from other teams in your organization can sometimes become unavailable, if the creating team deletes the feed or has a retention policy that cleans up old versions you still rely on.

With the upstream sources features that are now rolling out to all Package Management feeds, you can eliminate these concerns and consolidate all the packages you depend on into one feed.

Upstream sources between VSTS feeds

Upstream sources (for NuGet and npm) are now available between VSTS feeds within the same account, and between feeds in multiple VSTS accounts that are within an organization. With a few clicks, you can add another team’s feed as an upstream source and start using their packages, without altering the NuGet.config or .npmrc in your project.

When you use packages through an upstream source, a few helpful things happen. First, your feed saves a copy of the package that’s retained until you delete it. That means that if the upstream feed goes away, your builds keep running. You can also manage this package just like any other package in your feed. If you want to move your team off an old version of a package from an upstream, you can unlist/deprecate it or delete it. And finally, the saved package also remembers where it comes from and provides a helpful link back to the package in the upstream feed.

A package in the list with the source column highlighted

Upstream sources for public registries

You can also add upstream sources to public registries like and Just like with VSTS feeds as upstream sources, using public registries via upstream sources means VSTS keeps a saved copy of every package you use from the public source.

Getting started with VSTS upstream sources

Setting up a VSTS upstream source is a 2-stage process. First, you’ll need to ensure that the feed you want to add as an upstream source has a view that’s shared. Feeds created in the last few weeks will already have this set up correctly.

If the feed you’re adding is older, have its owner go to feed settings, select the Views pivot, select the view they want to share with you (@local is a great one to start with), click Edit, and select the Shared with my organization radio button and click Save. Learn more about views and upstream sources in the docs.

The configuration panel for adding a view

Then, to add an upstream source, go to feed settings, select the Upstream sources pivot, then select Add.

The configuration panel for adding an upstream source

For more detailed instructions, see the docs.

Getting started with upstream sources to public registries

If you’ve created your feed within the last few months, you’re already set to use the and upstream sources, unless you selected “Only use packages published to this feed” when you created your feed. If you did, or if your feed is older, just go to feed settings, select the Upstream sources pivot, then select Add.

New “Collaborator” permission for feeds

With upstream sources comes a new permissions level: “Collaborator”. In the private preview of upstream sources, we heard from many of you that there’s a different level of trust between “entities allowed to publish my packages to my feed” and “entities allowed to use packages from an upstream I already trust”. If that sounds like you, you’re in luck. “Contributors”, as always, are able to publish packages directly to the feed (e.g. with `npm publish`). “Collaborators” can save new packages from upstream sources (e.g. ‘npm install package-from-upstream’). “Readers” can only use packages that a Collaborator or above has already saved or published to the feed.

What’s next

Over the course of the summer, we expect to add support for other public/non-authenticated NuGet and npm package sources. Upstream sources for Maven packages are on the backlog – help us prioritize by voting on this UserVoice item.

If you’d like to learn more about the concepts behind upstream sources, check out the docs.

We’d love to hear from you about how upstream sources are working for you – just shoot me a tweet @alexmullans or use the blog comments below. If you run into any bugs (we hope not!), log ‘em on Developer Community and we’ll take a look.