Upgrading Artifactory

JFrog Installation & Setup Documentation

Content Type
Installation & Setup
ft:sourceType
Paligo

Subscription Information

This feature is supported on the Self-Hosted platform, with a Pro, Pro X, Enterprise X, or Enterprise+ license.

The procedure to upgrade Artifactory depends on your installation type. We strongly recommend reading through this page before proceeding with your upgrade.

We recommend that you first review Artifactory Release Notes. Review the breaking changes, deprecated features and more.Artifactory Release Notes

Important

Make sure to use the same upgrade method (RPM, Debian, Docker, etc.) as the one you initially used to install Artifactory.

Before you upgrade Artifactory

To ensure you can restore your Artifactory and database in case you encounter any issues during the upgrade process, we strongly recommend that you make sure your system and database backups are up to date.

Warning

Before you upgrade Artifactory, you need to shut down the Artifactory service. Artifactory will not be online during upgrade. Factor in this downtime before you proceed with the upgrade.

Before upgrading, ensure that you specify the join.key in the system.yaml file. If you do not specify the join key in the system.yaml file, the upgraded Artifactory node might fail to come up and will not be able to join the HA cluster. For information on system.yaml configuration, see Artifactory System YAML.

Oracle

Artifactory 7.x requires a new setup to connect to an Oracle Database. For more information, see Configure Artifactory to use Oracle.

MySQL

Artifactory version 7.25.5 and later ships with an OpenJDK version that prevents connection that use TLS 1.0 or 1.1. You must explicitly enable these connections if you are unable to upgrade the database to version that supports TLS 1.2 or later. For more information, see Enabling TLS 1.0 and 1.1 for Connectivity with Older Databases.

Before upgrading Artifactory, refer to System Requirements for information on supported platforms, supported browsers and other requirements. To learn about the HA architecture, refer to System Architecture.

Operating Systems and Platform Support

The following table lists the supported operating systems and the versions.

Product

Debian

RHEL

Ubuntu

Windows Server

Amazon Linux

Artifactory

10.x, 11.x

8.x, 9.x

20.04, 22.04

2016 or 2019

Amazon Linux 2023

Operating Systems - End of Support

As part of JFrog commitment to maintain the security and reliability of the JFrog Platform, Artifactory will officially run with Node.js 20.x on all installation types from Artifactory 7.77.3.

Node.js 20.x provided with Linux Archive/Debian/RPM installations (non-containerized distributions) is not supported on the following operating systems.

Hence, these operating systems will no longer supported from Artifactory version 7.77.3.

Supported Platforms

The following table lists the supported platforms.

Product

x86-64

ARM64

Kubernetes

OpenShift

Artifactory

1.19+

4.13+

Installation on Kubernetes environments is through Helm Charts. Supported Helm version is Helm 3+.

Kubernetes Sizing Requirements

We have included YAML files with the different sizing configuration for Artifactory in our GitHub page. You can use these YAML when you set up your cluster.

ARM64 Support

From version 7.41.4, Artifactory supports installation on ARM64 architecture through Helm and Docker installations. You must set up an external database as the Artifactory database since Artifactory does not support the bundled database with the ARM64 installation. Artifactory installation pulls the ARM64 image automatically when you run the Helm or Docker installation on the ARM64 platform.

ARM64 support is also available for Xray, Pipelines (in Helm installation), and Insight.

Artifactory Database Requirements

You can configure your own database from the following list.

Artifactory supports the following databases.

  • PostgreSQL

  • Oracle

  • MySQL

  • Microsoft SQL Server

  • MariaDB

Artifactory HA requires an external database, which is fundamental to management of binaries and is also used to store cluster wide configuration files.

Since Artifactory HA contains multiple Artifactory cluster nodes, your database must be powerful enough to service all the nodes in the system. Moreover, your database must be able to support the maximum number of connections possible from all the Artifactory cluster nodes in your system.

If you are replicating your database you must ensure that at any given point in time all nodes see a consistent view of the database, regardless of which specific database instance they access. Eventual consistency, and write-behind database synchronization is not supported.

Artifactory Filestore

The filestore is where binaries are physically stored.

