Still using Artifactory 3.x ?
Click here for the Artifactory 3.x User Guide

Skip to end of metadata
Go to start of metadata

Overview

The procedure to upgrade Artifactory depends on the version you currently have installed.

Please check the instructions below according to your current version.

Going Pro?

Even if you're just switching your current version of Artifactory OSS to the same version of Artifactory Pro, you still need to follow the same upgrade instructions specified on this page.

The one exception is for an rpm installation. Since you are installing an rpm with the same version number, you need to add --force to the end of the command.

Upgrading Artifactory HA?

If you are upgrading an Artifactory HA cluster, please refer to Upgrading Artifactory HA.

Page Contents

Before you upgrade

We strongly recommend that you do a complete System Export before commencing your upgrade procedure. If at any time you decide to roll back to your current version, you can use the export to reproduce your current system in its entirety.


Upgrading from v3.x to the Latest Version (v4.x)

Upgrading from version 3.x to version 4.x is a simple procedure whether you are running as a standalone installation, an RPM installation or in a Docker container.

Before you proceed

Before proceeding, there are three points you need to address:

  1. JDK Version
    From version 4.0, Artifactory requires JDK 8. Before you upgrade to Artifactory 4.x, please make sure you install JDK 8 and update your JAVA_HOME environment variable to point to your JDK 8 installation. For more details, please refer to System Requirements.

  2. Repositories with Multiple Package Types
    From version 4.0, Artifactory will only index, and work with corresponding clients for single package type repositories. If your current installation includes repositories that support multiple package types, you need to migrate them to single package type repositories. You may do so before upgrading or after. For more details please refer to Single Package Type Repositories.
     
  3. Servlet Containers
    From version 4.0, the only external servlet container that Artifactory supports is Tomcat v8 and above. If currently, you are not using Tomcat 8 or the default servlet container that comes with Artifactory out-of-the-box, please first read about using Upgrading When Using External Servlet Containers.

Running as a Standalone Installation

  1. Unzip the Artifactory distribution archive.
  2. If the $ARTIFACTORY_HOME/tomcat/conf/server.xml has been modified keep it in a temporary location.  
  3. If Artifactory is configured to work with a database that is not Derby, keep the $ARTIFACTORY_HOME/tomcat/lib/<JDBC> driver  in a temporary location.  
  4. Remove the following files and folders from your $ARTIFACTORY_HOME folder:
    • webapps/artifactory.war

    • tomcat

    • bin

  5. Replace the removed files and folders with the corresponding ones from the new unzipped version.
  6. Any files that were stored in temporary locations should now be returned to their original location under the new installation.
  7. If you installed Artifactory as a service, you now need to run the service
    1. For a Linux service, browse to $ARTIFACTORY_HOME/bin and execute the following command as root: $ARTIFACTORY_HOME/bin/installService.sh [USER [GROUP]]

    2. For  Windows service, browse to %ARTIFACTORY_HOME%\bin and run InstallService.bat

misc Folder

 The misc folder contains configuration files for specialized environments such as when running Artifactory as a Standalone Installation or on IBM Websphere.

Although these files are not required for runtime, it is recommended to replace this folder too.

Running as an RPM Installation

Make sure you are upgrading from v3.6 or above

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 rpm --force you may end up deleting all of your data.

 

  1. Log in as root (or use sudo su -).
  2. Execute the following command:

Upgrading Using YUM

An easy way to upgrade Artifactory from version 3.x  to version 4.x 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.

 If your current version is 3.6 and above:

For Artifactory Pro:

curl https://bintray.com/jfrog/artifactory-pro-rpms/rpm -o bintray-jfrog-artifactory-pro-rpms.repo && sudo mv bintray-jfrog-artifactory-pro-rpms.repo /etc/yum.repos.d
yum install jfrog-artifactory-pro

 

For Artifactory OSS:

curl https://bintray.com/jfrog/artifactory-rpms/rpm -o bintray-jfrog-artifactory-rpms.repo && sudo mv bintray-jfrog-artifactory-rpms.repo /etc/yum.repos.d/

yum install jfrog-artifactory-oss
 If your current version is below 3.6:

For Artifactory Pro

curl https://bintray.com/jfrog/artifactory-pro-rpms/rpm -o bintray-jfrog-artifactory-pro-rpms.repo && sudo mv bintray-jfrog-artifactory-pro-rpms.repo /etc/yum.repos.d
yum upgrade artifactory
yum install jfrog-artifactory-pro

 

For Artifactory OSS

curl https://bintray.com/jfrog/artifactory-rpms/rpm -o bintray-jfrog-artifactory-rpms.repo && sudo mv bintray-jfrog-artifactory-rpms.repo /etc/yum.repos.d/
yum upgrade artifactory
yum install jfrog-artifactory-oss

Running in a Docker Container

Artifactory runs as an RPM service within a Docker container. To upgrade Artifactory, follow the instructions for Running as an RPM Installation.

Running the WAR in an External Tomcat

To upgrade Artifactory that is running as a WAR in an external Tomcat:

  1. Unzip the Artifactory distribution archive.
  2. Replace the previously deployed artifactory.war file with the webapps/artifactory.war file found in the Artifactory distribution archive.

  3. Remove the expanded artifactory webapp directory.

    Recommend removing "work" and "temp" directories

    To make sure your previous version of Artifactory is really removed, we also recommend removing your Tomcat work and temp directories


Single Package Type Repositories

Single Package Type

To work with version 4.x, you need to ensure that your repositories only contain artifacts with the same package type.

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.

Generic 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.

Migrating to Single Package Type Repositories

To migrate a repository with multiple package types to single package type repositories, execute the following steps:

  1. Change the configuration of the original repository so it supports only one package type.
  2. For each additional packaging type needed, create a new repository with the corresponding package type
  3. Use the REST API or the UI to move packages from the original repository to the new one(s) created until all repositories only contain packages of the same type.
    When using the REST API, make sure to include the suppressLayouts=1 query parameter in order to prevent artifact path transformations.

Npm Repositories

If you move data to an Npm repository, make sure to include the .npm folder. This will preserve extra information that may have been stored when deploying packages using the npm client.

Fixing Multiple Package Type Repositories

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 single package from the original repository and output corresponding messages to the $ARTIFACTORY_HOME/logs/artifactory.log file.

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:

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.


Upgrading When Using External Servlet Containers

From version 4.0 Artifactory only supports the internal servlet container it comes with out-of-the-box, or an external Tomcat. Other external servlet containers (such as Websphere, JBoss etc.) are no longer supported.

If your current version is running on an external Tomcat, please refer to Running the WAR in an External Tomcat.

If your current installation is running in another external servlet container, the upgrade process to version 4.x involves the following basic steps:

  1. Install Artifactory 4.x in a new location but don't start it up

    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.


  2. When using an external database

    Copy the JDBC driver to your new installation and place it in $ARTIFACTORY_HOME/tomcat/lib.
     

  3. Copy or symlink the old data from $ARTIFACTORY_HOME to the new $ARTIFACTORY_HOME directory

    Copy or symlink the data, etc and backup directories from your old $ARTIFACTORY_HOME to the new $ARTIFACTORY_HOME.
     

  4. Shut down your current installation

    Perform an orderly shutdown of your current installation.
     

  5. Start up Artifactory 4.x


Upgrading from Any Version Below v3.0

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

Interim versions

Depending on your current version, upgrading to version 3.9.x may require you to first upgrade to an interim version.


Watch the Screencast