<p><strong>An artifact</strong></p>
<p>Is something that is produced/generated/crafted out of a specific process</p>
<blockquote>
<p>Jar out of a Java project build.</p>
<p>Question out of your mind</p>
<p>Car out of a factory</p>
<p>New song</p>
</blockquote>
<p><strong>A repository</strong></p>
<p>Is a receptacle where things are persisted</p>
<blockquote>
<p>Github for a Java project.</p>
<p>StackExchange for your daunting questions</p>
</blockquote>
<p>IN THEORY, an <strong>Artifact</strong>-<em>ory</em> would be a repository of artifact where they are persisted and managed throughout their life cycle.</p>
<p>In the context of DevOps, Artifactory is a product that manages binary artifacts. It stores and manages different types (Jar, Python and npm packages, etc...) that you produce out of your builds and re-use at compile or deployment time.</p>

CC BY-SA 4.0
2018-08-20T20:46:31.113Z
interesting explanation, merci!
Pierre.Vriens
CC BY-SA 4.0
2018-08-21T02:04:51.380Z
ca me fait plaisir!
gmolaire
CC BY-SA 4.0
2018-08-20T20:05:06.327Z
2019-05-13T13:46:10.700Z
2020-06-18T08:28:10.803Z
gmolaire
<p>The way it helped me understand initially, the difference between source code repository and binary repository was to think of it like:
* Github or Bitbucket is useful to maintain all 'code'
* Jfrog Artifactory is useful to maintain the built 'binary'
At least till I was comfortable with these terms!</p>

<p>Also, the importance of Artifactory can be understood in relation to the philosophy of DevOps to "Build once, Deploy always". It goes a long way in Continuous Integration to build your binary once, put it into Artifactory  and then call it from there to deploy into all of the different environments. That way, we are sure that the code that works in Dev is the one pushed to Prod and will work there.</p>

CC BY-SA 4.0
2018-08-20T20:46:47.313Z
interesting explanation, merci!
Pierre.Vriens
CC BY-SA 4.0
2018-08-20T01:20:58.463Z
2018-08-20T01:20:58.463Z
Karthik Venkatesan
<p>Artifactory is a <a href="https://en.wikipedia.org/wiki/Binary_repository_manager" rel="noreferrer">Binary Repository Manager</a> product from <a href="https://www.jfrog.com/" rel="noreferrer">Jfrog</a>. </p>

<p>You're right - being a binary repository manager it is typically used to manage storage of <a href="/questions/tagged/artifacts" class="post-tag" title="show questions tagged &#39;artifacts&#39;" rel="tag">artifacts</a> generated and used in the software development process.</p>

<p>From <a href="https://www.jfrog.com/artifactory/" rel="noreferrer">Artifactory's main webpage</a>:</p>

<blockquote>
  <p>As the first, and only, universal Artifact Repository Manager on the
  market, JFrog Artifactory fully supports software packages created by
  any language or technology.</p>
  
  <p>...</p>
  
  <p>...Artifactory provides an end-to-end, automated and bullet-proof
  solution for tracking artifacts from development to production.</p>
</blockquote>

<p>The usages you mentioned suggest it may be popular enough for a <a href="https://en.wikipedia.org/wiki/Generic_trademark" rel="noreferrer">generic trademark</a> in DevOps.</p>

