Azure Artifacts: Private Package Feeds (npm, NuGet, Maven)

By Kokil Thapa | Last reviewed: August 2026

Azure Artifacts private package feeds provide a centralized, secure registry for sharing internal libraries across npm, NuGet, and Maven ecosystems within your organization. When building reusable components for client projects or managing proprietary dependencies, relying on public registries introduces security risks and versioning chaos. This guide covers the practical configuration, authentication patterns, and CI/CD integration required to run Azure Artifacts: Private Package Feeds (npm, NuGet, Maven) effectively in production environments.

How do you configure Azure Artifacts private package feeds for npm?

Setting up npm feeds in Azure Artifacts requires careful attention to authentication and scope configuration. Unlike public npm, private feeds demand explicit credential management that differs between local development and automated build systems. For teams transitioning from ad-hoc Git-based dependency management, this shift enables proper versioning and audit trails—critical when maintaining multiple client projects like those described in Laravel development workflows.

Configuring .npmrc for private feeds

The .npmrc file is where feed authentication lives. A common mistake is committing credentials to version control or using user-level configs that break in CI. Always use project-scoped .npmrc files with environment variable substitution:

# .npmrc (project root)
registry=https://pkgs.dev.azure.com/{org}/{project}/_packaging/{feed}/npm/registry/
always-auth=true

# Authentication token injected via environment variable
//pkgs.dev.azure.com/{org}/{project}/_packaging/{feed}/npm/:_authToken=${NPM_TOKEN}

# Upstream caching ensures public packages resolve through your feed
@your-org:registry=https://pkgs.dev.azure.com/{org}/{project}/_packaging/{feed}/npm/registry/

In CI pipelines, inject NPM_TOKEN as a secret variable. Locally, use npm login --registry=https://pkgs.dev.azure.com/... to generate temporary credentials without storing PATs in plain text. For monorepos using workspaces, place the .npmrc at the workspace root to ensure consistent resolution across all packages.

Publishing packages with proper scoping

Scoped packages (@your-org/package-name) prevent naming collisions and clearly signal internal origin. Before publishing, verify your package.json includes:

• "name": "@your-org/component-library"
• "publishConfig": { "registry": "https://pkgs.dev.azure.com/{org}/{project}/_packaging/{feed}/npm/" }
• "repository": { "type": "git", "url": "https://dev.azure.com/{org}/{project}/_git/{repo}" }

Run npm publish from the package directory. Azure Artifacts enforces immutable versions by default—once published, a version cannot be overwritten. This prevents supply chain attacks but requires disciplined version bumping. Use semantic versioning strictly; reserve prerelease tags (-beta.1) for testing before promoting to stable.

What are the key differences between NuGet and Maven feed setup in Azure Artifacts?

While npm relies on .npmrc, NuGet and Maven use platform-native configuration files with distinct authentication mechanisms. Understanding these differences prevents frustrating debugging sessions when onboarding new team members or integrating legacy systems.

NuGet configuration for .NET projects

NuGet feeds integrate directly with Visual Studio and the dotnet CLI. Create a nuget.config at your solution root:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <clear />
    <add key="AzureArtifacts" value="https://pkgs.dev.azure.com/{org}/{project}/_packaging/{feed}/nuget/v3/index.json" />
  </packageSources>
  <packageSourceCredentials>
    <AzureArtifacts>
      <add key="Username" value="azurartifacts" />
      <add key="ClearTextPassword" value="%NUGET_PAT%" />
    </AzureArtifacts>
  </packageSourceCredentials>
</configuration>

In Azure Pipelines, use the built-in NuGetAuthenticate task instead of manual credential injection—it automatically configures the credential provider and avoids exposing PATs. For local development, install the Azure Artifacts Credential Provider which handles interactive login and token refresh transparently.

Maven repository configuration for Java/JVM projects

Maven requires server definitions in settings.xml (usually ~/.m2/settings.xml) and repository declarations in pom.xml:

<!-- ~/.m2/settings.xml -->
<servers>
  <server>
    <id>azure-artifacts</id>
    <username>azurartifacts</username>
    <password>${env.MAVEN_PAT}</password>
  </server>
</servers>

<!-- pom.xml repositories section -->
<repositories>
  <repository>
    <id>azure-artifacts</id>
    <url>https://pkgs.dev.azure.com/{org}/{project}/_packaging/{feed}/maven/v1</url>
  </repository>
</repositories>

