Upstream Sources
Upstream sources connect one repository to another, either within your organisation or to an external feed. Use them to share a filtered subset of packages, or to push packages out to a public registry.
Internal upstreams
An internal upstream links a repository to another repository in the same organisation. Packages from the upstream repository appear alongside the packages in the current repository. Access is read-only — upstream packages cannot be deleted or modified through the downstream repository.
When the upstream link is removed, the upstream packages no longer appear in the downstream repository.
Common use case: third-party access
A common use of internal upstreams is to provide a curated subset of packages to a third party:
- Create a new empty repository
- Add an internal upstream pointing to your main repository, filtered to the packages the third party needs
- Create a team with only View packages access to the new repository
- Issue a service account token to the third party scoped to that team
The third party gets a clean feed with only what they need, and can be revoked independently.
Filtering with regular expressions
Upstream packages can be filtered using .NET regex syntax. The filter is applied to the package ID. For example:
| Pattern | Matches |
|---|---|
.+\.Acme\..+ | All packages containing .Acme. anywhere in the ID |
Acme\..+ | All packages whose ID starts with Acme. |
External upstreams
An external upstream creates a link between a Feedz repository and a feed outside of Feedz (for example, nuget.org). Once configured, individual packages can be pushed to that external feed directly from the package details page in the Feedz portal.
Only NuGet feeds are supported as external upstream targets. If a non-NuGet package is selected for push, it will be automatically repackaged before being sent.
