From RHEL7, Ubuntu 18.04, CentOS 7, and Amazon Linux 2 to Newer Releases
As part of JFrog's ongoing efforts to ensure the security and dependability of the JFrog Platform, Artifactory will officially support Node.js 20.x on all installation types beginning with Artifactory version 7.77.3.
Node.js 20.x included in Linux Archive/Debian/RPM installations (non-containerized distributions) may not work with certain operating systems.
Please review the list of incompatible operating systems before proceeding with this article.
Users who would like to upgrade Artifactory would have first to migrate to a newer server version and then Upgrade
Upgrade - The process of upgrading Artifactory from a lower version to a higher one
Migration - The process of transferring Artifactory from one instance to another
It is not recommended to perform these two operations at the same time. First, migrate, then Upgrade.
Warning:
If Derby DB is being used, the migration method mentioned in this article will not be possible.
The only migration process that will work is system export as explained in detail here
Alternatively, you can move to another DB.
For this tutorial we will need to set 2 Terms:
Original Instance - The current old version of Linux server running Artifactory.
New Instance - The new node running a newer version of Linux supported by Artifactory 7.77.3+.
TIP:
These steps cover the essential components of the upgrade process. Additional steps specific to your environment may also be necessary.
1. Initialization
Create a new instance of a supported Linux OS version following the requirements from the official docs - This will be our New Instance
2. Artifactory Installation
Install Artifactory on the newly created instance, ensuring it matches the exact version of the existing setup.
Please don't start the Artifactory service after installation.
3. Security Configuration
Transfer the master.key from the original instance to $JFROG_HOME/var/etc/security/master.key on the new instance.
(The master.key is being used to decrypt all configuration files that are saved in the DB, in addition to passwords saved on the filesystem and more)
Note that the join key will automatically be retrieved from the database.
4. System Configuration
Copy the system.yaml from the original instance to the new instance, to keep the configurations of the original instance.
(Can be found at $JFROG_HOME/artifactory/var/etc/system.yaml)
Note:
If an IP address or hostname is configured in the system.yaml file, ensure that you update it to match the new server's correct IP address or hostname.
4.b Database Connector Configuration
Make sure that the connection string to the existing DB was copied properly:
For example With PostgreSQL:
url: "jdbc:postgresql://<DB_IP>:5432/artifactory"
Warning
Ensure that the new server has permission to access the existing DB. This may involve bypassing firewalls, updating allow lists, or making necessary configurations.
5. Storage Configuration Part 1
-
(If using local storage): You will need to manually move the content of your filestore (Default location $JFROG_HOME/artifactory/var/data/artifactory/filestore) to the New instance.
-
(If using NFS/NAS): Mount the NAS/NFS storage to your new instance
-
If using cloud storage (S3, AzureBlob, Google Storage): Make sure the new server has the correct permissions and credentials to access the cloud storage resource.
6. Storage Configuration Part 2
Copy the binarystore.xml from the original instance to $JFROG_HOME/var/etc/artifactory/binarystore.xml on the new instance.
7A. Single instance Artifactory:
Switch instances
Downtime is unavoidable: Stop Artifactory service on the original Instance and start Artifactory on the new instance.
7B. High Availability Artifactory - Multiple Nodes:
Switch instances - HA No Downtime Possibility
In an HA environment where a Load Balancer is properly distributing traffic between the nodes - There is a possibility of avoiding downtime by migrating only one node at any given time. While having a Load Balancer forwarding requests to other working nodes.
Note:
During the migration period, a single Artifactory cluster can temporarily contain nodes running different operating system versions (e.g., one node on RHEL 7, another on RHEL 8).
However, all nodes in the cluster must run the same Artifactory version — mixed Artifactory versions within a cluster are not supported.
8. Health Check
The new integration into the cluster via the Artifactory UI (Monitoring → Service Status → Nodes) -
Make sure it is present and healthy.
9. License Validation
Make sure that the node has been assigned a license. (How to check my licenses?)
10. Operational Validation
Check everything works correctly. (Download/Upload via the new node, etc)
11. Load Balancer Validation
If exists: Update the Load Balancer configuration to include the IP address of the new node, ensuring network continuity and load balancing within the HA environment then check the node via the Load balancer (Download/upload).
Revert option (Only if required)
In case of any failure, you can revert to the original instance, by stopping the Artifactory service on the new instance, and starting it back again on the original instance.