A managed service for hosting, sharing, and controlling the reusable pieces of software that your teams create and consume.

Starting with the word “package”

Developers do not write everything from scratch. If you need to read a spreadsheet, send an email, or draw a chart, you use code that someone else wrote and shared. That shared code is bundled into a package: a single file, usually compressed, containing the code, a name, a version number, and a list of other packages it needs. Each programming world has its own package format and its own tool to fetch them. .NET developers use NuGet packages, JavaScript developers use npm packages, Java developers use Maven packages, and Python developers use PyPI-style packages.

The tool that downloads and installs these packages is called a package manager. It reads your project’s list of needed packages, fetches each from a registry (a website that stores packages), and puts them where the build can find them. The famous public registries are open to the world and hold millions of packages.

The company problem

Public registries are wonderful, but companies have needs they do not meet.

• Private code: You have shared libraries that must not be public, such as your logging helper or your payment client.
• Reliability: If the public registry is down, or a package is deleted by its author, your builds break.
• Safety: A malicious package with a name similar to yours could sneak into your product.
• Control: You want to know who published what, who can use it, and which versions are approved.

What Azure Artifacts does

Azure Artifacts is a package management service that is part of Azure DevOps, Microsoft’s set of tools for planning, building, testing, and releasing software. It lets your organization create private registries called feeds, publish your own packages to them, and download packages from them. It can also act as a middleman for public registries, saving a copy of each public package you use. It supports several package types with their native tools, so developers keep using the commands they already know.

The word “artifact” is used for several different things in the Microsoft world. Sorting them out now saves a lot of confusion.

flowchart LR
    DEV["Developers write code"] --> REPO["Source repository"]
    REPO --> PIPE["Build pipeline"]
    PIPE --> PKG["Packages published to Azure Artifacts feed"]
    PIPE --> PA["Pipeline artifacts: temporary build outputs"]
    PIPE --> IMG["Container images to Azure Container Registry"]
    PKG --> OTHER["Other projects consume the packages"]
    PUB["Public registries"] --> PKG
    

Comparing with other package hosts

Choosing between them

If your teams already use Azure DevOps for pipelines and permissions, Azure Artifacts is the smoothest choice, because identities, projects, and pipelines are already connected. If your code and pipelines live in GitHub, GitHub Packages fits better. If you need unusual package formats or very advanced policy features, a dedicated repository manager may be worth considering. Many large companies use more than one and connect them.

A handful of words appear in every Azure Artifacts conversation. Learn them once and the rest becomes easy.

Organization and project

In Azure DevOps, an organization is the top-level account of your company. Inside it live projects, each holding the work of a team: code, pipelines, boards, and packages. Both matter for Artifacts, since a feed can belong to either.

Feed

A feed is a private registry: a named container that holds packages and controls who may read or publish them. You can have many feeds, for example one per team, one per product, or one shared by the whole company. Developers point their package manager at the feed’s address.

Package and version

A package is the reusable unit, identified by name. A version is one specific release of it. Versions usually follow semantic versioning, written as three numbers separated by dots, such as 2.4.1. The first number (major) changes when something breaks compatibility, the second (minor) when new features are added safely, and the third (patch) for small fixes. A suffix such as “beta” marks a pre-release, a version not yet considered final.

Immutability

Once a version is published, it can never be changed. You cannot overwrite version 2.4.1 with different contents. This immutability guarantees that every build that asked for 2.4.1 got identical bits, today or next year. To fix a mistake, you publish a new version.

Upstream source

An upstream source is another registry that a feed can pull from, such as a public registry or another feed. When someone asks the feed for a package it does not hold, it fetches it from upstream and keeps a copy.

View

A view is a filtered window onto a feed, showing only versions that have been promoted into it, for example “pre-release” or “release”. Consumers who want only approved versions point at a view instead of the whole feed.

Retention policy

A retention policy is an automatic cleanup rule, such as “keep at most the latest fifty versions of each package”, to control storage use.

Permissions