CC BY-SA 3.0
2017-08-31T17:03:41.487Z
Merci Dan, you're somehow confirming that an Artifactory is like a combination of the words **Artifac**ts with Reposi**tory**. The additional question I wonder about is this: what about artifacts that are used in production, but which are not binaries, such as PHP code, CSS files, bash scripts, etc?
Pierre.Vriens
CC BY-SA 3.0
2017-08-31T18:04:14.537Z
For application code they have source code versioning systems like cvs, svn, git, mercurial.. And for configuration code, configuration management and distribution systems, like puppet, chef, ansible, salt..
Ta Mu
CC BY-SA 3.0
2017-08-31T18:20:04.513Z
@Pierre.Vriens I didn't use to think about it this way, somehow "factory" always came to mind first :) But I totally see it now. Thanks!
Dan Cornilescu
CC BY-SA 3.0
2017-08-31T18:50:12.567Z
@J.Doe merci for that addition, and just to further extend your comment ... on mainframes they have tools like "ChangeMan ZMF", "Endevor SCM", etc. These tools are used for all the functions you mentioned (versioning, distribution, etc, but also for workflow, security, etc related to all that).
Pierre.Vriens
CC BY-SA 3.0
2017-08-31T19:17:59.410Z
So if we only reinvent msinframes what could be wrong with them?!
Ta Mu
CC BY-SA 3.0
2017-09-01T01:32:49.243Z
.. And, for container storage you can use the public Docker Hub or its private form, docker registry
Ta Mu
CC BY-SA 4.0
2020-07-21T20:24:24.800Z
"The additional question I wonder about is this: what about artifacts that are used in production, but which are not binaries, such as PHP code, CSS files, bash scripts, etc?" - I think this portion moves away from your original question and is more on the lines of "How do I use" rather than "What is". Also, I feel that each of those use cases can (and should?) be a question in their own right.
kapad
CC BY-SA 4.0
2020-07-23T15:57:12.127Z
@kapad Just fire a new question...
Dan Cornilescu
CC BY-SA 3.0
2017-08-31T16:15:15.700Z
2017-08-31T16:15:15.700Z
Dan Cornilescu
<p>I think complicating things is what everybody is getting appreciated for nowadays. I will try to answer this question in short .</p>
<p>Source Repository is used for storing code and its versions, while artifactory is used for storing the executable programs that are outputs of those code [ binaries - dll, jar, war, ear, msi, exe files etc.]</p>
<p>Now the reason why you would want to place them separately in a repo which is different from your code could be many - right from secure access, hacking threat, preventing unintentional downloads of malicious/modified jars or to simply have a separate avenue for the clients who will be using your binaries to develop their code.</p>
<p>The technology of SCM could have divulged itself into creating 2 kind of users ( one with developer privileges who will be able to access the source code and another as a client who will just be able to access binaries). But it did not take that route! So now we have artifactories.</p>

CC BY-SA 4.0
2020-01-14T23:24:05.070Z
A major reason for a binary storage (whether it is a repository or not) is that you can not create 'text diff patches' of the changes in a binary, as you can for source.  That is you can not store 'diff's' to save space and let users see how the text file (or source code) changed.    Git for example had major problem with 'versions' of 'formated documents', though I don't know if that is still the case.
anthony
CC BY-SA 4.0
2020-01-30T18:58:53.260Z
@anthony, Why would you want "text diff patches" in case of executable jars? The whole reason you get to deal with binary is that you dont bother about its code.
Spear A1
CC BY-SA 4.0
2019-03-31T16:58:43.900Z
2022-09-16T03:32:25.640Z
2022-09-16T03:32:25.640Z
Spear A1
<p><a href="https://www.jfrog.com/artifactory/" rel="noreferrer">Artifactory</a> is a product by JFrog that serves as a <a href="https://en.wikipedia.org/wiki/Binary_repository_manager" rel="noreferrer">binary repository manager</a>.  That said very often one will use a 'artifactory' as a synonym of the more general binary repository, much like many people use Frigidaire or fridge to denote the refrigerator regardless if it is a Frigidaire brand or not.</p>

<p>The binary repository is a natural extension to the source code repository, in that it will store the outcome of your build process, often denoted as artifacts.  Most of the times one would not use the binary repository directly but through a package manager that comes with the chosen technology.</p>

<p>In most cases these will store individual application components that can later be assembled into a full product - thus allowing a build to be broken in smaller chunks, making more efficient use of resources, reducing build times, better tracking of binary debug databases etc.</p>

<p>Here are some of the most popular package managers that can be managed using a binary repository:</p>

<ul>
<li>Java: jar, ear, war etc has <a href="https://maven.apache.org/" rel="noreferrer">Maven</a> and the official <a href="https://search.maven.org/" rel="noreferrer">MavenCentral</a>.  There are many other package managers that will use the maven binary repository format as well (<a href="http://ant.apache.org/ivy/" rel="noreferrer">ivy</a>, <a href="https://gradle.org/" rel="noreferrer">gradle</a> etc).</li>
<li>.Net: <a href="https://www.nuget.org/" rel="noreferrer">nuget</a> for .NET components (DLL and EXE) but can also be used as a distribution mechanism under windows thorugh systems like <a href="https://chocolatey.org/" rel="noreferrer">Chocolatey</a>.  Newer versions of Powershell can also leverage this to distribute powershell modules though the <a href="https://www.powershellgallery.com/" rel="noreferrer">powershell gallery</a> of which one could build a local distribution with a binary repository and a repository in nuget format.  Also check <a href="https://github.com/OneGet/oneget" rel="noreferrer">OneGet</a> if Windows distribution management is of interest to you.</li>
<li>In JavaScript: we have <a href="https://www.npmjs.com/" rel="noreferrer">npm</a> which is one of the most popular, will require <a href="https://nodejs.org/en/" rel="noreferrer">nodejs</a>.</li>
<li>In python: there is <a href="https://pypi.python.org/pypi/pip" rel="noreferrer">pip</a> and the official package index <a href="https://pypi.python.org/pypi" rel="noreferrer">pypi</a>, which one can also create a local instance through binary repository that will support the format.</li>
</ul>

