Upgrading from version 3.x or 4.x to the latest version is a simple procedure whether you are running as a standalone installation, an RPM installation or in a Docker container.
Before proceeding, there are a few points you need to address:
$ARTIFACTORY_HOME/tomcat/conf/server.xml has been modified keep it in a temporary location.
$ARTIFACTORY_HOME/tomcat/lib/<JDBC> driver in a temporary location.
For a Linux service, browse to
$ARTIFACTORY_HOME/bin and execute the following command as root:
$ARTIFACTORY_HOME/bin/installService.sh [USER [GROUP]]
Although these files are not required for runtime, it is recommended to replace this folder too.
When running as an RPM installation, you can only upgrade to v4.x if your current version is 3.6 or above. If necessary, first upgrade your current version to 3.6, and then upgrade to 4.x.
If you try to upgrade a version below 3.6 using
sudo su -).
Execute the following command:
rpm -U jfrog-artifactory-<oss|pro>-4.y.z.rpm
If you are just switching from Artifactory OSS to Pro with the same version number, you need to append the command with --force --nodeps as follows:
rpm -U jfrog-artifactory-<oss|pro>-4.y.z.rpm --force --nodeps
During an upgrade of an RPM installation different files may get backed up, where the backup file is appended with either a .rpmorig or a .rpmnew extension.
A .rpmorig extension means that the original file in your installation, the one that was there before performing the upgrade, was backed up before being replaced in the upgrade process.
A .rpmnew extension means that the original file in your installation, was not replaced in the upgrade, and instead, the new file with the same filename was backed up.
In either case, Artifactory will display a message such as:
warning: /etc/opt/jfrog/artifactory/default saved as /etc/opt/jfrog/artifactory/default.rpmorig
In these cases we recommend comparing the file installed once the upgrade has been completed with the backed-up file to see which best fits your needs, and using that one in the final setup.
If you make any changes, you may need to restart Artifactory for the change to be applied.
An easy way to upgrade Artifactory from version 3.x or 4.x to the latest version is to use YUM with the Bintray Artifactory repository. The code snippets below show how to do this depending on whether your current version is below 3.6, or 3.6 and above.
For Artifactory Pro
For Artifactory OSS
For Artifactory Pro
For Artifactory OSS
Artifactory runs as an RPM service within a Docker container. To upgrade Artifactory, follow the instructions for Running as an RPM Installation.
sudo su -).
Execute the following command:
dpkg -i $jfrog-artifactory-<oss|pro>-4.y.z.deb
When upgrading a Debian or RPM installation the upgrade process overwrites the following set of configuration files:
In case one of these files were changed a backed up file will be created automatically with a notification in the upgrade log. If you need to restore the configuration changes you can restore them from the backup created.
To work with version 4.x, you need to ensure that your repositories only contain artifacts with the same package type. A script to check this can be found on the JFrog GitHub.
In version 3.x Artifactory supported repositories with multiple package types. You were able to upload packages with different types to the same repository and Artifactory would calculate the metadata for those packages. Nevertheless, maintaining a single package type per repository was always a best practice that optimized performance and produced a more organized repository structure in your system. From version 4.0, you need to specify a single Package Type for a repository when you create it. Artifactory will only calculate metadata for, and be recognized by the corresponding client software for artifacts of the Package Type specified for that repository. (Artifactory will not prevent you from uploading packages of a different type, however, it will not calculate metadata for those packages, and the client for the different package types will not recognize the repository).
If you currently have repositories that are configured to support multiple package types, you need to migrate them to single package type repositories, however, you may do so either before or after running the upgrade procedure.
To migrate your repositories before upgrading, please refer to Migrating to Single Package Type Repositories.
If you prefer to migrate your repositories after upgrading, or have already upgraded, please refer to Fixing Multiple Package Type Repositories.
In version 4.x, if you need a repository to hold packages of several different types, you may specify its package type to be Generic. Artifactory does not calculate metadata for Generic repositories, and effectively, they behave like a simple file system to store packages.
To migrate a repository with multiple package types to single package type repositories, execute the following steps:
suppressLayouts=1query parameter in order to prevent artifact path transformations.
If you move data to an Npm repository, make sure to include the .
If you upgraded without migrating to single package type repositories, then Artifactory will start normally, however, repositories containing multiple package types will be randomly assigned one of the single package types from the original repository and output corresponding messages to the
For example, if libs-release-local contained three different package types: RubyGems, Npm and NuGet, after upgrading, your $ARTIFACTORY_HOME/logs/artifactory.log may contain messages similar to the ones below:
2015-06-28 10:10:47,656 [art-init] [INFO ] (o.a.v.c.v.SingleRepoTypeConverter:42) Converting repositories to a single package type 2015-06-28 10:10:47,663 [art-init] [ERROR] (o.a.v.c.v.SingleRepoTypeConverter:155) Disabling package 'Gems' for repo 'libs-release-local' since only one packaging type is allowed! 2015-06-28 10:10:47,664 [art-init] [ERROR] (o.a.v.c.v.SingleRepoTypeConverter:155) Disabling package 'Npm' for repo 'libs-release-local' since only one packaging type is allowed! 2015-06-28 10:10:47,664 [art-init] [INFO ] (o.a.v.c.v.SingleRepoTypeConverter:128) Setting repository 'libs-release-local' to type NuGet 2015-06-28 10:10:47,664 [art-init] [INFO ] (o.a.v.c.v.SingleRepoTypeConverter:128) Setting repository 'libs-snapshot-local' to type Maven 2015-06-28 10:10:47,664 [art-init] [INFO ] (o.a.v.c.v.SingleRepoTypeConverter:128) Setting repository 'plugins-release-local' to type Maven 2015-06-28 10:10:47,664 [art-init] [INFO ] (o.a.v.c.v.SingleRepoTypeConverter:128) Setting repository 'plugins-snapshot-local' to type Maven 2015-06-28 10:10:47,665 [art-init] [INFO ] (o.a.v.c.v.SingleRepoTypeConverter:128) Setting repository 'ext-release-local' to type Maven 2015-06-28 10:10:47,665 [art-init] [INFO ] (o.a.v.c.v.SingleRepoTypeConverter:128) Setting repository 'ext-snapshot-local' to type Maven 2015-06-28 10:10:47,666 [art-init] [INFO ] (o.a.v.c.v.SingleRepoTypeConverter:128) Setting repository 'jcenter' to type Maven 2015-06-28 10:10:47,666 [art-init] [INFO ] (o.a.v.c.v.SingleRepoTypeConverter:128) Setting repository 'remote-repo' to type Maven 2015-06-28 10:10:47,668 [art-init] [INFO ] (o.a.v.c.v.SingleRepoTypeConverter:128) Setting repository 'libs-snapshot' to type Maven 2015-06-28 10:10:47,668 [art-init] [INFO ] (o.a.v.c.v.SingleRepoTypeConverter:128) Setting repository 'p2' to type P2 2015-06-28 10:10:47,668 [art-init] [INFO ] (o.a.v.c.v.SingleRepoTypeConverter:56) Finished Converting repositories to a single package type
In this example, Artifactory set the Package Type to NuGet.
To fix this condition, you can simply follow steps described above in Migrating to Single Package Type Repositories, or after you upgrade, use the packageType utility found on the JFrog Github for 4.x migrations.
From version 4.0 Artifactory only supports the internal servlet container it comes with out-of-the-box. Other external servlet containers (such as Websphere, JBoss etc.) as well as an external Tomcat are no longer supported.
If your current 3.x installation is running in an external servlet container, the upgrade process to version 4.x involves the following basic steps:
Install Artifactory 4.x in a new location using the normal process described in Installing Artifactory.
Make sure to complete the steps below before you start up the new installation.
$ARTIFACTORY_HOME is location in which you unzipped the Artifactory installation file.
Copy the JDBC driver to your new installation and place it in
Copy or symlink the
backup directories from your old $ARTIFACTORY_HOME to the new $ARTIFACTORY_HOME.
Perform an orderly shutdown of your current installation.
To upgrade from a version prior to 3.0, you first need to upgrade to version 3.9.x as described in Upgrading Artifactory in the Artifactory 3 documentation.
Depending on your current version, upgrading to version 3.9.x may require you to first upgrade to an interim version.
The procedure to downgrade Artifactory may vary depending on the version you are using. For more details, please contact .
<iframe width="560" height="315" src="https://www.youtube.com/embed/5_6Ehj3LWpI" frameborder="0" allowfullscreen></iframe>