Access is given through roles on a feed. A reader can download, a collaborator can also save packages from upstream, a contributor can publish, and an owner can manage settings and permissions.

flowchart TD
    ORG["Azure DevOps organization"] --> PRJ["Project"]
    ORG --> OF["Organization scoped feed"]
    PRJ --> PF["Project scoped feed"]
    PF --> PK["Package"]
    PK --> V1["Version 1.0.0"]
    PK --> V2["Version 1.1.0"]
    PK --> V3["Version 1.2.0-beta"]
    PF --> VW["Views: prerelease and release"]
    PF --> UP["Upstream sources"]
    PF --> RP["Retention policy"]
    

Azure Artifacts speaks the native language of several ecosystems, so developers use the tools they already know.

Why native protocols matter

A protocol is the agreed way for a tool and a server to talk. Because Azure Artifacts implements each ecosystem’s protocol, a feed looks to the npm tool like any other npm registry, and to the NuGet tool like any other NuGet source. Developers change an address and a sign-in, not their habits. Build scripts keep working with tiny changes.

Universal Packages in detail

Not everything is a library. Teams also share large files: trained machine learning models, test data sets, installers, or tool kits. Universal Packages give such files a name, a version, and a home in a feed, with the same permissions and retention as other packages. They can be very large, and uploads and downloads are handled efficiently by breaking content into pieces and reusing pieces that already exist.

The feed is the central decision you make. Design it well and everything else becomes simpler.

Project-scoped and organization-scoped feeds

A feed can be project-scoped, belonging to a single project and inheriting its visibility, or organization-scoped, living at the top level and usable across all projects. Project-scoped feeds are the recommended default for new feeds in most cases, since they follow the project’s boundaries and are easier to reason about. Older feeds are often organization-scoped. Each style has its place.

How many feeds?

There is no single right answer, but the options have clear trade-offs.

A popular middle path: one feed for publicly sourced packages with upstreams enabled, which acts as the controlled gateway to the outside world, plus a separate feed per team for its own published packages. Teams then chain these using upstream sources.

flowchart TD
    PUB["Public registries"] --> GW["Company gateway feed with public upstreams"]
    GW --> TA["Team A feed"]
    GW --> TB["Team B feed"]
    TA --> BA["Team A builds"]
    TB --> BB["Team B builds"]
    TA -.->|"upstream"| TB
    

Visibility

A feed can be visible only to specific people and groups, to everyone in the organization, or, for feeds in public projects, to anyone on the internet. Pick the narrowest visibility that works, and remember that anything public cannot easily be taken back.

What sits behind a feed address, seen from a distance.

You never see the machines behind Azure Artifacts, because it is a cloud service run by Microsoft as part of Azure DevOps Services. Still, a rough picture explains its behavior. A request for a package enters through a protocol endpoint, passes an identity check and a permission check, is resolved against the feed’s metadata, and is served from durable storage, or fetched from an upstream source if needed.

flowchart TD
    CL["Client tools: dotnet, npm, pip, Maven, Cargo, universal"] --> EP["Protocol endpoints per package type"]
    EP --> AUTH["Identity and token validation"]
    AUTH --> PERM["Feed permission check"]
    PERM --> META["Feed metadata and package index"]
    META --> STORE["Durable package storage"]
    META --> UPS["Upstream proxy and cache"]
    UPS --> EXT["Public registries and other feeds"]
    EP -.-> AUD["Audit and usage records"]
    

A shared, multi-tenant service

Azure Artifacts serves many customers on shared infrastructure, with strict separation between organizations. Because the platform is shared, it applies usage limits and fair-use throttling, so one very busy client cannot slow down everyone else. A build that hammers the service with thousands of requests may see “too many requests” responses, and should be written to slow down and retry.

Cloud service and self-hosted server

Azure DevOps also comes as a product you can install in your own data center, called Azure DevOps Server. It includes package management too, with its own limits and feature set. This guide focuses on the cloud service, since that is what most teams use. If you must keep everything on your own servers, check the current feature list for the server version.

