What is a feed in Azure Artifacts, and which package types can a single feed host?

## What a feed actually is A **feed** is the top-level object in Azure Artifacts. Think of it as one private package registry that you own: it stores package versions, decides who may read or publish them, and exposes standard package-manager endpoints so ordinary clients (`dotnet`, `nuget`, `npm`, `pip`, `twine`, `mvn`) can talk to it without knowing anything about Azure DevOps. Two things make a feed different from "a folder of files": it is **protocol-aware** (it understands NuGet's v3 index, npm's registry API, Maven's repository layout, PyPI's simple index) and it is a **permission boundary** — you grant roles on the feed, not on individual packages. ## Multiple protocols, one feed A single feed can hold packages of several types side by side: - **NuGet** — .NET packages (`.nupkg`) - **npm** — JavaScript packages, including scoped names such as `@myorg/utils` - **Maven** — JVM artifacts addressed by groupId/artifactId/version - **Python** — wheels and sdists, uploaded with `twine`, installed with `pip` - **Universal Packages** — an Azure-DevOps-specific format for arbitrary files (a folder of binaries, test data, a toolchain) versioned semantically and pushed with the Azure CLI or the `UniversalPackages` pipeline task Each protocol has its own endpoint hanging off the same feed. For NuGet: ```text https://pkgs.dev.azure.com/{organization}/{project}/_packaging/{feed}/nuget/v3/index.json ``` and for npm: ```text https://pkgs.dev.azure.com/{organization}/{project}/_packaging/{feed}/npm/registry/ ``` The practical consequence is that one feed can be "the place internal packages live" for a whole polyglot team, with one permission model and one retention configuration, instead of a separate registry product per language. What a feed does **not** host is container images. Those go to a container registry (Azure Container Registry or another OCI registry); Azure Artifacts is a package registry, not an image registry. ## Feed scope: organization or project When you create a feed you choose its scope. - An **organization-scoped feed** lives at the organization level and is visible across projects. Its URL has no project segment. - A **project-scoped feed** belongs to one project, appears under that project's Artifacts hub, and inherits the project's visibility. Its URL carries the project segment. Project scoping is the more common default for new feeds because it keeps a feed alongside the team that owns it and lets project-level administration apply. Organization scoping suits a genuinely shared "golden packages" feed. The scope also affects which build identity can reach it, which is why the choice shows up later as a pipeline permission problem rather than as a naming preference. ## Permissions: feed roles Access is granted through four roles, each a superset of the one before: - **Reader** — can list and download packages. - **Collaborator** — can additionally cause packages to be saved into the feed from an upstream source. - **Contributor** — can publish (push) packages and delete or unlist their versions. - **Owner** — full control, including feed settings, retention policies, upstream configuration, and the recycle bin. You assign these to users, Azure DevOps groups, and — importantly for CI — to the pipeline's build service identity. A pipeline that only restores needs Reader; one that publishes needs Contributor. ## Views Every feed is created with three **views**: `@local`, `@prerelease` and `@release`. `@local` is everything the feed holds; the other two are filtered slices you promote versions into so consumers can subscribe to "blessed" versions only. Consumers select a view by putting it in the URL, e.g. `_packaging/{feed}@release/nuget/v3/index.json`. ## Why interviewers ask The question is a scoping check. A candidate who answers "it's where our NuGet packages go" has used it; a candidate who mentions multi-protocol support, feed scope and the role model has actually administered one. The follow-ups almost always move to upstream sources (how public packages get in), authentication from a pipeline (how CI gets access), and retention (what makes packages disappear).