Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2018-08-20T20:46:31.113Z
Answers: interesting explanation, merci!
Answers: Pierre.Vriens
Answers: CC BY-SA 4.0
Answers: 2018-08-21T02:04:51.380Z
Answers: ca me fait plaisir!
Answers: gmolaire
Answers: CC BY-SA 4.0
Answers: 2018-08-20T20:05:06.327Z
Answers: 2019-05-13T13:46:10.700Z
Answers: 2020-06-18T08:28:10.803Z
Answers: gmolaire
Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2018-08-20T20:46:47.313Z
Answers: interesting explanation, merci!
Answers: Pierre.Vriens
Answers: CC BY-SA 4.0
Answers: 2018-08-20T01:20:58.463Z
Answers: 2018-08-20T01:20:58.463Z
Answers: Karthik Venkatesan
Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2017-08-31T17:03:41.487Z
Answers: 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?
Answers: Pierre.Vriens
Answers: CC BY-SA 3.0
Answers: 2017-08-31T18:04:14.537Z
Answers: 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..
Answers: Ta Mu
Answers: CC BY-SA 3.0
Answers: 2017-08-31T18:20:04.513Z
Answers: @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!
Answers: Dan Cornilescu
Answers: CC BY-SA 3.0
Answers: 2017-08-31T18:50:12.567Z
Answers: @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).
Answers: Pierre.Vriens
Answers: CC BY-SA 3.0
Answers: 2017-08-31T19:17:59.410Z
Answers: So if we only reinvent msinframes what could be wrong with them?!
Answers: Ta Mu
Answers: CC BY-SA 3.0
Answers: 2017-09-01T01:32:49.243Z
Answers: .. And, for container storage you can use the public Docker Hub or its private form, docker registry
Answers: Ta Mu
Answers: CC BY-SA 4.0
Answers: 2020-07-21T20:24:24.800Z
Answers: "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.
Answers: kapad
Answers: CC BY-SA 4.0
Answers: 2020-07-23T15:57:12.127Z
Answers: @kapad Just fire a new question...
Answers: Dan Cornilescu
Answers: CC BY-SA 3.0
Answers: 2017-08-31T16:15:15.700Z
Answers: 2017-08-31T16:15:15.700Z
Answers: Dan Cornilescu
Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2020-01-14T23:24:05.070Z
Answers: 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.
Answers: anthony
Answers: CC BY-SA 4.0
Answers: 2020-01-30T18:58:53.260Z
Answers: @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.
Answers: Spear A1
Answers: CC BY-SA 4.0
Answers: 2019-03-31T16:58:43.900Z
Answers: 2022-09-16T03:32:25.640Z
Answers: 2022-09-16T03:32:25.640Z
Answers: Spear A1
Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2017-08-31T17:03:49.030Z
Answers: 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) ...".
Answers: Pierre.Vriens
Answers: CC BY-SA 3.0
Answers: 2017-08-31T18:05:58.343Z
Answers: 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.
Answers: Ta Mu
Answers: CC BY-SA 3.0
Answers: 2017-08-31T18:17:19.287Z
Answers: never heard of modulecounts.com, the site is down now though, I'll check it later.
Answers: Newtopian
Answers: CC BY-SA 4.0
Answers: 2018-09-05T20:12:20.623Z
Answers: Interesting analogy of fridge to refrigerator :)
Answers: Ravi Tiwari
Answers: CC BY-SA 4.0
Answers: 2020-01-14T23:11:57.043Z
Answers: So how does this differ from a authenticated web server that serves binary files rather than HTML?  Why a separate server?
Answers: anthony
Answers: CC BY-SA 4.0
Answers: 2020-01-14T23:45:12.057Z
Answers: @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.
Answers: Newtopian
Answers: CC BY-SA 4.0
Answers: 2017-08-31T16:30:54.667Z
Answers: 2018-08-17T20:59:20.017Z
Answers: 2018-08-17T20:59:20.017Z
Answers: Newtopian
Body: <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>
  
Comments: CC BY-SA 4.0
Comments: 2018-08-20T20:52:15.340Z
Comments: 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).
Comments: Pierre.Vriens
Tags: <terminology><artifacts><artifactory>
Title: What is an artifactory?
UserDisplayName: Pierre.Vriens
ThreadText: # 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**: @username_7: 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!  
  
  ---
  
  