skip to content

Artifacts & Package Feeds

1 roadmap6 questions

Azure Artifacts as the private package registry, with upstream sources for public packages and views used to promote a package from prerelease to release. Asked when a shop publishes internal libraries and needs a supply-chain story.

on this pageshow

explore

questions

6

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

level: juniorimportance: must knowfreq 60%

answer

  1. private registry inside Azure DevOps
  2. one feed, several package protocols
  3. org-scoped or project-scoped
  4. Reader, Collaborator, Contributor, Owner
  5. no container images here

basics

~20 s

An Azure Artifacts feed is a private package registry hosted inside an Azure DevOps organization or project. One feed can hold NuGet, npm, Maven, Python and Universal Packages together, each reached through its own protocol endpoint URL.

solid answer

~40 s

A feed is Azure Artifacts' unit of storage and permission: a private registry that lives in an Azure DevOps organization, or scoped to a single project inside it. The same feed serves several protocols at once — NuGet, npm, Maven, Python (PyPI) and Azure DevOps' own Universal Packages — so a polyglot shop does not need one registry product per language. Each protocol gets its own endpoint on the same feed, for example `https://pkgs.dev.azure.com/{org}/{project}/_packaging/{feed}/nuget/v3/index.json` for NuGet and a `/npm/registry/` path for npm; you point `nuget.config` or `.npmrc` at that URL. Access is governed by feed roles — Reader, Collaborator, Contributor, Owner — rather than by repository permissions. A feed does not host container images; those belong in a container registry.

go deeper

for a junior

Be able to say plainly that a feed is a private package registry in Azure DevOps, name two or three protocols it serves, and describe pointing nuget.config or .npmrc at its URL.

for a middle

Explain the difference between organization-scoped and project-scoped feeds, walk through the four feed roles and which one a restoring versus publishing pipeline needs, and know that views exist.

for a senior

Expect to justify how many feeds an organization should run and where the boundary sits, and to diagnose access failures by reasoning about feed scope plus the identity that is actually making the request.

for a principal

Own the wider question: which artifact types belong in Azure Artifacts versus a container registry or object storage, and what a single shared feed costs in blast radius and permission review compared with per-team feeds.

## 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).

  • Where do container images go if not into an Azure Artifacts feed?
    Into a container registry — Azure Container Registry or any other OCI-compliant registry. Azure Artifacts speaks package-manager protocols (NuGet, npm, Maven, PyPI, Universal Packages), not the OCI distribution API, so images are stored and tagged elsewhere and referenced by tag or digest from the pipeline.
  • What is a Universal Package good for that a NuGet or npm package is not?
    Arbitrary file payloads that no language ecosystem owns: a compiled toolchain, a large test-data corpus, firmware, signed binaries. You push and pull them by name and semantic version with the Azure CLI or the UniversalPackages pipeline task, getting versioning and retention without pretending the payload is a language package.
  • How does a developer's machine authenticate to a feed for a plain npm install?
    By putting credentials in the user-level client config — an .npmrc entry with a token for the feed host, or for NuGet the Azure Artifacts credential provider, which prompts a browser sign-in and caches a token. The Connect to feed dialog in the Artifacts hub generates the exact snippet per protocol.

saying these in an interview costs you the question

  • Thinking a feed can store Docker container images
  • Assuming one feed per package type is required
  • Confusing feed roles with project or repository permissions
  • Believing feeds are always public inside the organization
  • Calling the feed a build artifact store for pipeline logs and binaries

context

resolving links…

open as a page

An Azure Pipelines job fails with 401 Unauthorized while restoring from an Azure Artifacts feed in the same organization. How does a pipeline authenticate to a feed, and what would you check?

level: middleimportance: must knowfreq 50%

basics

~20 s

A pipeline authenticates as its build service identity, and an authentication task injects that identity's token into the package client's config. A 401 usually means the build service identity holds no role on the feed, or the job's authorization scope cannot reach a feed in another project.

open as a page

In Azure Artifacts, what does an upstream source on a feed do the first time a build restores a package the feed does not already hold?

level: middleimportance: should knowfreq 55%

basics

~20 s

The feed fetches that package version from the upstream registry, saves a copy into the feed itself, and serves the saved copy on every later request. Public packages and internal ones then come from one URL, and the copy survives if upstream removes the original.

open as a page

What are the @local, @prerelease and @release views on an Azure Artifacts feed, and what changes when you promote a package version to a view?

level: middleimportance: should knowfreq 45%

basics

~20 s

Views are filtered, read-only slices of one Azure Artifacts feed. @local shows everything the feed holds; @prerelease and @release show only versions you promote into them. Promotion copies no bytes — it just makes a version visible at the view's URL.

open as a page

Your team publishes an internal npm package to an Azure Artifacts feed that also has npmjs.com configured as an upstream source. How can a build still end up installing a public package of the same name, and what prevents it?

level: seniorimportance: should knowfreq 38%

basics

~20 s

Resolution is per version, not per name: if a client asks for a version your feed does not hold, the feed will fetch it from the public upstream. A floating range plus a higher public version is the opening. Scoped names, exact pinning and a single configured source close it.

open as a page

A rebuild of an old release fails because a package version is no longer in your Azure Artifacts feed, though nobody deleted it by hand. What in the feed's configuration explains this, and how do you recover?

level: seniorimportance: nice to knowfreq 28%

basics

~20 s

The feed's retention policy pruned it. Retention keeps a maximum number of versions per package and spares recently downloaded ones, so a version an old release pins can age out. Recover it from the feed's recycle bin, then promote versions you must keep to a view.

open as a page