Change project visibility to public or private

Azure DevOps Services

In this article, learn how to change the visibility of your project to public or private.

When you switch a private project to public visibility, it encompasses all its contents. It's not possible to selectively keep certain repositories, area paths, or build folders private.

Access is restricted for users who aren't signed in, often referred to as anonymous or public users. There are also users who are signed into Azure DevOps but aren't part of a project. Both these categories of users are given limited, read-only access as outlined in the following table.

When you switch a private project to public, all project members experience the following changes:

• Permissions marked Deny aren't recognized. The permissions automatically given to a nonmember set a minimum level of capabilities that can be assigned to any project member.
• If a build pipeline is set to Project Collection scope, it runs with a Project scope instead, which reduces the risk of malicious users gaining access to the build service's authentication token.
• Stakeholders have full access to Repos or Code features in public projects, but have no access in private projects.
• Stakeholders have full access to Boards or Work in public projects, but only partial access in private projects. For more information, see Stakeholder access quick reference.
• Basic + Test Plans users can view and run tests from Test Plans or Test. Basic users need to upgrade their access level to Basic + Test Plans to get full access, which includes capability to create test plans and add test cases.

Hub / Settings	Nonmember access	Stakeholder access	Basic access	Reader access	Contributor access	Project Admin access
Dashboards	read (many widgets aren't available)	partial	full	read	read-write	read-write-administer
Wiki	read	full	full	read	read-write	read-write-administer
Boards (Work)	read	partial	full	read	read-write	read-write-administer
Repos (Code)	read	full	full	read	read-write	read-write-administer
Pipelines (Build and Release)	read	full	full	read	read-write	Read-Write-Administer
Test Plans	no access	no access	partial access (see last bullet prior to table)	read	read-write	Read-Write-Administer
Notifications	no access	Full	Full	Read	read-write	read-write-administer
Search	full	full	full	full	full	full
Settings	No access	Full	Full	Read	Read	Read-Write-Administer

Prerequisites

• You must have an organization in Azure DevOps.
• You must be a member of the Project Collection Administrators group. Organization owners are automatically members of this group.
• Understand access levels and unavailable features for public projects.
• Be aware of partial migration options.
• Review items in the migration checklist.

Migration checklist

Most private projects contain a large amount of historical data. Old work items, early commits, and previous build pipelines might contain information you don't want to share publicly.

The following checklist indicates those items you might want to review before you make a project public. It also provides tips for migrating work items or files to a new project so that you can expose only current and future content.

Category

Guidance

Organization identities and settings

Understand that a user gains access to the following resources and details about the organization:

• Identities: List of all members added to the organization and email address for each member.
• Settings: Read-only view of all organization and project settings.
• Process metadata: All picklist values in all projects in the organization.
• Builds and releases: Names of people who triggered them, plus identities, including email addresses embedded in Git commits.
• Commits and work items: Embedded information, such as first name, last name, and email address.

Cross-project object links

Check whether links exist between projects, as details about the linked artifact in the private project are visible within the public project. You can use the following link types: branch, build, changeset, commit, found in build, integrated in build, pull request, and versioned item. Titles and names are exposed in the following links types: versioned item, branch, wiki page, pull request, and work item.

Agile tools and work items

Confirm that your work items, even closed ones, don't contain sensitive details: undisclosed security flaws, credentials, and customer data. Work-items maintain their history when they're migrated from a private to public project. All discussions and descriptions are available. Check that none contains problematic speech.

Confirm that none of your area paths have special, locked-down security settings. Denied permissions aren't enforced in a public project, so restricted area paths become public.

Code

Confirm that you have no sensitive details in your repositories' history: unpatched security bugs, credentials, and code you don't have the right to distribute.

All file contents and commit messages are available. Check that none contains problematic speech. If you aren't comfortable exposing an entire repository, you can migrate the tip to another project. For more information, see Instructions for a tip migration.

Build and release

Confirm that none of your pipelines expose sensitive data: credentials/secrets, obscure URLs, and private environment names.

Confirm that nonmembers don't require access to your private feeds. Builds can still access feeds, but nonmembers can't. If you need to migrate build pipelines to a new project, you can import and export them using YAML.

Test

Understand that manual and cloud load testing features aren't available to nonmembers in a public project.

Analytics and dashboards

Consider building a dashboard intended for the public. Some widgets are unavailable to nonmembers.

Artifacts

Confirm that none of the packages in any of the feeds that are scoped to the project have privacy concerns. All packages in the feeds that are scoped to the project become public. All existing upstream settings of the feeds that are scoped to the project are disabled once the project becomes public.

Extensions

Confirm whether there are any extensions vital to your project's experience. For instance, do you have a control on your work item form that renders data in a particular way? Are there custom extensions that expose important details?

Confirm that each extension's author made it available for nonmembers by testing it. If not, ask the extension author to add support for nonmembers.

1. Enable anonymous access to projects

Before you can change a private project to a public project, you must enable anonymous access for your organization.

1. Sign in to your organization (https://dev.azure.com/{yourorganization}).

2. Select Organization settings.

   

3. Select Policies, and then turn On the Allow public projects security policy.

   

2. Set project visibility

1. Sign in to your project (https://dev.azure.com/{YourOganization}{YourProject}).

2. Select Project settings > Overview > the Visibility dropdown menu, choose Public or Private, and then Save.

   

Access levels and unavailable features for public projects

A project member has access to features based on the access level assigned. Nonmembers / public users are granted limited access automatically. To contribute to a public project, you must be added as a member of that project and assigned either Stakeholder, Basic, or Basic + Test Plans access. Access levels determine the user interfaces that you can access. The security group you're assigned to determines the features you can exercise. For more information, see About access levels.

You add project members in the same way you do for private projects. Be sure you understand what it means to invite an external user to have access to your project. If you created the project, you're automatically assigned to the Project Administrators group.

The following user interface elements are hidden for nonmembers.

Service

Hidden UI elements

Boards

Work items are available, but Backlogs, Boards, Sprints, Queries, and Plans are hidden.

Repos

Team Foundation Version Control (TFVC) repositories are hidden.

Pipelines

Builds and Releases are available, but Library, Task Groups, Deployment Groups, Packages, and XAML build system are hidden. Pipeline and task editors for build and release pipelines are unavailable. Only the new Releases page, which is in Public preview, is available.

Test Plans

Test Plans and the associated manual and cloud load testing features are hidden.

Analytics

Analytics views are hidden, and the Analytics OData feed isn't supported for nonmembers. Power BI integration in general isn't supported.

Settings

Settings and administrative pages are hidden.

Nonmembers can't do the following tasks:

• Edit or create artifacts, such as files, work items, and pipelines
• Favorite and follow existing artifacts
• View project members' email addresses and other contact information; nonmembers can only see name and picture. Also, filter lists of artifacts by identity
• Switch between two public projects in the same organization; nonmembers must go directly to a public project using a URL
• Perform code or work item searches across an organization

Partial migration

If your organization contains sensitive material, you shouldn't turn on the public projects policy. We recommend that you create an entirely separate organization to host your public projects.

Move work items to a private project

If any work items are sensitive, you can move them into a separate, private project. Cross-project links continue to work for members, but nonmembers don't have access to the content since it resides in a private project.

If you have a large number of sensitive work items, consider keeping your current project private. Instead, create a new public project in another organization. Migrating work items can be accomplished using the open source WiMigrator maintained by Microsoft.

Migrate Git tip only

If a repository can't be shared due to problematic history, consider doing a tip-only migration to a new repository in a different project. Keep the project containing the problematic repository private. Create the new repository in a project that you don't mind making public.

Warning

• The new repository doesn't connect to the old one.
• You can't easily migrate changes between them in the future.
• Your pull request history doesn't migrate.

1. Clone the existing repository: git clone <clone_URL>.
2. Make sure you're in the root of the repository: cd <reponame>.
3. Ensure you're on the tip of the branch you want to start from: git checkout main.
4. Delete the Git data: rmdir /s .git on Windows, rm -rf .git on macOS or Linux.
5. Initialize a new Git repository: git init.
6. Create a new, empty repository in your public project.
7. Add the new repository as your origin remote: git remote add origin <new_clone_URL>.
8. Push your new repository: git push --set-upstream origin main.

Next steps

Code with Git

Related articles

• Limit user visibility for projects and more
• Delete a project
• Add external users
• Add a privacy policy URL