Manage packages with feed permissions

Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 | TFS 2017

The packages you host in Azure Artifacts are stored in a feed. Setting permissions on the feed allows you to share your packages with as many or as few people as your scenario requires.

Feed permissions overview

Feeds have four levels of access: Owners, Contributors, Collaborators, and Readers. Owners can add any type of identity-individuals, teams, and groups-to any access level.

Permission Reader Collaborator Contributor Owner
List, install, and restore packages
Push packages
Unlist/deprecate packages
Delete/unpublish package
Promote a package to a view
Add/remove upstream sources
Save packages from upstream sources
Edit feed permissions
Allow external package versions

By default, the Project Collection Build Service is a Contributor and your project team is a Reader.


To access a feed in a different organization, a user must be given access to the project hosting that feed.

Azure Artifacts settings

Azure Artifacts settings allow you to specify who can create and administer feeds.

Azure Artifacts settings button

By default, everyone in the same organization have the permissions to create feeds. A user who creates a feed is both an owner and an administrator of that feed.

Azure Artifacts settings

  1. Any user in the organization is allowed to create feeds.

  2. Only feed administrators and users or groups specified in the text box 2 are allowed to create feeds. You can specify a feed administrator by adding users or groups in the who can administer feeds section.

  3. Users or groups added here are allowed to administer any feed in the organization.


It's very important to understand the difference between feed, project, and project collection administrators. A feed administrator can perform all operations on the feed (edit feed permissions, delete packages, promote packages, etc.).
A project administrator on the other hand has permissions to administer all aspects of teams and project (delete team project, update project visibility, manage test environments etc.).
Project Collection Administrators are granted all collection-level permissions to manage resources for projects and project collections (add and delete projects, trigger events, manage build resources and audit streams etc.).

Adding users/groups permissions to a feed

Editing permissions for a feed

With your feed selected, select the gear icon (on the right side of the page).

Screenshot of the Edit feed button.

Screenshot of the Edit feed button.

Select Permissions.

Editing a feed's permissions devops 2019 and above

Select Add users/groups.

Adding users or groups

Add users and/or groups and choose their access role.

Adding users or groups dialogue

When you're done, select Save.

Editing a feed's permissions TFS 2017 and 2018

In the edit feed dialog:

  • Choose to make each person or team an Owner, Contributor, Collaborator, or Reader.
  • When you're done, select Save.

Understanding feeds and views permissions

Feeds are containers that allow users to group packages and control who can access them by modifying the feed permissions.

A feed view on the other hand is a way to enable users to share some packages while keeping others private. A common scenario for using a feed view is when a team shares a package version that has already been tested and validated but keeps packages that are still under development from being viewed.

By default, there are 3 views in a feed: @local, @prerelease, and @release. The latter two are suggested views that you can rename or delete as desired.

The @local view is the default view and it includes all the packages that were published directly to the feed as well as all the packages that were saved from the upstream sources.


If a user have permission to a specific view, and even if they don't have permission to the feed, they will still be able to access and download packages through that view. If you want to completely hide your packages, you must restrict both feeds and views permissions.

To restrict access to your feed, simply select a user or group from the permission table in your Feed Settings and select Delete. You can restrict access to a view by changing its visibility to specific people as shown below.

changing visibility to specific people

After restricting your view's visibility to specific people, the access permissions column should reflect your changes.

views settings


A very important concept to keep in mind is that views inherit their permissions from their parent feed. Setting view permissions to Specific people without specifying users or groups will cause the view permissions to default back to their parent feed permissions.

Package permissions in Azure Pipelines

To use packages from a feed in Azure Pipelines, the appropriate build identity must have permission to your feed. By default, the Project Collection Build Service is a Contributor. If you've changed your builds to run at project scope, you'll need to add the project-level build identity as a Reader or Contributor, as desired. The project-level build identity is named as follows:

[Project name] Build Service ([Organization name]) (e.g. FabrikamFiber Build Service (codesharing-demo))

You can also use the Allow project-scoped builds feature if you would like to automatically set up permissions for your project-scoped build identity.

  1. With your feed selected, select the gear icon gear icon to access the Feed settings.

  2. Select Permissions.

  3. Select the ellipsis on the right and select Allow project-scoped builds from the drop down menu.

feed permissions: allow project-scoped builds


If you want your pipelines to use a package from a feed in a different project, you must set up the other project to grant read/write access to the build service in addition to setting up the appropriate feed permissions.

Sharing packages with everyone in your organization

If you want to make the packages in a feed available to all users in your organization, create or select a view that contains the packages you want to share and ensure its visibility is set to People in my organization.

Sharing packages publicly with anonymous users

You can also make your packages available to anonymous users with limited access by creating a public feed.

What's next?