Publishing packages

Once you have created a package and have your .nupkg file in hand, it's a simple process to make it available to other developers, either publicly or privately:

  • Public packages are made available to all developers globally through as described in this article (requires NuGet 4.1.0+).
  • Private packages are available to only a team or organization, by hosting them either a file share, a private NuGet server, Azure Artifacts, or a third-party repository such as myget, ProGet, Nexus Repository, and Artifactory. For additional details, see Hosting Packages Overview.

This article covers publishing to; for publishing to Azure Artifacts, see Package Management.

Publish to

For, you must sign in with a Microsoft account, with which you'll be asked to register the account with

NuGet sign in location

Next, you can either upload the package through the web portal, push to from the command line (requires nuget.exe 4.1.0+) , or publish as part of a CI/CD process through Azure DevOps Services, as described in the following sections.

Web portal: use the Upload Package tab on

  1. Select Upload on the top menu of and browse to the package location.

    Upload a package on

  2. tells you if the package name is available. If it isn't, change the package identifier in your project, rebuild, and try the upload again.

  3. If the package name is available, opens a Verify section in which you can review the metadata from the package manifest. If you included a readme file in your package, check out the preview to ensure all content is being rendered properly. To change any of the metadata, edit your project (project file or .nuspec file), rebuild, recreate the package, and upload again.

  4. When all the information is ready, select the Submit button

Command line

To push packages to, you first need an API key, which is created on You must use either dotnet.exe (.NET Core), or nuget.exe v4.1.0 or above, which implement the required NuGet protocols. For more information, see .NET Core, nuget.exe, and NuGet protocols.

Create API keys

  1. Sign into your account or create an account if you don't have one already.

    For more information on creating your account, see Individual accounts.

  2. Select your user name (on the upper right), then select API Keys.

  3. Select Create, provide a name for your key, select Select Scopes > Push. Enter * for Glob pattern, then select Create. (See below for more about scopes.)

  4. Once the key is created, select Copy to retrieve the access key you need in the CLI:

    Copying the API key to the clipboard


Always keep your API key a secret! Treat your API key as a password that allows anyone to manage packages on your behalf. You should delete or regenerate your API key if it is accidentally revealed.


Save your key in a secure location because you cannot copy the key again later on. If you return to the API key page, you need to regenerate the key to copy it. You can also remove the API key if you no longer want to push packages.

Scoping allows you to create separate API keys for different purposes. Each key has its expiration timeframe and can be scoped to specific packages (or glob patterns). Each key is also scoped to specific operations: push of new packages and updates, push of updates only, or delisting. Through scoping, you can create API keys for different people who manage packages for your organization such that they have only the permissions they need. For more information, see scoped API keys.

Publish with dotnet nuget push

  1. Change to the folder containing the .nupkg file.

  2. Run the following command, specifying your package name (unique package ID) and replacing the key value with your API key:

    dotnet nuget push AppLogger.1.0.0.nupkg --api-key qz2jga8pl3dvn2akksyquwcs9ygggg4exypy3bhxy6w6x6 --source
  3. dotnet displays the results of the publishing process:

    info : Pushing AppLogger.1.0.0.nupkg to ''...
    info :   PUT
    info :   Created 12620ms
    info : Your package was pushed.

See dotnet nuget push.

Publish with nuget push

  1. At a command prompt, run the following command, replacing <your_API_key> with the key obtained from

    nuget setApiKey <your_API_key>

    This command stores your API key in your NuGet configuration so that you don't need to repeat this step again on the same computer.


    API key is not used for authenticating with the private feed. Refer to nuget sources command to manage credentials for authenticating with the source. API keys can be obtained from the individual NuGet servers. To create and manange APIKeys for refer to Create API keys.

  2. Push your package to NuGet Gallery using the following command:

    nuget push YourPackage.nupkg -Source

Publish signed packages

To submit signed packages, you must first register the certificate used for signing the packages.

Warning rejects packages that don't satisfy the signed package requirements.

Package validation and indexing

Packages pushed to undergo several validations, such as virus checks. (All packages on are periodically scanned.)

When the package has passed all validation checks, it might take a while for it to be indexed and appear in search results. Once indexing is complete, you receive an email confirming that the package was successfully published. If the package fails a validation check, the package details page will update to display the associated error and you also receive an email notifying you about it.

Package validation and indexing usually takes under 15 minutes. If the package publishing is taking longer than expected, visit to check if is experiencing any interruptions. If all systems are operational and the package hasn't been successfully published within an hour, please login to and contact us using the Contact Support link on the package page.

To see the status of a package, select Manage packages under your account name on You receive a confirmation email when validation is complete.

Note that it might take a while for your package to be indexed and appear in search results where others can find it, during which time you see the following message on your package page:

Message indicating a package is not yet published

Azure DevOps Services (CI/CD)

If you push packages to using Azure DevOps Services as part of your Continuous Integration/Deployment process, you must use nuget.exe 4.1 or above in the NuGet tasks. Details can be found on Using the latest NuGet in your build (Microsoft DevOps blog).

Managing package owners on

Although each NuGet package's .nuspec file defines the package's authors, the gallery does not use that metadata to define ownership. Instead, assigns initial ownership to the person who publishes the package. This is either the logged-in user who uploaded the package through the UI, or the users whose API key was used with nuget SetApiKey or nuget push.

All package owners have full permissions for the package, including adding and removing other owners, and publishing updates.

To change ownership of a package, do the following:

  1. Sign in to with the account that is the current owner of the package.
  2. Select your account name, select Manage packages, and expand Published Packages.
  3. Select on the package you want to manage, then on the right side select Manage owners.

From here you have several options:

  1. Remove any owner listed under Current Owners.
  2. Add an owner under Add Owner by entering their user name, a message, and selecting Add. This action sends an email to that new co-owner with a confirmation link. Once confirmed, that person has full permissions to add and remove owners. (Until confirmed, the Current Owners section indicates pending approval for that person.)
  3. To transfer ownership (as when ownership changes or a package was published under the wrong account), add the new owner, and once they've confirmed ownership they can remove you from the list.

To assign ownership to a company or group, create a account using an email alias that is forwarded to the appropriate team members. For example, various Microsoft ASP.NET packages are co-owned by the microsoft and aspnet accounts, which simply such aliases.

Recovering package ownership

Occasionally, a package may not have an active owner. For example, the original owner may have left the company that produces the package, credentials are lost, or earlier bugs in the gallery left a package ownerless.

If you are the rightful owner of a package and need to regain ownership, use the contact form on to explain your situation to the NuGet team. We then follow a process to verify your ownership of the package, including trying to locate the existing owner through the package's Project URL, Twitter, email, or other means. But if all else fails, we can send you a new invite to become an owner.