How a package manager decides which files to download, and why the answer is the same every time.

The dependency tree

Packages depend on other packages, which depend on others in turn, forming a dependency tree. Your application may list ten packages, but the full tree can contain hundreds. The package manager walks this tree, asks the feed for the list of available versions of each package, and picks versions that satisfy every rule. This is called dependency resolution.

Version ranges

A project rarely demands one exact version. It often says “any version from 2.4 up to, but not including, 3.0”. The package manager chooses the highest allowed version, or the lowest, depending on the ecosystem’s rules. Because a feed can publish new versions at any time, two builds run a week apart could pick different versions, unless you pin them. Many ecosystems offer a lock file, a record of the exact versions chosen, so that every build repeats the same choice.

Why immutability matters

Immutability protects three things. First, repeatability: version 2.4.1 means the same bits forever. Second, caching: tools and servers can safely keep copies of an immutable file without checking for changes. Third, trust: a security review of 2.4.1 stays valid, since nobody can swap its contents. Azure Artifacts enforces this: once a version has been published, publishing the same name and version again with different content is refused.

What you can do with a published version

Metadata and the package index

Every package carries metadata: name, version, description, authors, dependencies, and license. The feed indexes this so that searches and resolution are fast without opening each file. For tools that need only to know “which versions exist?”, the index answers in a blink and the heavy file is downloaded only after the choice is made.

Storage efficiency

The service stores each package version once, however many feeds or views refer to it. Promoting a version into a view does not copy the file. It only adds a label. That is why promotion is instant and cheap, and why views are a good way to express approval without duplicating storage.

Follow one package from the moment a developer creates it to the moment another team’s build uses it.

sequenceDiagram
    participant D as Developer or pipeline
    participant F as Azure Artifacts feed
    participant S as Package storage
    participant C as Consumer build
    participant U as Public registry upstream
    D->>F: Publish package version 1.2.0 with token
    F->>F: Check identity, permission and version is new
    F->>S: Store package file and index metadata
    F-->>D: Success
    C->>F: Ask for versions of the package
    F-->>C: List of available versions
    C->>F: Download chosen version
    F->>S: Fetch file
    S-->>C: Package delivered
    C->>F: Ask for a public package not yet in feed
    F->>U: Fetch from upstream and save a copy
    U-->>F: Package
    F-->>C: Package delivered
    

The publish journey

The restore journey

Restore is the step where a build downloads all the packages it needs before compiling. The package manager first reads the project’s list of dependencies and its configured feeds. It then asks each feed for the available versions, resolves the dependency tree, downloads missing files, and stores them in a local cache on the build machine. Later builds on the same machine find them in the local cache, which is faster.

Where each delay comes from

• First restore on a fresh machine: every package must be downloaded, so it is the slowest.
• First request for a new public package: the feed must fetch it from upstream before serving it, adding a short extra delay once.
• Repeated restores: served from the feed or the local cache, which is quick.

Your product is only as safe as the packages inside it. Upstream rules are your first line of defense.

How upstream works

When you enable an upstream source on a feed, the feed becomes a smart middleman. A developer asks the feed for a public package. If the feed does not yet hold it, the feed fetches the right version from the public registry, saves a copy, and serves it. From then on, that version is served from your feed, even if the public registry is down or the original author deletes it. The feed also shows available public versions, so tools can resolve ranges, although only the versions actually used are copied.

flowchart TD
    B["Build asks for a package"] --> Q{"Is the version in the feed"}
    Q -->|"yes"| S["Serve from feed storage"]
    Q -->|"no"| U["Look in upstream sources in order"]
    U --> F{"Found upstream"}
    F -->|"yes"| SV["Save copy in feed"]
    SV --> S
    F -->|"no"| E["Return not found"]
    

Benefits

The dependency confusion attack