<distributionManagement>
  <repository>
    <id>azure-artifacts</id>
    <url>https://pkgs.dev.azure.com/{org}/{project}/_packaging/{feed}/maven/v1</url>
  </repository>
</distributionManagement>

The <id> must match exactly between settings.xml and pom.xml. In CI, pass MAVEN_PAT as an environment variable or use the MavenAuthenticate task. Note that Maven’s groupId serves as your namespace—use reverse domain notation (com.yourorg.project) to avoid conflicts with public artifacts.

How do you integrate Azure Artifacts with CI/CD pipelines securely?

Hardcoding credentials in pipeline YAML is a security vulnerability waiting to happen. Azure DevOps provides dedicated tasks and service connections that handle authentication without exposing secrets. This pattern aligns with secure deployment practices discussed in CI/CD pipeline setup guides, where secret management is non-negotiable.

Azure Pipelines native authentication tasks

For each ecosystem, use the corresponding authenticate task before restore/publish operations:

# npm pipeline example
steps:
- task: NodeTool@0
  inputs:
    versionSpec: '22.x'

- task: npmAuthenticate@0
  inputs:
    workingFile: '$(Build.SourcesDirectory)/.npmrc'
    customEndpoint: 'AzureArtifactsFeedConnection'

- script: npm ci
  displayName: 'Install dependencies'

- script: npm publish
  displayName: 'Publish package'
  condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')

The npmAuthenticate task temporarily modifies the specified .npmrc with pipeline-generated credentials, then restores it after execution. This eliminates credential leakage in logs or artifacts. The same pattern applies to NuGetAuthenticate@1 and MavenAuthenticate@0.

Service connections for cross-project access

When multiple projects consume packages from a central feed, create a service connection under Project Settings → Service Connections → Azure Artifacts. This grants pipeline-level access without embedding PATs in YAML. Restrict permissions using feed-level security: give consuming projects "Contributor" access only if they need to publish, otherwise "Reader" suffices.

For GitHub Actions or external CI systems, use the actions/setup-node action with a scoped PAT stored as a repository secret. Generate tokens with minimal scope (Packaging Read for consumers, Read+Write for publishers) and rotate them quarterly. Never reuse PATs across different CI systems or team members.

What are the cost implications and retention strategies for Azure Artifacts?

Azure Artifacts charges per GB of stored data beyond the free tier (2 GB included). Without retention policies, feeds accumulate obsolete versions rapidly—especially in active monorepos. On a recent legal-tech portal project, we reduced storage costs by 60% within three months by implementing aggressive retention rules alongside the development workflow documented in legal tech solutions architecture.

Configuring retention policies

Navigate to Artifacts → Select Feed → Settings → Retention Policies. Configure two complementary rules:

1. Version retention: Keep the latest N versions per package (e.g., 5 stable + 3 prerelease). Older versions are soft-deleted and recoverable for 30 days.
2. Days-based retention: Delete versions older than X days regardless of count (e.g., 90 days for prereleases, 365 for stable). This catches abandoned packages that stop receiving updates.

Enable "Delete deleted versions permanently after 30 days" to prevent indefinite soft-delete accumulation. Monitor usage via the Artifacts analytics dashboard—identify packages with zero downloads in 90 days and archive or delete them. For large organizations, consider separate feeds per team or product line to isolate retention policies and simplify billing allocation.

Optimizing upstream source caching

Upstream sources cache public packages on first request, counting toward your storage quota. To minimize bloat:

• Disable upstream caching for feeds containing only internal packages
• Create dedicated "cache-only" feeds for public dependencies with shorter retention
• Use npm ci instead of npm install to avoid unnecessary metadata requests
• Audit cached packages quarterly; remove unused transitive dependencies

Remember that upstream caching improves build reliability during public registry outages—a worthwhile tradeoff for most production systems. Calculate the cost-benefit based on your team's build frequency and downtime tolerance rather than optimizing purely for storage savings.

Final recommendations for Azure Artifacts private package feeds

Azure Artifacts private package feeds deliver genuine value when configured with discipline: scoped authentication, automated CI integration, and proactive retention management. Start with a single feed per ecosystem, enforce semantic versioning from day one, and treat feed configuration as infrastructure code—not manual setup. For teams evaluating whether to adopt private feeds versus alternatives like GitHub Packages or self-hosted Verdaccio, prioritize integration depth with your existing Azure DevOps toolchain over marginal feature differences. If you're planning a migration or need help architecting a secure package management strategy for your development team, reach out to discuss your specific requirements.