You may define a repository as Generic in which case it has no particular type, and you may upload packages of any type. Generic repositories do not maintain separate package indexes. For using a client associated with a specific package type (e.g. yum, gem) you should create a matching repository.
Local repositories are physical, locally-managed repositories into which you can deploy artifacts.
Artifacts in a local repository can be accessed directly using the following URL:
Artifactory is deployed with a number of pre-configured local repositories which can be used for internal and external releases, snapshots and plugins.
For full details on configuring local repositories, please refer to Local Repositories.
A remote repository serves as a caching proxy for a repository managed at a remote URL (which may itself be another Artifactory remote repository).
Artifacts are stored and updated in remote repositories according to various configuration parameters that control the caching and proxying behavior. You can remove artifacts from a remote repository cache but you cannot actually deploy a new artifact into a remote repository.
Artifacts in a remote repository can be accessed directly using the following URL:
This URL will fetch a remote artifact to the cache if it has not yet been stored.
In some cases it is useful to directly access artifacts that are already stored in the cache (for example to avoid remote update checks).
To directly access artifacts that are already stored in the cache you can use the following URL:
Artifactory is deployed with a number of pre-configured, remote repositories which are in common use. Of course you can change these according to the needs of your organization.
A remote repository acts as a proxy not as a mirror. Artifacts are not pre-fetched to a remote repository cache. They are only fetched and stored on demand when requested by a client.
For full details on configuring remote repositories please refer to Remote Repositories.
A virtual repository (or "repository group") aggregates several repositories with the same package type under a common URL.
By their nature, Virtual Repositories whose package type has been specified as Generic can aggregate repositories of any type, however generic virtual repositories do not maintain any metadata
Artifactory offers an option to use a global virtual, which contains all local and remote repositories.
By default this option is disabled, to enable the Default Virtual Repository edit the 'artifactory.system.properties' located at $ARTIFACTORY_HOME/etc and set the following flag to false:
## Disable the download access to the global 'repo' artifactory.repo.global.disabled=false
This change requires you restart your Artifactory service.
Once enabled the repository is available at:
When an artifact is requested from a virtual repository, the order in which repositories are searched or resolved is local repositories first, then remote repository caches, and finally remote repositories themselves.
Within each of these, the order by which repositories are queried is determined by the order in which they are listed in the configuration as described in General Resolution Order below.
For a virtual repository, you can see the effective search and resolution order in the Included Repositories list view in the Basic settings tab. This is particularly helpful when nesting virtual repositories. For more details on configuring a virtual repository please refer to Virtual Repositories.
You can set the order in which repositories of each type (local, remote and virtual) are searched and resolved by simply ordering them accordingly within the corresponding section of the Configure Repositories page. To set the order you need to add the repositories to the list of selected repositories in the order in which they should be searched to resolve artifacts.
The order in which repositories are searched is also affected by additional factors such as security privileges, include/exclude patterns and policies for handling snapshots and releases.