Imagine your company has a private package called “acme-billing-helper”. An attacker discovers the name, publishes a package with the same name to the public registry, and gives it a very high version number. A poorly configured build asks both places for the latest version, sees that the public one has a higher number, and downloads the attacker’s code into your product. This is called dependency confusion, and it has hit well-known companies.

Azure Artifacts defends against this with a control on each package: whether versions that come from outside are allowed or blocked. When a package name exists in your own feed, outside versions of the same name can be blocked, so a public lookalike is never served. Keep the setting at its protective choice for internal package names, and never let public and private packages with the same name mix.

Other supply chain risks

• Typosquatting: a malicious package named almost like a popular one, hoping for a typing mistake.
• Compromised maintainers: a trusted public package gets a poisoned update after an account is hijacked.
• Vulnerable versions: an honest package has a security hole discovered later.
• Abandoned packages: something your product depends on is no longer maintained.

Not every published version is ready for everyone. Views let you stage trust.

The problem views solve

When a team publishes a new version, it is untested by other teams. If every consumer’s build picked it up at once, one bug could break dozens of projects. Teams want a way to say “this version is a candidate” and later “this one is approved for everyone”.

Default views

A feed commonly offers three views. The local view contains every version published to the feed and any version saved from upstream. The prerelease view contains candidate versions. The release view contains versions that have been approved. Consumers who point their tools at the release view only ever see approved versions, and the feed’s view addresses look slightly different from the main feed address.

flowchart LR
    PUB["Publish new version"] --> L["Local view: all versions"]
    L -->|"passes automated tests"| PR["Prerelease view: candidates"]
    PR -->|"approved after review and wider testing"| RL["Release view: approved only"]
    RL --> PRODB["Production builds"]
    PR --> TESTB["Test and early adopter builds"]
    L --> DEVB["Developers on the same team"]
    

Why promotion is cheap and safe

Promotion adds a label. It does not copy or change the package, so the bytes tested in prerelease are exactly the bytes shipped in release. This avoids the dangerous habit of rebuilding “the same” code for production, which can yield subtly different results.

Views and version labels together

Views describe approval status, while version numbers describe change. A team can publish 3.0.0-beta.1, 3.0.0-beta.2, and so on, as pre-release versions, then publish 3.0.0 as the final. Combining semantic version suffixes with views gives consumers two signals about stability.

Who may read, who may publish, and how they prove who they are.

Feed roles

Proving identity from a developer machine

Developers can sign in to package tools in several ways.

Proving identity from a pipeline

Pipelines have their own identity, a build service account. Pipeline steps called authentication tasks, one for each ecosystem, set up the package tool with a short-lived token for that identity, so no secret needs to be stored. For the pipeline to publish or restore, its identity must be granted a role on the feed. If a build fails with “unauthorized” for a feed in another project, the missing role grant is the most common cause.

flowchart TD
    P["Pipeline run starts"] --> ID["Pipeline uses build service identity"]
    ID --> T["Authentication step creates short lived token"]
    T --> TOOL["Package tool uses token"]
    TOOL --> F["Feed checks role of the identity"]
    F -->|"role allows"| OK["Restore or publish succeeds"]
    F -->|"no role"| NO["Unauthorized error"]
    

Managing tokens safely

• Least privilege: give tokens only the scope they need, such as read-only package access.
• Short life: choose short expiry dates, and rotate before they run out.
• Never in code: do not commit tokens to source repositories or paste them into chat. Use secret variables or a key vault.
• Prefer identities: where possible, use managed or federated identities and sign-in providers instead of long-lived tokens.
• Organization controls: administrators can limit how long tokens may live, or who may create them.

Groups, not individuals

Grant feed roles to groups from your identity system instead of to single people. When someone joins or leaves a team, their access changes automatically with their group membership, which is both safer and easier to audit.

Packages come alive when pipelines produce and consume them automatically.

A typical library pipeline

flowchart LR
    LIB["Library repository"] --> LP["Library pipeline"]
    LP --> FD["Feed"]
    FD --> AP["Application pipeline restores package"]
    FD --> AP2["Another application pipeline"]
    AP --> APPA["Application A release"]
    AP2 --> APPB["Application B release"]
    

