Fix Azure DevOps Artifacts: Setup, Publishing & Feed Errors

Why Azure DevOps Artifacts Stops Working

Here's a scenario I've seen play out dozens of times: a developer sets up a new Azure DevOps project, creates an Azure Artifacts feed, and then spends the next two hours staring at a 401 Unauthorized error or a Unable to load the service index for source message in their terminal. Nothing in the error tells you why it failed. Just a wall of red text and a deadline looming.

Azure DevOps Artifacts is Microsoft's centralized package management service. It lets your team store, manage, and share packages , NuGet, npm, Maven, Python, Cargo, and Universal Packages , all from a single feed. On paper, it's exactly what modern development teams need. In practice, getting it working correctly the first time is where most people hit a wall.

The problems almost always fall into one of four buckets:

• Authentication failures, The Azure Artifacts Credential Provider isn't installed, expired, or misconfigured. Your NuGet client has no way to prove who you are to the feed.
• Feed configuration errors, The nuget.config file is pointing at the wrong feed URL, scoped incorrectly, or missing entirely from the project directory.
• Permissions problems, The account running the restore or publish command doesn't have the right role assigned in the feed settings. This is especially common in CI/CD pipelines where a service principal or build identity is used instead of a personal account.
• Upstream source misconfiguration, You expect packages from NuGet.org or npmjs.com to flow through your feed automatically, but upstream sources weren't enabled when the feed was created, or they were set up incorrectly after the fact.

Microsoft's error messages for Azure Artifacts failures are notoriously unhelpful. A 401 could mean your token expired, your credential provider isn't installed, or the feed URL in your config is wrong. A package restore failure could be a network issue, a visibility setting, or a missing upstream source. The error text rarely tells you which.

I know this is frustrating, especially when the rest of your pipeline is green and this one piece is blocking a deploy. The good news is that once you understand the three moving parts (feed, credential provider, config file), nearly every Azure DevOps Artifacts issue has a clear fix.

This guide covers the most common Azure DevOps Artifacts setup errors, NuGet feed publishing failures, upstream source configuration problems, and permission issues, all grounded in what Microsoft's official documentation actually says to do. Browse all Microsoft fix guides →

The Quick Fix, Try This First

If you're getting authentication errors when trying to restore or publish packages to an Azure Artifacts feed, start here. The single most common root cause is a missing or outdated Azure Artifacts Credential Provider. This is a NuGet plugin that handles the OAuth token exchange between your local machine and the Azure DevOps feed. Without it, NuGet doesn't know how to authenticate.

Open PowerShell as your normal user (not admin, this matters) and run:

iex "& { $(irm https://aka.ms/install-artifacts-credprovider.ps1) }"

That script pulls and installs the latest credential provider directly from Microsoft. After it finishes, close and reopen your terminal, then retry your dotnet restore or nuget restore command. You should see a browser window or a device login prompt asking you to authenticate with your Azure DevOps account. Sign in, and the credential provider caches your token going forward.

If you're on a machine that doesn't allow interactive browser prompts, a build server, for example, you'll need to use a Personal Access Token (PAT) instead. Go to Azure DevOps → User Settings → Personal Access Tokens → New Token. Set the scope to Packaging (Read & Write), copy the token, and pass it as the password in your feed source configuration. More on that in the step-by-step section below.

After installing the credential provider, also verify your nuget.config file exists in your project root and contains the correct feed URL. The feed URL format for Azure Artifacts looks like this:

https://pkgs.dev.azure.com/{organization}/{project}/_packaging/{feedName}/nuget/v3/index.json

If that URL is wrong by even a single character, wrong org name, wrong feed name, you'll get a misleading 404 that looks like an auth error. Double-check it in the Azure DevOps portal under Artifacts → Connect to Feed → dotnet.

Advanced Troubleshooting for Azure DevOps Artifacts

Diagnosing 401 and 403 Errors in Feed Access

A 401 Unauthorized means authentication failed entirely, your client couldn't prove who it is. A 403 Forbidden means authentication succeeded but your account doesn't have permission to do what you're trying to do. These are different problems with different fixes.

For 401 errors, the fix chain is: (1) verify the credential provider is installed, (2) check your PAT hasn't expired, (3) confirm the feed URL in your config matches exactly what's shown in the "Connect to Feed" dialog. Run this to clear cached credentials and force a fresh login:

dotnet nuget locals all --clear

