Upstream sources
What it is
Upstream sources let a feed in Azure Artifacts act as a proxy and cache for packages stored in another location — most commonly public registries such as nuget.org, npmjs.com, PyPI, Maven Central, or another Azure Artifacts feed. When a consumer requests a package the feed doesn’t have, the feed pulls it from the upstream, caches a copy, and serves it from then on.
Why it exists
Without upstreams, every build that needs a public package hits the public registry directly — slow, non-reproducible, and open to the internet. Upstreams give teams a single governed endpoint that transparently supplies external dependencies while caching them, so builds are reproducible and more secure.
Key ideas
- Proxy + cache — first request fetches from upstream and stores a copy; subsequent requests are served from the feed.
- Multiple package types — upstreams can be configured per package protocol (NuGet, npm, Maven, Python, etc.).
- Feed-to-feed upstreams — chain org feeds together; a project feed can upstream an org feed, keeping a hierarchy.
- Single identity — consumers authenticate once to the feed rather than to many public registries.
- Security — limits direct egress to public registries and makes dependency resolution auditable through a central place.
How it fits
Exam notes
- Enabling upstream sources caches external packages so builds don’t depend on the public internet being up.
- Upstreams support public registries and other Azure Artifacts feeds (feed-to-feed).
- A package published to the feed with the same ID/version as an upstream package takes precedence and can “shadow” it.
- Upstreams are a core part of a dependency-management strategy for reproducibility and supply-chain control.
Related
azure-artifacts · package-feed · dependency-management · dependency-graph · pipeline-integration
📘 Source: Microsoft Learn — Upstream Sources