Choosing version numbers

Good versioning is a team agreement, ideally automated. Many teams keep the major and minor numbers in a file in the repository, and let the pipeline fill in the patch number from the build counter. Builds from side branches get a pre-release suffix that includes the branch name, so experiments never look like official releases. Tags in source control can trigger the final release version.

Making restores fast

Using packages from other places

Azure Artifacts feeds are ordinary registries to ordinary tools, so they also work from GitHub Actions workflows, from developer laptops, from other build systems, and from container builds. In each place you provide the feed address and a suitable sign-in.

A package is code that your product trusts completely. Protect the warehouse and everything that enters it.

flowchart TD
    A["Who may use the feed: identity and roles"] --> B["How they sign in: short lived tokens"]
    B --> C["What may enter: upstream rules and review"]
    C --> D["How it is built: protected pipelines"]
    D --> E["What is inside: vulnerability and license scans"]
    E --> F["Who changed what: audit logs"]
    F --> G["Fast response: inventory and alerts"]
    

Control who can publish

Publishing rights are powerful. A malicious or careless publish can plant code in many products at once. Restrict contributor roles to release pipelines and a few owners, protect the branches those pipelines run from, and require code review before changes reach them.

Control what comes in

Treat the gateway to public packages as a checkpoint. Limit who can save new public packages, review newly added ones, and block outside versions of your private names. Consider an approval process for packages with unusual licenses or low maintenance.

Scan and inventory

Automated tools can check the full dependency tree for known security issues and risky licenses. Azure DevOps offers security features that include dependency scanning for supported repositories, and many third-party scanners work in pipelines. Keep a record of the exact package versions inside each release, sometimes called a software bill of materials. When a new vulnerability is announced, you can answer “are we affected?” in minutes.

Audit trail

Azure DevOps keeps an audit log of important actions, such as changing feed permissions, creating or deleting feeds, and changing upstream settings. The log can be viewed in the portal and sent to a monitoring system. Review it periodically and set alerts for suspicious changes, like permissions widened late at night.

Network and sign-in policies

Organization-level controls, such as conditional access policies and allowed network ranges, apply to Azure DevOps and therefore protect access to feeds. Combine them with multi-factor sign-in for people.

Builds stop when the warehouse is closed. Plan so that one failure does not halt your whole company.

Availability of the service

Azure Artifacts is part of a Microsoft-run cloud service with a published availability promise, called a service level agreement. The platform stores data redundantly and recovers from machine failures on its own. No service is perfect, though. Occasional incidents on Azure DevOps will affect pipelines and feeds, and your design should make them survivable.

Upstream caching as resilience

One of the best protections is already built in. Public packages saved in your feed keep serving even if the public registry is offline. The weak spot is a package version you have never used before, which cannot be fetched during a public registry outage. Teams with strict needs pre-warm the feed by restoring their common dependencies after each approval, so nothing is fetched for the first time during an emergency.

Local and build-agent caches

Package managers keep a local cache on each machine. Build agents that are re-created for every run lose this cache, so use pipeline caching or agents that keep their cache between runs. A warm cache lets builds proceed even if the feed is briefly unreachable, because the needed files are already on the machine.

Throttling and fair use

Azure DevOps protects itself with rate limits. A build farm that starts hundreds of jobs at once, each downloading thousands of small files, can hit “too many requests” responses and slow down. Spread the load, enable caching, trim unused dependencies, and make scripts retry politely with increasing waits.

Large packages

Very large files, such as machine learning models, are best shared as Universal Packages, which upload and download in chunks and reuse unchanged pieces between versions. Even so, big downloads are slow on poor links. Place build agents close to the service, cache large downloads, and avoid pulling them on every run.

Scaling with the organization

As the number of packages and consumers grows, the main challenges are human, not technical: naming rules, ownership, cleanup, and discoverability. Write a short package policy covering naming prefixes, version rules, who owns each feed, and how to deprecate packages. A large catalog without ownership turns into a junk drawer.

