<p>There's repository managers and Universal package repository managers (UPM). </p>

<p>UPM’s can store all your build artifact for Jenkins, teamcity etc. and can generally also act as repository mangers for many different types of binary artifacts Maven, npm, NuGet and more. </p>

<p>These would be tools like <a href="https://www.jfrog.com/artifactory/" rel="noreferrer">Jfrog Artifactory</a>, <a href="http://inedo.com/proget" rel="noreferrer">Inedo ProGet</a>, and <a href="https://www.sonatype.com/nexus-repository-oss" rel="noreferrer">Sonatype Nexus</a>. </p>

<p>A pretty decent comparison is here: <a href="https://binary-repositories-comparison.github.io/" rel="noreferrer">https://binary-repositories-comparison.github.io/</a> </p>

CC BY-SA 3.0
2017-04-04T16:12:57.540Z
2017-04-04T16:12:57.540Z
Karl Harnagy
<p>During development you generate a fair amount of different artifacts. These might include:</p>

<ul>
<li>The source code</li>
<li>The compiled application</li>
<li>A deployable package</li>
<li>Documentation</li>
</ul>

<p>and potentially others as well</p>

<p>While you could use a source control system to store all of them, it's usually massively inefficient, as source control systems are usually designed to handle text based files, and not binary files. You might be able to use them as a simple storage mechanism, if most of your releases are text based, and you don't have to store a lot of binary data.</p>

<p>Artifact repositories however are designed to store all kinds of files, including binary ones. This includes anything from zipped up source codes, to build results, to things like docker images as well. Also, they usually not only store these artifacts but also help manage them using various additional functions, for example:</p>

<ul>
<li>Versioning support: properly store some metadata, like when each artifact was built, what their version number is, store their hashes, etc.</li>
<li>Retention: make sure you only keep the important artifacts, and automatically delete ones that are only snapshots / not needed anymore, etc. based on various criteria you can set up</li>
<li>Access control: set up who can publish and who can download the various artifacts</li>
<li>Promotion: ability to promote artifacts. For example you can have snapshot artifacts with a short retention period on a server near your coders, and a separate repository near the live servers, where only artifacts that have been deemed deployable appear. This also includes support for various version channels, and moving artifacts between them (like promoting a specific version from beta to stable).</li>
<li>Act as a native repository for the artifacts. Meaning you can use it as the main repository for maven, rubygems, docker, etc. This can also include caching of artifacts from the official repositories as well.</li>
</ul>

CC BY-SA 3.0
2017-03-10T08:59:37.563Z
May worth adding the 'channel' capability over the Versionning support, having the ability to have some machine targeting the latest release in channel "develop" and prod machine targeting a specific version in channel "stable".
Tensibai
CC BY-SA 3.0
2017-03-10T15:19:49.110Z
@Pierre.Vriens added some small comments, but maybe it can be addressed in a separate Question as well
SztupY
CC BY-SA 3.0
2017-03-10T15:39:56.743Z
merci, but just in case, [here](http://devops.stackexchange.com/q/466/40) is your chance to further address my additional comment ...
Pierre.Vriens
CC BY-SA 3.0
2017-11-01T12:23:47.150Z
Does it makes sense to also keep track of configuration files or fixtures in these kind of repositories?
tutuca
CC BY-SA 4.0
2017-03-09T16:13:04.370Z
2019-11-15T09:09:26.987Z
2019-11-15T09:09:26.987Z
SztupY
<p>What is an artifact repository?  If it's just a place to store files, can't I just use a source control system?</p>

<terminology><continuous-delivery><continuous-deployment><artifacts>
What is an artifact repository?
Dave Swersky
# What is an artifact repository?

(Asked by: username_0 on 2017-03-09)

What is an artifact repository? If it's just a place to store files, can't I just use a source control system?

**Tags:** terminology, continuous-delivery, continuous-deployment, artifacts


---

## 2 answers

### Answer by username_2 on 2017-03-09. Score: 40 | Accepted answer

During development you generate a fair amount of different artifacts. These might include:

* The source code
* The compiled application
* A deployable package
* Documentation

and potentially others as well

While you could use a source control system to store all of them, it's usually massively inefficient, as source control systems are usually designed to handle text based files, and not binary files. You might be able to use them as a simple storage mechanism, if most of your releases are text based, and you don't have to store a lot of binary data.

Artifact repositories however are designed to store all kinds of files, including binary ones. This includes anything from zipped up source codes, to build results, to things like docker images as well. Also, they usually not only store these artifacts but also help manage them using various additional functions, for example:

* Versioning support: properly store some metadata, like when each artifact was built, what their version number is, store their hashes, etc.
* Retention: make sure you only keep the important artifacts, and automatically delete ones that are only snapshots / not needed anymore, etc. based on various criteria you can set up
* Access control: set up who can publish and who can download the various artifacts
* Promotion: ability to promote artifacts. For example you can have snapshot artifacts with a short retention period on a server near your coders, and a separate repository near the live servers, where only artifacts that have been deemed deployable appear. This also includes support for various version channels, and moving artifacts between them (like promoting a specific version from beta to stable).
* Act as a native repository for the artifacts. Meaning you can use it as the main repository for maven, rubygems, docker, etc. This can also include caching of artifacts from the official repositories as well.

> **Comments:**
> **username_3**: May worth adding the 'channel' capability over the Versionning support, having the ability to have some machine targeting the latest release in channel "develop" and prod machine targeting a specific version in channel "stable".  
> **username_2**: @username_4 added some small comments, but maybe it can be addressed in a separate Question as well  
> **username_4**: merci, but just in case, [here](http://devops.stackexchange.com/q/466/40) is your chance to further address my additional comment ...  
> **username_5**: Does it makes sense to also keep track of configuration files or fixtures in these kind of repositories?  

---

### Answer by username_1 on 2017-04-04. Score: 7

There's repository managers and Universal package repository managers (UPM).

UPM’s can store all your build artifact for Jenkins, teamcity etc. and can generally also act as repository mangers for many different types of binary artifacts Maven, npm, NuGet and more.

These would be tools like [Jfrog Artifactory](https://www.jfrog.com/artifactory/), [Inedo ProGet](http://inedo.com/proget), and [Sonatype Nexus](https://www.sonatype.com/nexus-repository-oss).

A pretty decent comparison is here: <https://binary-repositories-comparison.github.io/>


---