For 403 errors, go to Azure DevOps → Artifacts → your feed → Feed Settings → Permissions. You'll see roles assigned to identities, Owner, Contributor, Collaborator, and Reader. The account you're publishing from needs at minimum Contributor access to push packages. Collaborator can only consume (read/install). Check that your identity, or your pipeline's build service account, has the right role.

In Azure Pipelines specifically, the build service account is usually listed as {ProjectName} Build Service ({OrgName}). Add this identity to your feed with Contributor permissions if your pipeline publish tasks are failing with 403.

Storage Limits and What Happens When You Hit Them

Azure Artifacts gives each organization 2 GiB of free storage. That sounds like a lot until you start storing large Universal Packages or keeping every historical version of heavily-used NuGet packages. When you hit the limit, publishes start failing with errors like TF400898 or generic HTTP 500 responses from the Artifacts endpoint.

Check your current usage: go to Organization Settings → Billing → Artifacts storage. You'll see total usage and a breakdown by project. To free space, go into your feed and delete old package versions you no longer need, navigate to the package, expand the version list, select obsolete versions, and click Delete version. Deleted versions go to a recycle bin and are permanently removed after 30 days.

If your team's usage genuinely exceeds 2 GiB, you can increase the storage limit through Organization Settings → Billing. Microsoft charges per GiB beyond the free tier.

Package Restore Failures in Azure Pipelines

Pipeline restore failures are almost always one of three things: wrong feed URL in the pipeline's NuGetAuthenticate task, the build service account lacks feed permissions, or the nuget.config committed to the repo has a placeholder URL rather than the real one.

In your Azure Pipeline YAML, the recommended pattern for Azure Artifacts NuGet restore is:

- task: NuGetAuthenticate@1

- task: DotNetCoreCLI@2
  inputs:
    command: 'restore'
    projects: '**/*.csproj'
    feedsToUse: 'config'
    nugetConfigPath: 'nuget.config'

The NuGetAuthenticate@1 task automatically injects credentials for any Azure Artifacts feeds referenced in your nuget.config. You don't need to manage PATs manually in pipelines when you use this task, it uses the pipeline's identity and your feed permission settings.

Debugging with Feed Views and Package Promotion

Azure Artifacts feeds support views, named snapshots of your feed (typically @local, @prerelease, and @release). Packages published to a feed land in @local by default. If your downstream consumers are configured to only see packages promoted to @release, they won't find newly published packages until someone explicitly promotes them.

To promote a package, go to the package in your feed, click the version you want to promote, then use the Promote button and select the target view. This is worth checking if packages publish successfully but still aren't found during restore on other machines.

Prevention & Best Practices for Azure Artifacts Feeds

The teams I've seen get the most value from Azure DevOps Artifacts are the ones who set it up thoughtfully once, rather than patching problems reactively. Here's what separates the smooth setups from the ones that generate support tickets every sprint.

Use feed views from day one. Treating @prerelease and @release as promotion gates, rather than just publishing everything to @local, gives you a controlled release process for internal packages. Your CI pipeline publishes to @prerelease automatically; a human approves promotion to @release after testing. This prevents half-baked packages from landing in production builds.

Scope your feeds to match your team structure. Don't dump all packages from all projects into one organization-scoped feed just because you can. Project-scoped feeds give teams clearer ownership, simpler permission management, and faster debugging when something goes wrong. You can always add an upstream source pointing at a shared org-level feed if cross-project sharing is needed.

Rotate PATs on a schedule. Personal Access Tokens used for feed authentication in scripts or environment variables expire silently. Set a calendar reminder to rotate them before they expire, 90 days is a reasonable cycle. When a PAT expires, every automated process using it fails at once. Build in PAT rotation as a maintenance task, not a crisis response.

Monitor your storage usage proactively. The 2 GiB free tier disappears faster than you'd think in active projects. Set up a monthly check of Organization Settings → Billing. Better yet, script a PAT-authenticated API call to the /_apis/packaging/feedstoragedata endpoint and pipe it into your monitoring dashboard so you're not surprised by a storage-full failure during a release.

Always pin package versions in production builds. Using floating version ranges like [1.0, ) in your NuGet dependencies means the next upstream package version gets pulled into your build automatically. That might be fine in development, but in production pipelines it's a recipe for non-deterministic builds. Pin exact versions and promote updates deliberately.

Frequently Asked Questions