<p>This list is far from complete, just gives an idea of what's out there.</p>

<p>The binary repository can allow to host all of these under one roof, making their management much simpler for teams.  Note that you do not need a very large team to start reaping benefits from binary package management.  The initial investment is not very large and the benefits are felt immediately.  Especially now that more and more platforms, frameworks and languages are integrating this dependency management directly in them.
Their biggest advantage I have found however was to create an environment that your programmers will find natural and comfortable making it essential.  It helps you as a devops creating a solid tool-chain and it helps them making the overall experience fit naturally in their stack of choice.</p>

<p>As I said earlier there are <a href="https://en.wikipedia.org/wiki/List_of_software_package_management_systems" rel="noreferrer">many products</a> out there that can serve as binary package managers, some more generic than others in their target usage, varying also widely in their accessibility and prices.</p>

<p>My personal opinion is that binary repositories are as vital a part of a well designed devops setup as the source code repository or continuous integration.</p>

CC BY-SA 3.0
2017-08-31T17:03:49.030Z
Merci for this interesting answer (also). For some reason, all this makes me think like "hm, so this is like what we typically call, in good old mainframe environments, things like *load libraries containing executables* (used to run your CICS / IMS / IDMS regions) ...".
Pierre.Vriens
CC BY-SA 3.0
2017-08-31T18:05:58.343Z
One important thing to add is the rise of public repositories like Maven Central etc http://www.modulecounts.com - these are often THE supply source for software projects which become more and more assembly srores for these components plus custom glue/frontend code and of course customer specific business logic.
Ta Mu
CC BY-SA 3.0
2017-08-31T18:17:19.287Z
never heard of modulecounts.com, the site is down now though, I'll check it later.
Newtopian
CC BY-SA 4.0
2018-09-05T20:12:20.623Z
Interesting analogy of fridge to refrigerator :)
Ravi Tiwari
CC BY-SA 4.0
2020-01-14T23:11:57.043Z
So how does this differ from a authenticated web server that serves binary files rather than HTML?  Why a separate server?
anthony
CC BY-SA 4.0
2020-01-14T23:45:12.057Z
@Anthony: Main difference is that you are serving these files to other scripts / tools that have their own expectations on API endpoints/naming conventions.  Most stack will have their own implementation and/or multiple open source implementations, essentially you'd get a single use binary repository.  Having (most of) them all under the same roof has benefits, I can concentrate on offering better services and delegate the plumbing to this system.
Newtopian
CC BY-SA 4.0
2017-08-31T16:30:54.667Z
2018-08-17T20:59:20.017Z
2018-08-17T20:59:20.017Z
Newtopian
<p>There are quite some <a href="https://devops.stackexchange.com/search?q=artifactory+is%3Aq">questions</a> and <a href="https://devops.stackexchange.com/search?q=artifactory+is%3Aa">answers</a> that mention "<strong><em>artifactory</em></strong>".</p>

<p>I wouldn't be surprised if it is somehow related to <a href="/questions/tagged/artifacts" class="post-tag" title="show questions tagged &#39;artifacts&#39;" rel="tag">artifacts</a>.</p>

<p><strong>My questions</strong>:</p>

<ul>
<li>What is actually an "artifactory" (in the context of DevOps)?</li>
<li>Why are artifactories used?</li>
</ul>

CC BY-SA 4.0
2018-08-20T20:52:15.340Z
Quite a few interesting answers to what I thougt to be a rather basic question. Funny enough they all remind me about a similar concept in good old mainframe environments (where my DevOps roots are ... and where so many DevOps concepts seem to originate from).
Pierre.Vriens
<terminology><artifacts><artifactory>
What is an artifactory?
Pierre.Vriens
# What is an artifactory?

(Asked by: username_0 on 2017-08-31)