Artifactory provides the following options to store binaries.

  • Local file system in which binaries are stored with redundancy using a binary provider, which manages synchronizing files between the cluster nodes according to the redundancy defined.

  • Cloud storage: Amazon S3, Microsoft Azure, and Google Cloud Storage.

  • Network File System (NFS)

For detailed information, see Filestore Configuration.

Binary Storage

While Artifactory can use a Networked File System (NFS) for its binary storage, you should do not install the application itself on an NFS. The Artifactory application needs very fast, reliable access to its configuration files. Any latency from an NFS will result in poor performance when the application fails to read these files. Therefore, install Artifactory on a local disk mounted directly to the host.

To use an NFS to store binaries, use the "file-system" binarystore.xml configuration with the additional "<baseDataDir>" setting.

Working with Very Large Storage

In most cases, our recommendation is for storage that is at least 3 times the total size of stored artifacts in order to accommodate system backups.Backups

However, when working with a very large volume of artifacts, the recommendation may vary greatly according to the specific setup of your system. Therefore, when working with over 10 TB of stored artifacts, contact JFrog support, who will work with you to provide a recommendation for storage that is customized to your specific setup.

Allocated storage space may vary

Xray downloads and then deletes fetched artifacts after indexing. However, in order to have more parallel indexing processes, and thereby more temporary files at the same time would require more space.

This is especially applicable for large BLOBs such as Docker images.

Artifactory Network Ports

Artifactory uses external network ports to communicate with services outside Artifactory and internal networks to communicate with Artifactory and other JFrog Platform microservices.

External Network Ports

Artifactory uses the following external network ports by default.

  • 8081

  • 8082

Internal Network Ports

Artifactory uses the following internal network ports.

Microservice

Port

Artifactory

8081

Access

8040 and 8045

Web

8070

Metadata

8086

Router

8082, 8046, 8047, 8049, and 8091

Events

8061, and 8062

Integration

8071 and 8072

JFConnect

8030

Observability

8036

gRPC

8037

Artifactory Upgrade Versions

The upgrade instructions vary according to your version of the Artifactory.

  • Below Artifactory 6.10.x

  • From Artifactory 6.10.x onwards to Artifactory 7.x

  • From Artifactory 7.x to Artifactory 7.x

  • Artifactory HA Upgrade

Artifactory Upgrade with Xray

When more than one Artifactory instances are connected to a single Xray instance

When upgrading to the JFrog Platform, Xray must be connected only to a single Artifactory instance. If you have one Xray instance connected to more than one Artifactory instances, use one of the following options before proceeding with any upgrade.

  • Recommended

    Keep one connected Artifactory instance to your single Xray instance, and upgrade the rest to version 7.x with newly installed Xray version 3.x instances. This option will require re-indexing the the additional Artifactory instances, and will cause some loss of configuration data. Learn More >

  • Install additional Xray version 2.x instances for each Artifactory instance that you have, and restore all MongoDB and PostgreSQL data. Continue to upgrade each Artifactory and Xray pairs to version 7.x and version 3.x. This procedure is only suggested if you must keep all your Xray configurations and easily reconfigure them in the new instances. Learn More >

Before you upgrade Xray

The Artifactory upgrade process might take a while to complete, you should consider enabling the Allow downloads when Xray is unavailable, and the Allow downloads of blocked artifacts checkboxes in the Xray Configuration page to prevent Artifactory from not being able to respond to user requests.

Installation Types

The install type is referenced as <type> in the different installation instructions below.

Subscription Type

Install Type

Download the Package

Pro

Pro X

Enterprise

Enterprise+

pro

Download Link

Artifactory OSS

oss

Download Link

JFrog Container Registry

jcr

Download Link

Upgrade Steps

The upgrade procedure involves the following main steps.

Default Home Directory / $JFROG_HOME

The default home directory is defined according to the installation type. For additional details see the Product Directory Structure page.

$JFROG_HOME represents the JFrog root directory containing the deployed product.

  1. Download the package to upgrade (Linux Archive, RPM, Debian, Docker Compose, Helm).

  2. Stop the current server

  3. Extract/Install the package according to the installer distribution type.

  4. Check the Migration Log and review system.yaml to validate the migration was successful (only for upgrading from v6.x).

  5. Start the service using the start scripts or OS service management.

  6. Check the Artifactory Log for the status of the service.