Azure Artifacts: One Trusted Home for Your Software Packages
A friendly, step-by-step guide to how Azure Artifacts stores, shares, and protects the packages your software is built from, covering feeds, upstream sources, views, permissions, pipelines, security, retention, and cost, with plain-English analogies throughout.
Imagine you run a busy bakery. Every morning your bakers need flour, sugar, yeast, and special spice blends. If each baker drove to a different shop whenever they ran short, the results would be messy: different brands, different quality, and some mornings a shop might be closed. A smart bakery solves this with one well-organized pantry. Every ingredient is stocked in one place, labeled with its version, checked for freshness, and available to every baker. Software teams face exactly the same problem with the building blocks of their programs, and Azure Artifacts is the well-organized pantry.
In this guide you will learn what Azure Artifacts is, why it exists, how its parts fit together, and how teams use it safely every day. You do not need any background in package management or cloud tooling. Every new word is explained the first time it appears.
1What Is Azure Artifacts?
Azure Artifacts is a managed service for storing and sharing software packages, and it is part of Azure DevOps.
First, What Is a Package?
Almost no modern program is written entirely from scratch. Developers reuse ready-made pieces of code that other people wrote, such as a tool for handling dates, a library for talking to a database, or a set of buttons for a web page. When these pieces are bundled together with a name, a version number, and a description, the bundle is called a package. Packages are the “ingredients” of software.
Each programming ecosystem has its own package style. JavaScript developers use npm packages. .NET developers use NuGet packages. Java developers use Maven packages. Python developers use Python packages, and Rust developers use Cargo crates. Teams can also bundle their own files, such as tools or data, into a general-purpose type called a Universal Package.
The Short Definition
Azure Artifacts lets your organization host these packages in private, access-controlled storage and also lets you reuse packages from public sources such as npmjs or NuGet.org through a single secure location. “Managed” means Microsoft runs the storage and servers, so you do not install or maintain anything. Developers and automated build systems pull the packages they need from your feeds, and publish the packages they create back into those same feeds.
Think of a company library. Staff can borrow books written by outside authors, and they can also deposit reports written by their own colleagues. The librarian keeps every book organized by title and edition, controls who may borrow which shelf, and makes sure old editions are never silently replaced. Azure Artifacts is that library for software packages.
Features, limits, and prices in cloud services change over time. The ideas in this guide are the stable foundation. Always confirm exact numbers, such as free storage allowances, in Microsoft’s current documentation.
2Why Does It Exist? The Problem It Solves
Without a central home for packages, teams run into slow builds, security gaps, and mysterious “works on my machine” problems.
Life Without a Package Home
Picture a team of twenty developers. One keeps a shared code library on a network drive. Another emails a compiled file to a colleague. A third downloads a public package straight from the internet and never records which version she used. Soon nobody knows which version of anything is running in production. When a bug appears, no one can say whether it came from the team’s own code or from an outside package that quietly changed.
There are also outside risks. A public package might be deleted by its author, which has actually broken thousands of builds around the world in the past. A public registry might suffer an outage on the day you need to release. A malicious person might publish a harmful package with a name designed to trick your tools. A central, controlled package home reduces all of these risks.
Imagine every cook in a restaurant buying ingredients from random street stalls each day. Quality varies, nobody tracks suppliers, and if a stall disappears the recipe breaks. A central pantry with approved suppliers, labeled batches, and a stock record fixes all of that at once.
What You Gain
One Source of Truth
Everyone, including build machines, gets packages from the same place, so everyone uses the same versions.
Reliable Builds
Packages from public sources can be saved in your own feed, so a public outage or deletion does not stop your release.
Private Sharing
Teams can share internal code safely without publishing it to the world.
Access Control
You decide who may read, publish, or manage each feed, using the same identity system as the rest of Azure DevOps.
Quality Gates
Views let you mark packages as experimental, tested, or released, so consumers only see what is ready for them.
Traceability
You can see which build produced which package, helping with audits and troubleshooting.
3The Core Building Blocks
Five simple ideas explain almost everything: package, version, feed, upstream source, and view.
Package and Version
A package is a named bundle. Each time its author makes a change and publishes it again, the bundle gets a new version number, such as 1.0.0, 1.1.0, or 2.0.0. Versions let a team say precisely which edition they depend on. A well-known convention called semantic versioning gives the numbers meaning: a change in the first number signals a big change that may break things, the second signals new features, and the third signals small fixes.
Feed
A feed is a container in Azure Artifacts that holds packages and controls who can use them. You can create many feeds, such as one for the whole company and another for a single sensitive project. A feed can hold several package types at once. Developers point their tools at the feed’s address, and the tools then fetch or publish packages there automatically.
Upstream Source
An upstream source is another place a feed can look when it does not already have a package. For example, your feed can be told to also look at the public npm registry. When someone asks your feed for a public package, the feed fetches it, keeps a saved copy, and serves it. Next time, the saved copy is used even if the public site is down.
View
A view is a filtered window onto a feed. A feed starts with three standard views: one that shows everything, one for prerelease packages, and one for release-quality packages. Teams promote a package from one view to the next as it passes tests. People who consume packages can subscribe to the view that matches how stable they want their ingredients to be.
A feed is a warehouse. Upstream sources are the trusted wholesalers the warehouse can order from. Versions are the batch numbers printed on each crate. Views are different shop windows onto the same warehouse: one window shows fresh experimental stock, another shows only goods that passed inspection.
flowchart TD
P1["Public registries - npmjs, NuGet.org, PyPI, Maven Central"] --> U["Upstream sources"]
U --> F["Feed - your private package home"]
B["Your team's builds"] --> F
F --> V1["Local view - everything"]
F --> V2["Prerelease view - testing"]
F --> V3["Release view - approved"]
V3 --> C["Production builds and developers"]
Name feeds after their audience or purpose, such as “company-shared” or “payments-team”, rather than after the tools inside them. A feed holds many package types, and the name should still make sense next year.
4Package Types Supported
Azure Artifacts speaks the native language of the most common programming ecosystems.
Why Native Support Matters
Each ecosystem has its own tools and rules for installing packages. Azure Artifacts behaves like the registry those tools already expect, so developers keep using familiar commands instead of learning something new. The feed simply becomes the address the tool talks to.
NuGet
For .NET libraries and tools. Very common in companies that build with C# and the wider .NET platform.
npm
For JavaScript and TypeScript projects, including web front ends and Node.js services.
Maven
For Java and related languages. Gradle builds can also use Maven-style feeds.
Python
For Python libraries, widely used in data science, automation, and web back ends.
Cargo
For Rust crates, giving Rust teams a private home for internal libraries.
Universal Packages
For anything else: scripts, tools, machine learning files, or large binary assets that do not fit a language package format.
Think of a multilingual post office. Letters arrive in many languages, but the clerk understands each one, so every sender and receiver uses the format they already know. Azure Artifacts is that clerk for package formats.
Packages Versus Pipeline Artifacts
This is a point that confuses many beginners. Azure Pipelines can also store “pipeline artifacts,” which are the files produced by one run of a build, such as a compiled program or a test report. Pipeline artifacts are tied to a specific run and are meant to be handed to later stages of that same run or kept briefly for inspection. Packages in Azure Artifacts, by contrast, are versioned, shared, long-lived building blocks that many different projects consume over time.
| Question | Pipeline Artifacts | Azure Artifacts Packages |
|---|---|---|
| Purpose | Pass build output between stages of one run | Share reusable building blocks across teams and time |
| Lifetime | Tied to a pipeline run and its retention rules | Kept in a feed until policy or people remove them |
| Versioning | By run number | By explicit package version |
| Consumers | The same pipeline or release | Any developer or pipeline with access to the feed |
Teams sometimes use pipeline artifacts as a permanent library and later lose files when run retention expires. If something is meant to be reused by others over time, publish it as a package instead.
5Feeds in Depth: Scope and Organization
Where a feed lives decides who can find it and how it relates to your projects.
Organization-Scoped and Project-Scoped Feeds
Azure DevOps arranges work in two levels. An organization is the top-level account, and inside it you create projects, each usually matching a product or team. Feeds can be created at either level. An organization-scoped feed belongs to the whole organization and can be shared widely. A project-scoped feed belongs to one project and inherits that project’s visibility, so it follows the project’s rules automatically.
Project-scoped feeds are generally the more natural fit for new work because they keep packages beside the code, boards, and pipelines of the project that owns them. Organization-scoped feeds suit shared company libraries that many projects consume.
A company has one central supply room that every department can use, and each department also keeps a cupboard of its own. The central supply room is an organization feed. The department cupboard is a project feed.
Project-Scoped Feeds
- Visibility follows the owning project
- Keeps packages close to related code and pipelines
- Simpler permission thinking for single teams
- Good for public projects that want public packages
Organization-Scoped Feeds
- Best for company-wide shared libraries
- Not tied to any single project
- Needs deliberate permission design so access is not too broad
How Many Feeds Do You Need?
There is no single correct answer, but a few guidelines help. Start with fewer feeds, because every extra feed adds permissions to manage and addresses for developers to remember. Create a separate feed when audiences differ, such as an external-facing feed for packages you give to customers, or when security needs differ, such as a feed that only a small trusted group may publish into. Avoid creating one feed per developer or per package, which quickly becomes confusing.
Single Shared Feed
A small company puts all internal and cached public packages in one feed. Simple to manage, and perfectly fine until different audiences emerge.
Feed Per Product Team
Larger organizations give each product team its own feed so teams control their own publishing rules while still reading from a shared company feed.
Separate Release Feed
Some organizations keep a tightly controlled feed for officially released packages, with only the release pipeline allowed to publish into it.
6Upstream Sources: Safe Access to Public Packages
Upstream sources let one feed serve both your private packages and trusted public ones.
How Upstreaming Works
When upstream sources are enabled, a developer needs only one address. If they request a package that your feed already holds, they receive it immediately. If the package is not there, the feed asks its upstream sources, such as the public npm registry, downloads the package, stores a copy, and delivers it. From then on, that exact version lives in your feed.
This saved copy is the key benefit. If the public registry goes down, or the package author deletes the package, your builds keep working because your feed still has the version you already used.
A neighborhood grocer who also stocks things from the big wholesale market. The first time you ask for an unusual spice, the grocer orders it, then keeps some on the shelf. The next customer gets it instantly, even if the wholesale market is closed that day.
sequenceDiagram
participant D as Developer or Build
participant F as Your Feed
participant P as Public Registry
D->>F: Request package version
F->>F: Is it already saved in the feed?
F->>P: Not saved, so ask the upstream source
P->>F: Returns package
F->>F: Saves a copy
F->>D: Delivers package
D->>F: Later request for same version
F->>D: Delivered from saved copy, no public call needed
The Dependency Confusion Risk
A sneaky attack called dependency confusion works like this. Suppose your company has an internal package named “acme-billing-tools” that exists only in your private feed. An attacker discovers the name and publishes a package with the same name, but a higher version number, on a public registry. A tool that blindly looks in both places might choose the higher version, which is the attacker’s package, and install harmful code into your build.
Azure Artifacts includes upstream behavior controls designed to reduce this risk. When a package name is already published in your own feed, the feed can block versions of that same name coming from public upstream sources. This way internal names stay internal, and only the version your team published is served.
Never configure your developers’ tools to look at your private feed and a public registry as two separate, equal sources. Route everything through a single feed with upstream sources, and use the upstream behavior protections, so the feed decides which source is allowed to supply each package name.
Other Kinds of Upstream
Besides public registries, a feed can use another Azure Artifacts feed as an upstream source. This lets a company build a chain: team feeds read from a company feed, which reads from the public registries. The shared company feed becomes the one place where public packages are reviewed and cached, and every team benefits.
Put upstream sources on a central company feed and let team feeds chain to it. Security teams then have a single place to watch which outside packages enter the organization.
7Views and Promotion: Marking Quality
Views let you share packages at different levels of readiness without copying them.
The Three Standard Views
Every feed begins with three views. The first, commonly named Local, shows everything in the feed, including packages saved from upstream sources. The second, Prerelease, is meant for packages that are still being tested. The third, Release, is meant for packages that have passed testing and are approved for general use. You can also create custom views, for example one named after a particular product line.
Promotion in Plain Words
To promote a package means to add a particular version to a higher view. Nothing is copied or rebuilt; the same package simply becomes visible through the new window. A typical story goes like this. A build publishes version 2.4.0-beta1. Testers use the Prerelease view and confirm it works. A release manager promotes the same package to the Release view. Developers who only subscribe to Release now see it, while those who wanted early access already had it.
Publish
A pipeline builds the code and publishes a new package version into the feed.
Test in Prerelease
Early adopters and automated tests consume the package from the prerelease view and check that it behaves.
Approve
An owner or an approval step confirms the package meets the quality bar.
Promote to Release
The same package version is added to the release view, instantly visible to everyone who consumes only approved packages.
A bakery tests a new loaf on staff first, then in a small corner of the shop labeled “new today,” and finally places it in the main display once customers like it. It is the same loaf the whole time; only the shelf changes.
Because the same package is promoted rather than rebuilt, what you tested is exactly what you release. Rebuilding for release would risk producing a slightly different result from the one that was tested.
Letting every developer promote packages to the release view. Restrict promotion rights to a small group or to an automated pipeline step, so the release view keeps its meaning.
8How Packages Flow Through the Service
Following one package from a developer’s laptop to production shows where every control sits.
The Journey in Plain Words
Suppose a developer finishes improving a shared logging library. She commits the code to a repository. A pipeline notices the change, builds the library, runs its tests, and packs the result into a package with a new version number. The pipeline then authenticates to Azure Artifacts and publishes the package to the team’s feed. Azure Artifacts checks that the pipeline’s identity has permission to publish, makes sure the version number does not already exist, stores the package, and records which build produced it.
Other teams that depend on the library then update to the new version. Their tools ask the feed for it. The feed checks that each caller has permission to read, and delivers the package. If a team wants an older version, the feed still has it.
flowchart LR
A["Developer commits code"] --> B["Pipeline builds and tests"]
B --> C["Pipeline packs a new version"]
C --> D["Publish to feed with permission check"]
D --> E["Feed stores package, rejects duplicate versions"]
E --> F["Prerelease view"]
F --> G["Promote to Release view"]
G --> H["Other teams restore the package"]
Immutability: Published Means Permanent
A rule that surprises beginners: once a version is published, its contents can never be changed or replaced, and the same version number cannot be reused. This is called immutability. If you discover a mistake in version 1.2.0, you cannot fix it in place; you must publish 1.2.1. This might feel strict, but it protects everyone. A consumer who tested against 1.2.0 can be certain that 1.2.0 will always mean exactly the same bytes.
Think of a printed and numbered edition of a textbook. If an error is found, the publisher cannot sneak into every library and alter the old copies; they release a corrected new edition. Readers always know which edition they hold.
What You Can Do With a Published Version
Promote
Make a version visible in a higher view such as Release.
Deprecate
Mark a version as discouraged, with a message steering people to a better one, while leaving it available for existing users.
Unlist
Hide a version from search results while still allowing builds that already reference it to continue.
Delete
Move a version to a recycle bin where it can be recovered for a limited period before permanent removal.
9Permissions and Identity
Strong access control means the right people and machines can read or publish, and no one else.
Who Can Do What
Feeds use a small set of roles. A Reader can see and download packages. A Collaborator can do that and also save packages coming from upstream sources. A Contributor can publish new package versions. An Owner can do everything, including changing feed settings and permissions. You grant roles to people, groups, and also to automated identities.
| Role | Can Read | Can Use Upstream | Can Publish | Can Manage Feed |
|---|---|---|---|---|
| Reader | Yes | No | No | No |
| Collaborator | Yes | Yes | No | No |
| Contributor | Yes | Yes | Yes | No |
| Owner | Yes | Yes | Yes | Yes |
In a library, a visitor may read books, a member may request books from other libraries, a staff member may add new books, and the head librarian may change the rules. The same pattern, from least to most power, applies to feed roles.
Machines Need Permissions Too
Pipelines are not people, but they must publish and restore packages. Azure DevOps gives pipelines build service identities, and you grant these identities the roles they need on a feed. A build that only restores packages needs the reader-style access. A build that publishes needs contributor access. Giving every pipeline owner access is a common shortcut that creates risk.
How People and Tools Prove Who They Are
Developers working on their own computers typically sign in through a credential helper provided for their package tool, which uses their organizational account and avoids storing long-lived secrets in files. Where a token is unavoidable, a personal access token can be created with a limited scope and an expiry date. A personal access token is like a temporary key card that works only for specific doors and expires on a date you choose.
Pasting long-lived tokens into configuration files that get committed to a repository. Anyone who can see the repository can then use the token. Prefer credential helpers and pipeline-provided identities, and set short expiry dates on any token you must create.
Grant to Groups, Not Individuals
Assign roles to groups so that people joining or leaving the team are handled by group membership.
Use Least Privilege
Give each person and pipeline only the role they need, and keep owners to a small number.
Prefer Short-Lived Credentials
Use credential helpers and pipeline identities. If tokens are required, limit their scope and expiry.
Review Access Regularly
Check feed permissions every few months and remove access that is no longer needed.
10Working With Azure Pipelines
Azure Artifacts and Azure Pipelines are designed to cooperate, so packages flow automatically through your delivery process.
Two Jobs for Pipelines
Pipelines interact with feeds in two ways. In the first, a pipeline consumes packages: before building, it restores the packages your code depends on from the feed, so every build uses the same trusted sources. In the second, a pipeline produces packages: after building and testing, it packs the output and publishes it to the feed for others to use.
A factory both receives parts from suppliers and ships finished goods to customers. The pipeline is the factory floor. The feed is the loading dock where parts arrive and finished goods leave.
Versioning Strategies
Because published versions are permanent, pipelines need a plan for assigning new version numbers. Two common approaches exist. In the first, humans choose version numbers deliberately and increase them following semantic versioning when they release. In the second, the pipeline automatically adds a build number or date to each version, which guarantees uniqueness for every build and is common for prerelease packages. Many teams combine them: automatic suffixes for work-in-progress builds, and deliberate numbers for official releases.
Automatic Version Suffixes
- Every build gets a unique, never-clashing version
- No manual number juggling for frequent builds
- Easy to trace a package back to its build
Trade-offs
- Feeds can fill up quickly with many small versions
- Consumers need guidance on which versions are meant for them
- Needs retention rules to keep clutter in check
A Healthy Delivery Flow
Restore From the Feed
The build fetches its dependencies only from the approved feed, which is already protected by upstream rules.
Build and Test
The code is compiled and tested. Failing builds never publish anything.
Publish a Prerelease
On success, a prerelease package goes into the feed and appears in the prerelease view.
Promote After Approval
When checks and approvals pass, the very same package is promoted to the release view.
Only publish from builds on your main, trusted branches. Letting every experimental branch publish creates clutter and could let unreviewed code into a shared feed.
11Universal Packages and Large Files
Not everything fits a language package format, and Universal Packages cover the rest.
What They Are
A Universal Package is a versioned bundle of files with no language-specific rules. You choose a name, a version, and a folder of content, and the service stores it. It is designed to handle large files efficiently and to avoid re-uploading content that has not changed between versions.
A language package is like a labeled box shaped for one kind of tool. A Universal Package is a plain shipping crate: it can hold anything, and the warehouse still tracks its label and version.
Common Uses
Shared Tooling
A team bundles a set of command-line tools or scripts so every build machine uses the same versions.
Machine Learning Assets
Data science teams version trained models or datasets so experiments can be reproduced precisely.
Game and Media Assets
Studios store large art or audio bundles that many builds need, avoiding bloating the code repository with huge binary files.
Installer and Deployment Bundles
Teams package installers or deployment content so release pipelines pull an exact, known version.
Source repositories are best for text that changes often. Large binary files make repositories slow and heavy. Placing them in versioned packages keeps repositories light and gives each large file a clear version.
12Security and Supply Chain Protection
Packages are part of your software supply chain, so protecting them protects everything built from them.
What Is a Supply Chain Attack?
Your software is assembled from many outside ingredients. A supply chain attack targets the ingredients rather than your own code. An attacker might slip harmful code into a popular package, publish a lookalike package with a name that is one letter different, or hijack the account of a package author. Because builds pull ingredients automatically, a bad ingredient can reach thousands of systems before anyone notices.
If someone tampers with the flour at the mill, every bakery using that flour is affected, no matter how careful the bakers are. Protecting the pantry means checking what flour enters it in the first place.
Layers of Defense
Single Entry Point
All public packages enter through one feed with upstream sources, so there is one place to monitor and control.
Upstream Behavior Controls
Block outside versions of package names that your organization already publishes internally.
Immutable Versions
Published versions cannot be altered, so a package you tested cannot silently change later.
Controlled Publishing
Only trusted identities and pipelines can publish, and only from trusted branches.
Dependency Scanning
Scanning tools in your pipelines can compare your dependencies against known vulnerability lists and warn you.
Pinned Versions
Specifying exact versions or using lock files means builds do not accidentally pick up a surprise new version.
Saving a public package in your feed does not make it safe. The feed preserves what was downloaded; it does not judge whether the package is trustworthy. Combine the feed with scanning and sensible review of new dependencies.
Audit and Visibility
Azure DevOps records activity such as permission changes and package actions in its audit features, which helps answer questions like “who promoted this package?” or “who changed this feed’s settings?” Regularly reviewing these records is a practical habit for security teams.
13Retention, Cleanup, and Recovery
Feeds grow over time, and a little tidying keeps them fast, understandable, and affordable.
Why Cleanup Matters
Automated builds can publish a new package version many times a day. After a year, a single package might have thousands of versions, most of them long out of date. Without cleanup, searching becomes confusing, and storage use and cost keep rising.
Retention Policies
A retention policy is an automatic rule that removes old package versions. Typical settings include a maximum number of versions to keep per package, and a number of days to keep packages that were recently downloaded. Packages that are promoted into a view are generally protected from automatic cleanup, which means versions you have officially released are kept safe while experimental builds are trimmed.
A bakery tidies the display case each evening, removing day-old pastries but keeping the award-winning specialties on a protected shelf. The retention policy is the evening tidy-up, and promotion to a release view is the protected shelf.
The Recycle Bin
When a package version is deleted, it is not erased immediately. It moves to a recycle bin where it can be restored for a limited time, which the documentation describes as a matter of weeks. After that period it is permanently removed. This is a safety net for human mistakes, but you should not rely on it as a backup strategy.
Decide What to Keep
Agree on how many versions per package matter and how long unused versions should be retained.
Turn On Retention
Set the feed’s retention policy so cleanup happens automatically instead of relying on memory.
Protect Released Packages
Promote officially released versions to a view so cleanup rules leave them alone.
Use Recovery Carefully
If something is deleted by mistake, restore it from the recycle bin quickly, before the recovery period ends.
Setting very aggressive retention on a feed that production builds depend on. If a product still references an old version that gets cleaned up, its build can suddenly fail. Make sure versions in use are promoted or otherwise protected.
14Storage, Cost, and Monitoring
Understanding what you pay for makes it easy to keep costs predictable.
How Costs Work
Azure Artifacts offers a free allowance of storage for each organization, and usage beyond that allowance is billed according to published pricing tiers. At the time of writing, the free allowance was a few gibibytes, but you should confirm the current figure and pricing in Microsoft’s documentation. Storage includes all the package types in all your feeds, including copies saved from upstream sources.
Keeping an Eye on Usage
Azure DevOps shows storage usage in its settings, broken down so you can see which feeds and packages use the most. Reviewing this regularly helps you find the “heavy” feeds, such as one that receives large Universal Packages on every build. Often a small change, such as lowering retention for prerelease packages, brings usage down noticeably.
Check Storage Monthly
A quick look at usage reports prevents surprises on the bill.
Find the Biggest Feeds
A few feeds often account for most of the storage. Focus cleanup there first.
Tune Retention
Shorter retention for prerelease builds and longer for released ones balances cost and safety.
Watch Large Packages
Universal Packages with big files can grow storage quickly if every build publishes a new one.
Avoid publishing a new package from every tiny build on every branch. Publishing only from important builds keeps both storage and clutter under control.
15Advantages and Trade-offs
No tool is perfect. Seeing both sides helps you decide where Azure Artifacts fits.
Advantages
- Many package types managed in a single service
- Tight integration with Azure Pipelines, Repos, and permissions
- Upstream sources keep builds working during public outages
- Views provide a built-in quality and release workflow
- Fully managed, with no servers to maintain
- Immutable versions give reproducible builds
Disadvantages / Trade-offs
- Best value for teams already using Azure DevOps
- Storage beyond the free allowance adds cost
- Permissions and scopes need careful planning as organizations grow
- Immutability means mistakes require new versions rather than quick fixes
- Cached public packages are not automatically vetted for safety
Comparing Approaches to Hosting Packages
| Approach | Strengths | Weaknesses |
|---|---|---|
| Azure Artifacts | Integrated with Azure DevOps, multi-format, managed, upstream caching | Tied to the Azure DevOps ecosystem, storage costs beyond free tier |
| Public registries only | Free and simple for open-source consumption | No private sharing, exposed to outages and deletions |
| Shared network folder | Quick to set up | Weak access control, poor versioning, little traceability |
| Self-hosted package server | Full control over everything | You maintain, patch, secure, and back it up yourself |
If your team already builds and releases with Azure DevOps, Azure Artifacts is usually the natural choice because it shares identity, permissions, and pipelines. Teams standardized on another platform may prefer that platform’s own package service.
16Design Patterns and Anti-Patterns
Teams repeat the same successes and the same mistakes. Learn from both.
Patterns Worth Copying
Single Gateway Feed
Route all public package access through one governed feed with upstream sources, so there is a single place to apply protections and monitor what enters the organization.
Promote, Never Rebuild
Build once, publish once, and promote the same package through prerelease and release views. What you tested is exactly what you ship.
Pipeline-Only Publishing
Allow only pipelines running trusted branches to publish into the release feed. Humans consume; automation produces.
Retention With Protection
Trim old prerelease builds automatically while protecting versions promoted to release views.
Anti-Patterns to Avoid
Problem
Developers configure their tools to read from both the private feed and a public registry as separate, equal sources.
Why It’s Harmful
This opens the door to dependency confusion, where an attacker’s public package with a higher version number replaces your internal package during a build.
Correct Approach
Use a single feed with upstream sources and enable the upstream behavior controls so internal package names are never served from public sources.
Problem
Everyone is given owner or contributor access to every feed “to avoid delays.”
Why It’s Harmful
Anyone can then publish, promote, or delete packages. A mistaken or malicious action can break builds across many teams, and it becomes difficult to know who did what.
Correct Approach
Assign roles to groups, give most people reader access, restrict publishing to pipelines and a small set of maintainers, and review permissions regularly.
Problem
Publishing from every branch and every commit with no cleanup rules.
Why It’s Harmful
The feed fills with thousands of throwaway versions, search becomes confusing, consumers cannot tell which versions matter, and storage costs climb.
Correct Approach
Publish from trusted branches, label prerelease versions clearly, and apply retention policies while protecting released versions.
Problem
Long-lived personal access tokens are saved in configuration files committed to source repositories.
Why It’s Harmful
Anyone with access to the repository, including past contributors or leaked copies, can use the token to read or even publish packages.
Correct Approach
Use credential helpers and pipeline identities, keep any necessary tokens narrowly scoped and short-lived, and store secrets in a secure vault.
17Real-World Use Cases
Across industries, teams use Azure Artifacts to make software delivery safer and smoother.
Shared Internal Libraries
A bank maintains common libraries for logging, security checks, and customer data formats. Dozens of application teams consume the same tested versions instead of copying code between projects.
Protecting Builds From Public Outages
A retailer routes all public JavaScript and .NET dependencies through its feed. When a public registry has a bad day before a major sale, builds continue using saved copies.
Controlled Release Process
A healthcare software company publishes every build as prerelease. Quality assurance tests those, and only after sign-off does the release manager promote the same package to the release view used for production.
Sharing Packages With Partners
A software vendor creates a feed for customers who integrate with its tools. Customers receive read access to just that feed and nothing else in the organization.
Machine Learning Reproducibility
A data science team publishes trained models and datasets as Universal Packages, so an experiment from last year can be reproduced with exactly the same inputs.
Migrating From Shared Folders
A growing company retires its network folders full of mysterious compiled files and moves them into feeds with clear names, versions, and permissions, making builds repeatable for the first time.
18Best Practices and Common Mistakes
A short checklist that captures the lessons from earlier chapters.
Best Practices
Centralize Public Access
Send all public package requests through a governed feed with upstream sources and the upstream protections enabled.
Use Clear Versioning
Follow semantic versioning for releases and use clear suffixes for prerelease builds.
Promote, Do Not Rebuild
Use views so the exact package you tested is the one you release.
Apply Least Privilege
Give groups and pipelines only the roles they need, and keep feed owners few.
Automate Cleanup
Set retention policies early, and protect released versions through promotion.
Scan Your Dependencies
Add vulnerability scanning to pipelines so risky packages are flagged before release.
Document the Feed Map
Write down which feeds exist, who owns them, and which teams should use which, so newcomers are never guessing.
Common Mistakes
Pipeline artifacts expire with their runs. Anything meant for long-term reuse belongs in a versioned package.
A new pipeline fails to restore or publish because its build identity was never granted access to the feed. Check feed permissions when setting up each pipeline.
Teams are sometimes surprised that a published version cannot be replaced. Plan for this by never reusing version numbers and by publishing a corrected new version instead.
Without periodic review, a feed can quietly grow until the bill surprises you. Check storage usage regularly and tune retention.
19Getting Started: A Gentle Roadmap
You can begin with a few simple steps and grow from there.
Choose Your Scope
Decide whether the first feed should belong to a single project or to the whole organization.
Create a Feed
Create a feed with a clear name, and enable upstream sources if you want it to serve public packages too.
Connect Your Tools
Use the connect instructions in the feed screen to point your package tool at the feed, and sign in through the credential helper.
Set Permissions
Grant reader access to consumers, contributor access to your publishing pipeline, and keep owners few.
Publish a First Package
Have a pipeline build a small internal library and publish it, then consume it from another project.
Add Views and Retention
Start using prerelease and release views, and turn on retention rules before the feed grows large.
20Frequently Asked Questions
No. Pipeline artifacts are files produced by a particular build run and are tied to that run. Azure Artifacts hosts versioned packages in feeds that many projects can reuse over a long time.
Azure Artifacts is a service within Azure DevOps, so you need an Azure DevOps organization. Your developers can still use their own tools and editors, and your builds can come from Azure Pipelines or other systems that can authenticate to a feed.
If your feed had already saved a copy through an upstream source, your builds continue to work because they use the saved copy. This is one of the biggest benefits of upstream sources.
No. Published versions are immutable. To fix a problem, publish a new version, and optionally deprecate or unlist the faulty one so people move on.
A view is a filtered window onto a feed. Teams use views to show packages at different levels of readiness, such as prerelease and release, so consumers only see what is appropriate for them.
Route all package access through one feed with upstream sources and enable the upstream behavior controls, which block public versions of package names that already exist in your own feed.
Ideally only trusted pipelines running on protected branches and a small group of maintainers. Most developers should have reader access and consume packages.
The feed stores and serves packages; it does not by itself guarantee they are safe. Add dependency scanning and sensible review of new dependencies to your pipelines, and follow Microsoft’s current guidance on available security features.
Deleted package versions go to a recycle bin and can be restored for a limited time. Act quickly, because after the recovery period they are permanently removed.
Each organization receives a free storage allowance, and storage beyond that is billed according to Microsoft’s published pricing. Check the current allowance and prices in the official documentation, since they can change.
Yes. A single feed can hold several package types at the same time, such as npm, NuGet, and Python packages. Create separate feeds only when audiences or security needs differ.
The most common cause is that the pipeline’s build identity does not have the right role on the feed. Check the feed permissions for that identity, and confirm the pipeline is pointed at the correct feed.
21Summary and Key Takeaways
Azure Artifacts gives your organization a single, managed pantry for the software packages its products are built from. You create feeds, choose their scope, connect your tools, and let pipelines publish and restore packages automatically. Upstream sources save copies of public packages so your builds survive outages and deletions, while views let you mark packages as prerelease or release without rebuilding anything. Roles and identities decide who may read, publish, and manage, and retention policies keep feeds tidy and affordable.
Success comes from keeping things simple at first, routing public access through a governed gateway feed, protecting internal names, restricting who can publish, and reviewing permissions and storage as habits. The service stores and serves your ingredients; your design and discipline decide how trustworthy the finished software will be.
Key Takeaways
- It is a managed home for packages — Azure Artifacts hosts NuGet, npm, Maven, Python, Cargo, and Universal Packages inside Azure DevOps.
- Feeds, upstream sources, and views are the core — feeds hold packages, upstream sources bring in public ones safely, and views mark readiness.
- Packages are not pipeline artifacts — reusable, versioned building blocks belong in feeds, while run-specific outputs belong in pipeline artifacts.
- Published versions are immutable — you promote, deprecate, or publish a new version rather than editing an old one, which keeps builds reproducible.
- Protect against supply chain risks — use a single gateway feed, upstream behavior controls, scanning, and pinned versions to defend against dependency confusion and tampering.
- Least privilege protects everyone — grant roles to groups, let pipelines publish, prefer short-lived credentials, and review access regularly.
- Tidy feeds stay fast and affordable — apply retention policies, protect released versions through promotion, and watch storage usage.