There are quite some [questions](https://devops.stackexchange.com/search?q=artifactory+is%3Aq) and [answers](https://devops.stackexchange.com/search?q=artifactory+is%3Aa) that mention "***artifactory***".

I wouldn't be surprised if it is somehow related to [artifacts](/questions/tagged/artifacts "show questions tagged 'artifacts'").

**My questions**:

* What is actually an "artifactory" (in the context of DevOps)?
* Why are artifactories used?

**Tags:** terminology, artifacts, artifactory

> **Comments:**
> **username_0**: Quite a few interesting answers to what I thougt to be a rather basic question. Funny enough they all remind me about a similar concept in good old mainframe environments (where my DevOps roots are ... and where so many DevOps concepts seem to originate from).  

---

## 5 answers

### Answer by username_8 on 2017-08-31. Score: 131 | Accepted answer

[Artifactory](https://www.jfrog.com/artifactory/) is a product by JFrog that serves as a [binary repository manager](https://en.wikipedia.org/wiki/Binary_repository_manager). That said very often one will use a 'artifactory' as a synonym of the more general binary repository, much like many people use Frigidaire or fridge to denote the refrigerator regardless if it is a Frigidaire brand or not.

The binary repository is a natural extension to the source code repository, in that it will store the outcome of your build process, often denoted as artifacts. Most of the times one would not use the binary repository directly but through a package manager that comes with the chosen technology.

In most cases these will store individual application components that can later be assembled into a full product - thus allowing a build to be broken in smaller chunks, making more efficient use of resources, reducing build times, better tracking of binary debug databases etc.

Here are some of the most popular package managers that can be managed using a binary repository:

* Java: jar, ear, war etc has [Maven](https://maven.apache.org/) and the official [MavenCentral](https://search.maven.org/). There are many other package managers that will use the maven binary repository format as well ([ivy](http://ant.apache.org/ivy/), [gradle](https://gradle.org/) etc).
* .Net: [nuget](https://www.nuget.org/) for .NET components (DLL and EXE) but can also be used as a distribution mechanism under windows thorugh systems like [Chocolatey](https://chocolatey.org/). Newer versions of Powershell can also leverage this to distribute powershell modules though the [powershell gallery](https://www.powershellgallery.com/) of which one could build a local distribution with a binary repository and a repository in nuget format. Also check [OneGet](https://github.com/OneGet/oneget) if Windows distribution management is of interest to you.
* In JavaScript: we have [npm](https://www.npmjs.com/) which is one of the most popular, will require [nodejs](https://nodejs.org/en/).
* In python: there is [pip](https://pypi.python.org/pypi/pip) and the official package index [pypi](https://pypi.python.org/pypi), which one can also create a local instance through binary repository that will support the format.

This list is far from complete, just gives an idea of what's out there.

The binary repository can allow to host all of these under one roof, making their management much simpler for teams. Note that you do not need a very large team to start reaping benefits from binary package management. The initial investment is not very large and the benefits are felt immediately. Especially now that more and more platforms, frameworks and languages are integrating this dependency management directly in them.
Their biggest advantage I have found however was to create an environment that your programmers will find natural and comfortable making it essential. It helps you as a devops creating a solid tool-chain and it helps them making the overall experience fit naturally in their stack of choice.

As I said earlier there are [many products](https://en.wikipedia.org/wiki/List_of_software_package_management_systems) out there that can serve as binary package managers, some more generic than others in their target usage, varying also widely in their accessibility and prices.

My personal opinion is that binary repositories are as vital a part of a well designed devops setup as the source code repository or continuous integration.

> **Comments:**
> **username_0**: Merci for this interesting answer (also). For some reason, all this makes me think like "hm, so this is like what we typically call, in good old mainframe environments, things like *load libraries containing executables* (used to run your CICS / IMS / IDMS regions) ...".  
> **username_4**: One important thing to add is the rise of public repositories like Maven Central etc http://www.modulecounts.com - these are often THE supply source for software projects which become more and more assembly srores for these components plus custom glue/frontend code and of course customer specific business logic.  
> **username_8**: never heard of modulecounts.com, the site is down now though, I'll check it later.  
> **username_9**: Interesting analogy of fridge to refrigerator :)  
> **username_7**: So how does this differ from a authenticated web server that serves binary files rather than HTML?  Why a separate server?  
> **username_8**: @Anthony: Main difference is that you are serving these files to other scripts / tools that have their own expectations on API endpoints/naming conventions.  Most stack will have their own implementation and/or multiple open source implementations, essentially you'd get a single use binary repository.  Having (most of) them all under the same roof has benefits, I can concentrate on offering better services and delegate the plumbing to this system.  

---

### Answer by username_2 on 2018-08-20. Score: 27

The way it helped me understand initially, the difference between source code repository and binary repository was to think of it like:
\* Github or Bitbucket is useful to maintain all 'code'
\* Jfrog Artifactory is useful to maintain the built 'binary'
At least till I was comfortable with these terms!

Also, the importance of Artifactory can be understood in relation to the philosophy of DevOps to "Build once, Deploy always". It goes a long way in Continuous Integration to build your binary once, put it into Artifactory and then call it from there to deploy into all of the different environments. That way, we are sure that the code that works in Dev is the one pushed to Prod and will work there.

> **Comments:**
> **username_0**: interesting explanation, merci!  

---

### Answer by username_3 on 2017-08-31. Score: 13

Artifactory is a [Binary Repository Manager](https://en.wikipedia.org/wiki/Binary_repository_manager) product from [Jfrog](https://www.jfrog.com/).

You're right - being a binary repository manager it is typically used to manage storage of [artifacts](/questions/tagged/artifacts "show questions tagged 'artifacts'") generated and used in the software development process.

From [Artifactory's main webpage](https://www.jfrog.com/artifactory/):

> As the first, and only, universal Artifact Repository Manager on the
> market, JFrog Artifactory fully supports software packages created by
> any language or technology.
>
> ...
>
> ...Artifactory provides an end-to-end, automated and bullet-proof
> solution for tracking artifacts from development to production.

The usages you mentioned suggest it may be popular enough for a [generic trademark](https://en.wikipedia.org/wiki/Generic_trademark) in DevOps.

> **Comments:**
> **username_0**: Merci Dan, you're somehow confirming that an Artifactory is like a combination of the words **Artifac**ts with Reposi**tory**. The additional question I wonder about is this: what about artifacts that are used in production, but which are not binaries, such as PHP code, CSS files, bash scripts, etc?  
> **username_4**: For application code they have source code versioning systems like cvs, svn, git, mercurial.. And for configuration code, configuration management and distribution systems, like puppet, chef, ansible, salt..  
> **username_3**: @username_0 I didn't use to think about it this way, somehow "factory" always came to mind first :) But I totally see it now. Thanks!  
> **username_0**: @J.Doe merci for that addition, and just to further extend your comment ... on mainframes they have tools like "ChangeMan ZMF", "Endevor SCM", etc. These tools are used for all the functions you mentioned (versioning, distribution, etc, but also for workflow, security, etc related to all that).  
> **username_4**: So if we only reinvent msinframes what could be wrong with them?!  
> **username_4**: .. And, for container storage you can use the public Docker Hub or its private form, docker registry  
> **username_5**: "The additional question I wonder about is this: what about artifacts that are used in production, but which are not binaries, such as PHP code, CSS files, bash scripts, etc?" - I think this portion moves away from your original question and is more on the lines of "How do I use" rather than "What is". Also, I feel that each of those use cases can (and should?) be a question in their own right.  
> **username_3**: @username_5 Just fire a new question...  

---

### Answer by username_6 on 2019-03-31. Score: 11

I think complicating things is what everybody is getting appreciated for nowadays. I will try to answer this question in short .

Source Repository is used for storing code and its versions, while artifactory is used for storing the executable programs that are outputs of those code [ binaries - dll, jar, war, ear, msi, exe files etc.]

Now the reason why you would want to place them separately in a repo which is different from your code could be many - right from secure access, hacking threat, preventing unintentional downloads of malicious/modified jars or to simply have a separate avenue for the clients who will be using your binaries to develop their code.

The technology of SCM could have divulged itself into creating 2 kind of users ( one with developer privileges who will be able to access the source code and another as a client who will just be able to access binaries). But it did not take that route! So now we have artifactories.

> **Comments:**
> **username_7**: A major reason for a binary storage (whether it is a repository or not) is that you can not create 'text diff patches' of the changes in a binary, as you can for source.  That is you can not store 'diff's' to save space and let users see how the text file (or source code) changed.    Git for example had major problem with 'versions' of 'formated documents', though I don't know if that is still the case.  
> **username_6**: @username_7, Why would you want "text diff patches" in case of executable jars? The whole reason you get to deal with binary is that you dont bother about its code.  

---

### Answer by username_1 on 2018-08-20. Score: 5

**An artifact**

Is something that is produced/generated/crafted out of a specific process

> Jar out of a Java project build.
>
> Question out of your mind
>
> Car out of a factory
>
> New song

**A repository**

Is a receptacle where things are persisted

> Github for a Java project.
>
> StackExchange for your daunting questions

IN THEORY, an **Artifact**-*ory* would be a repository of artifact where they are persisted and managed throughout their life cycle.

In the context of DevOps, Artifactory is a product that manages binary artifacts. It stores and manages different types (Jar, Python and npm packages, etc...) that you produce out of your builds and re-use at compile or deployment time.

> **Comments:**
> **username_0**: interesting explanation, merci!  
> **username_1**: ca me fait plaisir!  

---