A warehouse that never throws anything away eventually fills the building. Watching usage and cleaning up keeps it healthy and affordable.

What to watch

Retention policies

Continuous publishing creates many versions. Most are never used again after a newer one appears. A retention policy automatically removes the oldest versions beyond a number you choose for each package. Versions that have been promoted to a view are normally kept, so the approved ones that real products use are safe from cleanup. Choose the number with care: keep enough history to roll back and to rebuild older product releases.

The recycle bin

Deleted package versions move to a recycle bin for a limited time before being permanently removed. This gives a safety net for mistakes. Remember, though, that once a version is truly gone, its number cannot be reused for different contents, so consumers who needed it must move to another version.

Cost awareness

Azure Artifacts offers a free allowance of storage for each organization, and usage above it is billed according to Microsoft’s current pricing. Because prices and allowances change, check the official pricing page for today’s numbers. What stays true is the cost drivers: total stored size, number of retained versions, and big files like Universal Packages or large binaries.

Ways of organizing feeds that experienced teams repeat, and traps that they learned to avoid.

Pattern: one organization feed with upstreams

A single organization-wide feed with public upstreams gives every team one address, one set of rules, and one cache. It suits small to medium companies where teams share most libraries.

Pattern: team feeds plus a shared gateway feed

Each team has its own feed for its internal libraries, and each team feed uses one shared “gateway” feed as an upstream. The gateway feed is the only one connected to public registries and is managed by a platform team. Teams get independence, and the company gets a single controlled entrance.

flowchart TD
    PUBR["Public registries"] --> GW["Gateway feed managed by platform team"]
    GW --> TA["Team A feed"]
    GW --> TB["Team B feed"]
    GW --> TC["Team C feed"]
    TA --> BA["Team A builds"]
    TB --> BB["Team B builds"]
    TC --> BC["Team C builds"]
    TA -.->|"upstream of other feeds if allowed"| TB
    

Pattern: promotion by views

Every library publishes once, then moves through prerelease and release views. Consumers choose their level of risk by choosing a view.

Pattern: build once, promote the same bits

Never rebuild for production. The package tested is the package shipped.

Anti-patterns

A checklist you can adopt on the first day, and a list of stumbles to skip.

Best practices

Common mistakes

These are composite examples that show typical situations. They are illustrations, not reports about specific companies.

Several tools store build outputs. Knowing which does what avoids wasted effort.

flowchart TD
    Q["What are you storing"] --> A{"Container image"}
    A -->|"yes"| ACR["Azure Container Registry"]
    A -->|"no"| B{"Reusable package for other projects"}
    B -->|"yes"| ART["Azure Artifacts feed"]
    B -->|"no"| C{"Only passed between stages of one pipeline"}
    C -->|"yes"| PA["Pipeline artifacts"]
    C -->|"no"| BLOB["Blob storage or another store"]
    

When to look elsewhere

• If your code and workflows live in GitHub, GitHub Packages may be simpler.
• If you need package formats Azure Artifacts does not offer, a third-party repository manager may fit.
• If you run Azure DevOps Server on your own machines, remember it is a separate product with its own feature set and versions, so check its documentation.

Azure Artifacts turns scattered code copies into a controlled, versioned supply of building blocks.

You began with a simple idea: a good workshop keeps a labeled parts warehouse instead of letting every craftsperson make their own copies. Azure Artifacts is that warehouse for software. Feeds hold packages, packages hold immutable versions, upstream sources bring in public packages safely, and views let you promote trust step by step. Authentication, roles, and pipelines connect all of it to everyday work, while retention, monitoring, and clear ownership keep it tidy and affordable.

The deeper lesson is about trust. Every package you use is code you did not write running inside your product. The practices in this guide, such as pinned versions, blocked lookalikes, reviewed additions, protected pipelines, inventories, and audit logs, are how you keep that trust earned rather than assumed.