JFrog Artifactory 5.6 User Guide

JFrog%20Artifactory%205.6%20User%20Guide

User Manual: Pdf

Open the PDF directly: View PDF .
Page Count: 882

Download
Open PDF In Browser	View PDF

Artifactory
User Guide
1. Welcome to Artifactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1 Installing Artifactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.1 System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.2 Installing on Linux Solaris or Mac OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.3 Installing on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.4 Installing with Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.4.1 Building Artifactory OSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.4.2 Changing the Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Upgrading Artifactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.1 Upgrading an Enterprise HA Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Using Artifactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.1 Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.2 General Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.3 Browsing Artifactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.4 Using WebDAV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.5 Searching for Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.6 Deploying Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.7 Manipulating Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.8 Updating Your Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.9 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.10 Artifactory REST API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.10.1 Repository Configuration JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.10.2 Security Configuration JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.10.3 System Settings JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4 Configuring Artifactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.1 Configuring the Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.1.1 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.1.2 Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.1.3 Microsoft SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.1.4 PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.2 Configuring the Filestore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.3 Checksum-Based Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.4 Configuring Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.4.1 Common Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.4.2 Local Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.4.3 Remote Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.4.3.1 Managing Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.4.3.2 Advanced Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.4.4 Smart Remote Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.4.5 Virtual Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.5 Configuring Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.5.1 Managing Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.5.2 Managing Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.5.3 Centrally Secure Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.5.4 Master Key Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.5.5 Managing Security with LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.5.6 Managing Security with Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.5.7 Managing Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.5.8 Using a Self-Signed Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.5.9 Access Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.5.10 Access Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.6 Configuring a Reverse Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.6.1 Configuring Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.6.2 Configuring NGINX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.7 Mail Server Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.8 Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.9 Exposing Maven Indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.10 Clustering Artifactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4
6
8
10
17
20
24
25
27
37
50
53
58
61
67
68
76
83
88
93
95
193
197
198
199
204
206
210
211
215
216
247
250
253
255
259
262
263
268
271
275
280
286
290
292
294
297
304
306
307
314
315
320
323
325
327
331
333

1.5 System Monitoring and Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.1 System Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.2 Monitoring Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.3 Artifactory Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.4 Artifactory JMX MBeans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.5 Regular Maintenance Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.6 Managing Backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.7 Importing and Exporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.8 Managing Disk Space Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.9 Getting Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6 Artifactory High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6.1 HA Installation and Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6.2 Managing the HA Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6.3 Migrating Data from NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6.4 Troubleshooting HA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7 Xray Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.8 Bintray Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.8.1 Bintray info panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.8.2 Distribution Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.8.3 Deploying Snapshots to oss.jfrog.org . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.9 Log Analytics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10 Artifactory Pro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.1 Artifactory Comparison Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.2 Pro Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.2.1 Artifactory Query Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.2.2 Atlassian Crowd and JIRA Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.2.3 Azure Blob Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.2.4 Black Duck Code Center Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.2.5 Filestore Sharding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.2.6 Filtered Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.2.7 GPG Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.2.8 Google Cloud Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.2.9 LDAP Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.2.10 License Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.2.11 OAuth Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.2.12 Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.2.12.1 Using Properties in Deployment and Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.2.13 Repository Layouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.2.14 Repository Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.2.15 S3 Object Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.2.16 SAML SSO Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.2.17 Single Sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.2.18 Smart Searches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.2.19 SSH Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.2.20 User Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.2.21 Watches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.2.22 WebStart and Jar Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.3 Package Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.3.1 Bower Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.3.2 Chef Cookbook Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.3.3 CocoaPods Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.3.4 Conan Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.3.5 Debian Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.3.6 Docker Registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.3.6.1 Getting Started with Artifactory as a Docker Registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.3.6.2 Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.3.6.3 Working with Docker Content Trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.3.6.4 Using Docker V1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.3.7 Git LFS Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.3.8 Npm Registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.3.9 NuGet Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.3.9.1 Microsoft Symbol Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.3.10 Opkg Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.3.11 P2 Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.3.12 PHP Composer Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.3.13 Puppet Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.3.14 PyPI Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.3.15 RubyGems Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.3.16 SBT Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.3.17 Vagrant Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.3.18 VCS Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.3.19 RPM Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

335
335
336
339
343
347
350
353
359
362
364
369
382
385
391
394
397
398
398
411
416
420
422
424
426
444
447
448
448
453
455
457
461
464
471
480
482
484
492
499
501
507
510
513
515
538
538
540
542
552
559
564
567
575
587
598
599
603
612
618
628
638
642
646
652
656
671
678
687
691
697
706

1.10.4 Ecosystem Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.4.1 Maven Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.4.1.1 Maven Artifactory Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.4.2 Working with Gradle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.4.2.1 Gradle Artifactory Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.4.3 Working with Ivy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.5 Build Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.5.1 Jenkins Artifactory Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.5.1.1 Working With Pipeline Jobs in Jenkins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.5.2 TeamCity Artifactory Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.5.2.1 TeamCity Artifactory Plugin - Release Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.5.3 Bamboo Artifactory Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.5.3.1 Bamboo Artifactory Plugin - Release Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.5.4 MSBuild Artifactory Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.5.5 VS Team Services Artifactory Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.5.6 Using File Specs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.11 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.12 Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.13 End of Life . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.14 Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.15 Pivotal Cloud Foundry JFrog Artifactory Tile Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

716
717
723
728
733
741
744
754
755
771
784
789
810
818
827
836
841
842
843
847
881

Welcome to Artifactory
Welcome to the JFrog Artifactory User Guide!
JFrog Artifactory is the only Universal Repository Manager supporting all major packaging formats, build tools
and CI servers.

This user guide is for Artifactory 5.0.0 and above.
Click this link to download the latest PDF version of the Artifactory User Guide:
Note that the online version may be more up-to-date.
If you are using Artifactory 4.x.y, please refer to the Artifactory 4 User Guide.

Which Artifactory Do You Need?
Artifactory comes in the following flavors:

Artifactory
OSS

Offers powerful features with fine-grained permission control behind a sleek
and easy-to-use UI.
Using the links in the next column, you can download the Artifactory OSS
installation files, or the source files so you can build Artifactory OSS yourself.

Download
Download
Sources

For more information on building Artifactory OSS, please refer to the Readme
file.

Artifactory
Pro

Artifactory
Cloud
Artifactory

Exposes a set of professional add-ons, on top of those already available to
you from Artifactory Open Source, opening up a whole world of features that
empower you to manage your binaries and integrate with industry standard
tools in your development and deployment ecosystem.

Download

JFrog's SaaS-based solution for managing your artifacts and binary
repositories in the cloud with the full power of Artifactory Pro behind you and
24/7 SLA-based support.

Exposes an enterprise feature set such as cloud storage providers, advanced
capabilities for replication, high availability and more

Enterprise
Free Trial

Enterprise

To see which version of Artifactory best suits your needs, please see the Artifactory Features Matrix.

How is this Guide Organized?

Installing and U
pgrading
Artifactory

Learn how to install and upgrade Artifactory on all supported platforms, including
detailed system requirements and pre-requisites.

Using
Artifactory

Learn how to use Artifactory on a day-to-day basis including creating repositories,
deploying, copying and moving artifacts and more.

Configuring
Artifactory

Learn how to configure repositories, users, permissions and more.

Artifactory
REST API

A detailed specification of Artifactory's extensive REST API letting you automate any
process in your development ecosystem.

System
Monitoring and
Maintenance

Learn how to keep your system free of clutter and operating smoothly.

Artifactory
High
Availability

Learn how to configure and use Artifactory in a High Availability configuration providing
the most stable and secure binary repository available to enterprise users today.

Bintray
Integration

Learn how to integrate with JFrog Bintray to completely automate your software
development pipeline all the way to distribution.

Artifactory Pro

Learn about all the add-ons that let Artifactory work seamlessly with packaging formats
such as Docker, NuGet, Vagrant, RubyGems and more, as well as with all major CI
servers and build tools

Release Notes

Learn about the changes that came with each release of Artifactory.

Distributing Software Through Bintray
Bintray is JFrog's universal distribution platform.
Through tight integration, you can use Artifactory to push artifacts directly to your repositories in Bintray,
search through your Bintray repositories and more to fully automate your software distribution process. For
more details, please refer to Bintray Integration.
For more details on how to use Bintray, please refer to the Bintray User Guide.

Page Contents
Welcome to the JFrog Artifactory User Guide!
Which Artifactory Do You Need?
How is this Guide Organized?
Distributing Software Through Bintray

Quick Links

Artifactory REST
API

Recently Updated

Docker Registry

Release Notes

Artifactory REST API

29 minutes ago • updated by Rami Honig • view change
Artifactory REST API

about 9 hours ago • updated by Shlomi Kriheli • view change
HA Installation and Setup

yesterday at 7:39 PM • updated by Rami Honig • view change
User Plugins

yesterday at 2:44 PM • updated by Rami Honig • view change
JFrog Platform 5.7 - DONE

yesterday at 12:10 PM • updated by Rami Honig • view change
Working With Pipeline Jobs in Jenkins

yesterday at 10:53 AM • updated by Eyal Ben Moshe • view change
VCS Repositories

yesterday at 10:00 AM • updated by Rami Honig • view change
Release Notes

Nov 27, 2017 • updated by Rami Honig • view change
Release Notes 5.6.2

Nov 27, 2017 • updated by Rami Honig • view change
Getting Started with Artifactory as a Docker Registry

Nov 27, 2017 • updated by Rami Honig • view change

Installing Artifactory
Overview
This section provides a guide on the different ways you can install and configure Artifactory.

Installing Artifactory HA
There are different instructions for installing Artifactory HA
If you are installing an Artifactory HA cluster, please refer to HA Installation and Setup.
If you follow the instructions on this page for an installation of Artifactory HA, your HA cluster
will not work.

System Requirements
Before you install Artifactory please refer to System Requirements for information on supported platforms,
supported browsers and other requirements.

Installation
The installation procedure involves the following main steps:
1.
2.
3.
4.

Installing Artifactory
Configuring the database
Configuring the filestore
Configuring an HTTP Server (Optional)

Installing Artifactory
For detailed instructions, visit one of the following platform-specific pages:
Installing on Linux, Solaris or Mac OS
Installing on Windows
Installing with Docker

Configuring the Database
Artifactory comes with an embedded Derby Database out-of-the-box which it is pre-configured to use,
however, for better performance and to reuse existing infrastructures you may have, you can configure
Artifactory to work with alternative supported databases.
For details please refer to Configuring the Database.

Configuring the Filestore
By default, Artifactory is configured to use the local file system as its filestore. Artifactory supports a variety of
additional filestore configurations to meet a variety of needs for binary storage providers, storage size and
redundancy. For details, please refer to Configuring the Filestore.

Configuring an HTTP Server
You can run Artifactory with one of the supported HTTP servers set up as a front end. For details please refer
to Configuring a Reverse Proxy.
Page Contents
Overview
Installing Artifactory HA
System Requirements
Installation
Installing Artifactory
Configuring the Database
Configuring the Filestore
Configuring an HTTP Server
Directory Structure
Default Admin User
Watch the Screencast
Troubleshooting
Artifactory Does Not Start Up

Read more
System Requirements
Installing on Linux Solaris or Mac OS
Installing on Windows
Installing with Docker

Directory Structure
After installing Artifactory, the $ARTIFACTORY_HOME directory will contain the following directory structure (the $ARTIFACTORY_HOME directory
location depends on your installation type):

File/Folder

Description

access

The home directory of the bundled JFrog Access. More details in the Access Tokens page.

access/etc/keys

JFrog Access keys. More details in the Access Tokens page.

logs

Artifactory log files (general, access, request etc.)

etc

Configuration files

etc/plugins

Custom Groovy user plugins.

etc/security

Global security related files (configuring global encryption key, PGP signing key etc.).

etc/ui

Manually uploaded custom UI logos.

data/derby

The Derby database (only present when using Derby).

data/filestore

The checksum based storage of binaries when using the default filesystem storage.

data/tmp/work

Directory to save temporary files which Artifactory generates.

data/tmp/artifactory-uploads

Directory to save files uploaded using the Web UI.

bin

Artifactory startup/shutdown scripts.

tomcat

The default tomcat directory bundled with Artifactory.

tomcat/work

The tmp directory tomcat and the JVM uses (Tomcat automatically assigns it to a java system
environment variable as java.io.tmpdir)

tomcat/logs

Additional Tomcat log files

misc

Configuration files used as examples for different databases and servlet containers.

backup

The default backup directory Artifactory uses for system wide and repository backup.

webapps

Contains the Artifactory WAR file and the Access WAR file used by the bundled Tomcat distribution.
We strongly recommend keeping both these files in the same bundled Tomcat.

Default Admin User
Once installation is complete, Artifactory has a default user with admin privileges predefined in the system:
User: admin
Password: password
Change the admin password
We strongly recommend changing the admin password as soon as installation is complete.

Watch the Screencast

Troubleshooting
Artifactory Does Not Start Up
There are no log file entries in $ARTIFACTORY_HOME/logs/artifactory.log
Cause

An exception was thrown (possibly by your servlet container) before Artifactory loaded its logging mechanism.

Resolution

Check your servlet container's localhost.log file. For more information, please refer to Artifactory Log Files.

System Requirements
Supported Platforms
Artifactory has been tested and verified on Linux, Windows (Vista and higher), Solaris and Mac OS X. You
should be able to run Artifactory on other platforms, but these have not been tested.

JDK
You must run Artifactory with JDK 8, preferably JDK 8 update 45 and above.
You can download the latest JDK from the Oracle Java SE Download Site.

JAVA_HOME and JRE_HOME
Make sure your JAVA_HOME environment variable correctly points to your JDK 8 installation.
If you also have JRE_HOME defined in your system, this will take precedence over JAVA_HOME
and therefore you need to either point JRE_HOME to your JDK 8 installation, or remove the
JRE_HOME definition.

Page Contents
Supported Platforms
JDK
JVM Memory
Allocation
Browsers
Recommended
Hardware
Working with
Very Large
Storage
High Availability
Configuration
Database
Requirements
Servlet Containers

JVM Memory Allocation
While not a strict requirement, we recommend that you modify the JVM memory parameters used to run Artifactory.
You should reserve at least 512MB for Artifactory, and the recommended values for JVM parameters are as follows:
Recommended JVM parameters
The larger your repository or number of concurrent users, the larger you need to make the -Xms and -Xmx values accordingly.
Recommended values are:
-server -Xms512m -Xmx2g -Xss256k -XX:+UseG1GC
To set your JVM parameters according to your platform, please refer to the corresponding instructions for Linux, Solaris or Mac, or Windows.

Browsers
Artifactory has been tested with the latest versions of Google Chrome, Firefox, Internet Explorer and Safari.

Recommended Hardware
The following table provides hardware recommendations for a single server machine:
Number of
developers

OS/JVM

Processor

*Memory (RAM) for
JVM Heap

Storage

1 - 20

64 bit

4 cores

4GB

Fast disk with free space that is at least 3 times the total size of stored
artifacts

20 - 100

64 bit

4 cores

8GB

Fast disk with free space that is at least 3 times the total size of stored
artifacts

100 - 200

64 bit

8 cores (16 cores
recommended)

12GB

Fast disk with free space that is at least 3 times the total size of stored
artifacts (backup SAN recommended)

200+

64 bit

Please contact JFrog support for a recommended setup.

*Memory (RAM) for JVM Heap
This specifies the amount of memory that Artifactory requires from the JVM heap. The server machine should have enough additional
memory to run the operating system and any other processes running on the machine.

Build machine
For the purposes of this table, a build machine is considered equivalent to 10 developers

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
. 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, please contact JFrog support who will work with you to provide a recommendation for
storage that is customized to your specific setup.

High Availability Configuration
If you are running Artifactory in a High Availability configuration, to maintain high system performance in case of single or multiple server crash,
we recommend following the recommended hardware guidelines above for each of the HA server instances. For more details, please refer to Artif
actory High Availability.

Database Requirements
To avoid network latency issues when reading and writing artifacts data, we strongly recommend creating the database either on a machine that
is network close (latency well below 1 ms) to the machine on which Artifactory is running (database engine and storage) with fast storage. This
recommendation is critical when using fullDb (whereby files are served from database BLOBs) and the file system cache is small.
For supported databases and more details, please refer to Configuring the Database.

Servlet Containers
Artifactory should be run with its bundled Tomcat 8 servlet container.
From version 5.0, Artifactory is bundled with Tomcat version 8.0.39.

Installing on Linux Solaris or Mac OS
Overview
Make sure you have reviewed the overall installation process
Before you proceed with the instructions on this page, make sure you have reviewed the whole
installation procedure as described in Installing Artifactory.
This page describes how to install Artifactory on Linux, Solaris or Mac OS.

The procedure for all these platforms is identical, so for the sake of clarity the rest of this page will refer to
Linux only.
You can install Artifactory on your Linux system in one of the following ways:
Manual Installation
Service Installation
RPM or Debian Installation
As a Docker Image
Running as root to install Artifactory as a service or RPM distribution
To install Artifactory as a service or RPM distribution you must have root privileges.
To run as root either execute the following command:
su or precede all commands with sudo (e.g. sudo service artifactory start)
If you are unable to get root privileges please contact your system administrator.

Configuring Your Database and Filestore
Once you have completed installing Artifactory, make sure you configure its database and filestore according
to your preference. For details, please refer to Configuring the Database and Configuring the Filestore.
Page Contents
Overview
Configuring
Your
Database and
Filestore
Requirements
Setting
JAVA_HOME
Setting Java
Memory
Parameters
Manual Installation
Installing
Artifactory
Running
Artifactory
Service Installation
Installing
Artifactory
Running
Artifactory
Using
syste
md
Using
init.d
Chec
king
the
Artifa
ctory
Log
RPM or Debian
Installation
Managed Files
and Folders
Installing
Artifactory
Running
Artifactory
Backup and
Recover
Running with Docker

The ARTIFACTORY_
HOME Folder
Accessing Artifactory

Requirements
Setting JAVA_HOME
As mentioned in the section on System Requirements, make sure that your JAVA_HOME environment variable is correctly set to your JDK
installation.

Setting Java Memory Parameters
While not a strict requirement, it is recommended to modify the JVM memory parameters used to run Artifactory.
If you can reserve at least 512MB for Artifactory, the recommended values for JVM parameters are:
Recommended minimal JVM parameters
The larger your repository or number of concurrent users, the larger you need to make the -Xms and -Xmx values accordingly.
Recommended minimal values are:
-server -Xms512m -Xmx2g -Xss256k -XX:+UseG1GC
For more recommendations about your hardware configuration (especially the -Xmx parameter), please refer to Recommended
Hardware.
Where you set your JVM parameters depends on how you are running Artifactory:
For a manual installation, modify JAVA_OPTIONS in $ARTIFACTORY_HOME/bin/artifactory.default.
For a service installation, modify JAVA_OPTIONS in $ARTIFACTORY_HOME/etc/default (you will need to stop and then restart the
service after making the modification)
For an RPM or Debian installation, modify JAVA_OPTIONS in /etc/opt/jfrog/artifactory/default

Manual Installation
Installing Artifactory
To install Artifactory manually, simply unzip the Artifactory download file to a location on your file system. This will be your $ARTIFACTORY_HOME
location.
No further action is needed.
Don't forget to modify your JVM parameters as needed by setting JAVA_OPTIONS in $ARTIFACTORY_HOME/bin/artifactory.de
fault.

Running Artifactory
You can run Artifactory manually to see its behavior by directly executing:
$ARTIFACTORY_HOME/bin/artifactory.sh
The console is locked on the Artifactory process and you can stop it cleanly with Ctrl+C.
To directly run Artifactory as a daemon process, using the environment variables of the shell you are currently in, execute the following script:

$ARTIFACTORY_HOME/bin/artifactoryctl start

Startup time
Depending on your system performance it may take Artifactory several seconds to start up. If you try to access Artifactory through your
browser while it is starting up, within a few seconds it will provide a notification that it is in the startup process.
Using the same script, you can check if Artifactory is running and display its process id, or stop it using:

Checking if Artifactory is running or stopping it
$ARTIFACTORY_HOME/bin/artifactoryctl check | stop

To run the Artifactory UI see Accessing Artifactory.

Service Installation
Artifactory is packaged as a zip file with a bundled Tomcat, and a complete install script that can be used to install it as a service running under a
custom user.
Permissions
When running Artifactory as a service, the installation script creates a user called Artifactory which must have run and execute
permissions on the installation directory.
Therefore it is recommended to extract the Artifactory download file into a directory that gives run and execute permissions to all users
such as /opt

Not supported on Mac OS
The service Installation is currently supported only on Linux and Solaris. It is not supported with Mac OS.

Don't forget to modify your JVM parameters as needed by setting JAVA_OPTIONS in $ARTIFACTORY_HOME/etc/default.
You need to reinstall the service for your changes to take effect.

Installing Artifactory
To install Artifactory as a service, browse to your $ARTIFACTORY_HOME/bin directory and execute the following command as
root:

Running the installation script as root
$ARTIFACTORY_HOME/bin/installService.sh [USER [GROUP]]

The following table describes the sequence of commands performed by the install script:

User
creation

Creates a default user named artifactory ($ARTIFACTORY_USER). You can change the default user by editing the $ARTIFAC
TORY_USER value in /etc/opt/jfrog/artifactory/default.
You can also optionally run the install script to start the Artifactory service under a different user by passing in the user name as
the first parameter. If you include the user name, you may also optionally include a group.

etc config

Creates the folder /etc/opt/jfrog/artifactory, copies the configuration files there and creates a soft link in$ARTIFACTOR
Y_HOME/etc

Creates the file /etc/opt/jfrog/artifactory/default containing the main environment variables needed for Artifactory to
run:JAVA_HOME, ARTIFACTORY_USER, ARTIFACTORY_HOME, JAVA_OPTIONS,...
The /etc/opt/jfrog/artifactory/default is included at the top of artifactoryctl and can include any settings.

etc
default

To modify your JVM parameters modify JAVA_OPTIONS in /etc/opt/jfrog/artifactory/default
If you are running on a Linux distribution that supports systemd, the install script will use it to install Artifactory - otherwise init.
d will be used.

systemd
or init.

If systemd is supported, the install script copies the service script file artifactory to /etc/systemd/system/artifactor
y.service
If systemd is not supported and init.d is used, the install script copies the service script file artifactory to /etc/init.d/
artifactory
Creates the folder $ARTIFACTORY_HOME/logs, makes it writable for the user ARTIFACTORY_USER and creates a soft link $ART
IFACTORY_HOME/logs/catalina.

Logs
folder

The $ARTIFACTORY_HOME/tomcat/logs folder is linked to $ARTIFACTORY_HOME/logs/catalina.
Creates the folder $ARTIFACTORY_HOME/backup, so you must create a link if you want this folder to point to a different place
(such as /var/backup/artifactory for example). The script makes $ARTIFACTORY_HOME/backup writable for the user AR
TIFACTORY_USER.

Backup
folder

Creates the folder $ARTIFACTORY_HOME/data, so you must create a link if you want this folder to point to somewhere else. The
script makes it writable for the user ARTIFACTORY_USER.

Data
folder

The script calls add and list (you can see the output), and then activates the Artifactory service
chkconfig
calls

Running Artifactory
To start or stop Artifactory as a service you must be running as root. The command you use depends on whether the Artifactory service was
installed using systemd or init.d.

Using systemd
Start or stop Artifactory using:

Artifactory installed with systemd
systemctl artifactory.service

Checking the status of the Artifactory service
Once Artifactory is correctly installed, you can check if it is running with:
systemctl status artifactory.service
If Artifactory is running, you should see its pid.
If Artifactory is not running you will see a list of environment variables used by the service.

Using init.d
Start or stop Artifactory using

Artifactory installed with init.d
service artifactory

Checking the status of the Artifactory service
Once Artifactory is correctly installed, you can check if it is running with:
service artifactory check
If Artifactory is running, you should see its pid.
If Artifactory is not running you will see a list of environment variables used by the service.

Checking the Artifactory Log
You can check the Artifactory log to see the status of the service using:

tail -f $ARTIFACTORY_HOME/logs/artifactory.log

RPM or Debian Installation
Artifactory can also be installed from an RPM or Debian distribution on Red Hat compatible Linux distributions.
The installation package creates a dedicated user, installs a stripped-down distribution of the Apache Tomcat container configured for Artifactory
(on port 8081), and registers this Tomcat as a service (but does not start it immediately).
This package effectively replaces the different setup scripts included with the Artifactory Zip distribution.

Managed Files and Folders
When installed from an RPM distribution, Artifactory retains the FHS (Filesystem Hierarchy Standard) format:

File/Folder

Location

Ownership

Artifactory home

/var/opt/jfrog/artifactory

artifactory

Artifactory etc

/etc/opt/jfrog/artifactory

artifactory

Artifactory logs

/var/opt/jfrog/artifactory/logs

artifactory

Artifactory env variables

/etc/opt/jfrog/artifactory/default

artifactory

Tomcat home

/opt/jfrog/artifactory/tomcat

artifactory (root for sub dirs)

Artifactory startup script

/etc/init.d/artifactory

root

Artifactory binary

/opt/jfrog/artifactory

root

Installing Artifactory
To install Artifactory from an RPM or Debian distribution you must be running as root and can use the corresponding commands below:
Installing Artifactory Pro from an RPM distribution...
wget 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/
sudo yum install jfrog-artifactory-pro
Installing Artifactory OSS from an RPM disribution
wget https://bintray.com/jfrog/artifactory-rpms/rpm -O bintray-jfrog-artifactory-rpms.repo
sudo mv bintray-jfrog-artifactory-rpms.repo /etc/yum.repos.d/
sudo yum install jfrog-artifactory-oss
Installing Artifactory Pro from a Debian distribution...
echo "deb https://jfrog.bintray.com/artifactory-pro-debs {distribution} {components}" | sudo tee -a /etc/apt/sources.list

Note: If you are unsure, components should be "main." To determine your distribution, run lsb_release -c
Example: echo "deb https://jfrog.bintray.com/artifactory-pro-debs xenial main" | sudo tee -a /etc/apt/sources.list
curl https://bintray.com/user/downloadSubjectPublicKey?username=jfrog | sudo apt-key add sudo apt-get update
sudo apt-get install jfrog-artifactory-pro
Installing Artifactory OSS from a Debian distribution...
echo "deb https://jfrog.bintray.com/artifactory-debs {distribution} {components}" | sudo tee -a /etc/apt/sources.list
Note: If you are unsure, components should be "main." To determine your distribution, run lsb_release -c
Example: echo "deb https://jfrog.bintray.com/artifactory-debs xenial main" | sudo tee -a /etc/apt/sources.list
curl https://bintray.com/user/downloadSubjectPublicKey?username=jfrog | sudo apt-key add sudo apt-get update
sudo apt-get install jfrog-artifactory-oss
JVM parameters
Make sure to modify your JVM parameters by modifying JAVA_OPTIONS in /etc/opt/jfrog/artifactory/default as appropriate for
your installation.

Running Artifactory
To start or stop Artifactory you must be running as root and can use the following command:

service artifactory start | stop

You can also check the Artifactory log with:

tail -f $ARTIFACTORY_HOME/logs/artifactory.log

When installing from an RPM distribution, Artifactory is generally started as root and will su internally to the $ARTIFACTORY_USER user.
Security
For reasons of security, it is not recommended to leave the $ARTIFACTORY_USER variable undefined with Artifactory running as the
current user, especially if the current user is root.

Backup and Recover
When uninstalling an RPM distribution of Artifactory, it will save the $ARTIFACTORY_HOME folder and create a backup folder at /var/opt/jfro
g/ while preserving symbolic links to remote filestores.
After installing a new instance of Artifactory, you can recover the configuration and filestore from this backup by running the script $ARTIFACTOR
Y_BINARY/bin/recover.backup.sh.

Working with an external database
This process does not back up an external database, but rather its definitions in Artifactory. Therefore, when working with an external
database, a manual dump should be performed before uninstalling the RPM, and then imported when starting the new installation.

Installing/Upgrading on a new machine
The Backup and Recover described above will only work if you are re-installing the RPM on the same machine. If you are installing or
upgrading the RPM on a new machine you will need to use Import as described in the section on Upgrading Artifactory.

Running with Docker
From Version 3.6, Artifactory may be pulled as a Docker Image. For full details, please refer to Installing with Docker.

The ARTIFACTORY_HOME Folder
It is important to know where your Artifactory home folder is located, since this folder stores your configurations and important repository data.
When Artifactory runs for the first time, it sets up a default configuration and creates all necessary files and folders under the ARTIFACTORY_HOM
E folder.
The default location of ARTIFACTORY_HOME is {user.home}/.artifactory.
To run Artifactory with the home folder set to a different location on the file system (particularly when installing Artifactory on a production server),
either:
Start the Tomcat virtual machine with -Dartifactory.home=
- or Set an ARTIFACTORY_HOME environment variable pointing to your preferred location before running the installation.
Artifactory creates the home folder on startup if it does not already exist.
Permissions on the Artifactory Home Folder
Make sure that the user running the Tomcat has write permissions on the Artifactory home folder.

Accessing Artifactory
Artifactory can be accessed using the following URL:
http://SERVER_DOMAIN:8081/artifactory
For example, if you are testing on your local machine you would use: http://localhost:8081/artifactory

Installing on Windows
Overview
Make sure you have reviewed the overall installation process
Before you proceed with the instructions on this page, make sure you have reviewed the whole
installation procedure as described in Installing Artifactory.
There are three ways to install Artifactory on your Windows system:
Manual Installation
Service Installation
As a Docker Image
Unzip the Artifactory download file to a location on your file system.
This will be your %ARTIFACTORY_HOME% location.
Define this location as an environment variable called ARTIFACTORY_HOME.

Requirements
Setting JAVA_HOME
As mentioned in the section on System Requirements, make sure that your JAVA_HOME environment variable is correctly set to your JDK
installation.
Troubleshooting
Note that normally the installation path to your JAVA_HOME might include a space, e.g. c:\Program Files (x86)\java\jdk, this might
cause an issue and result in error "Files was unexpected at this time", in which case you will need to replace the Program Files (x86) wit
h PROGRA~2 and make sure there are no spaces in the path.

Setting Java Memory Parameters
While not a strict requirement, it is recommended to modify the JVM memory parameters used to run Artifactory.
This is done by modifying the JAVA_OPTIONS variable in artifactory.bat, for a manual installation, or the JOPTS variable in installServ
ice.bat when running Artifactory as a service.
For your changes to take effect you need to stop Artifactory and then rerun the modified file.
If you can reserve at least 512MB for Artifactory, the recommended values for JVM parameters are as follows:
Recommended JVM parameter settings
The larger your repository or number of concurrent users, the larger you need to make the -Xms and -Xmx values accordingly.
Recommended values are:
-server -Xms512m -Xmx2g -Xss256k -XX:+UseG1GC

Manual Installation
Browse to %ARTIFACTORY_HOME%\bin and execute the file artifactory.bat. This script searches for the Java executable and runs
Artifactory's main class.
Security settings

Depending on the security settings under Windows, you might need to run artifactory.bat using 'Run as administrator'

Don't forget to modify your JVM parameters as needed by setting JAVA_OPTIONS in $ARTIFACTORY_HOME/bin/artifactory.ba
t.
To test your installation see Accessing Artifactory.

Service Installation
Artifactory makes use of the Apache Commons Procrun components allowing you to install the application as a Windows Service.
To run Artifactory as a Windows service, browse to %ARTIFACTORY_HOME%\bin, and execute the file InstallService.bat.
By editing InstallService.bat, you can modify default properties such as JOPTS and the log directory.
For your changes to take effect you need to stop the currently running Artifactory service and run InstallService.bat again once you have
completed your modifications.
To test your installation see Accessing Artifactory.
Security
Windows 8 implements strict User Account Control (UAC). You must either disable UAC or right-click on cmd.exe and select "Run as
administrator" in order to run this script.

Running on 32 bit Windows
If you are running a 32 bit version of Windows you need to do the following:
Download the latest version of the Apache Commons Daemon.
Take prunsvr.exe from the downloaded archive and rename it to artifactory-service.exe
Replace the current artifactory-service.exe found in your %ARTIFACTORY_HOME%/bin directory

Don't forget to modify your JVM parametersas needed by setting JAVA_OPTIONS in $ARTIFACTORY_HOME/etc/default.
You need to reinstall the service for your changes to take effect.

Running Artifactory
After installing Artifactory you need to start the service.
To start or stop Artifactory as a service you can use the following command in a Command Prompt window:

Starting and stopping the Artifactory service
sc start|stop Artifactory

Checking the status of the Artifactory service
Once Artifactory is correctly installed, you can check if it is running with:
sc query Artifactory

You can also use any standard text editor to view the artifactory log data found in $ARTIFACTORY_HOME/logs/artifactory.log

Running with Docker

From Version 3.6, Artifactory may be pulled as a Docker Image. To run Artifactory in a Docker container on a Windows system, you first need to
install boot2docker.
For full details, please refer to Installing with Docker.

Accessing Artifactory
Artifactory can be accessed using the following URL:
http://SERVER_DOMAIN:8081/artifactory.
For example, if you are testing on your local machine you would use: http://localhost:8081/artifactory

Installing with Docker
Overview
Make sure you have reviewed the overall installation process
Before you proceed with the instructions on this page, make sure you have reviewed the
whole installation procedure as described in Installing Artifactory.
Artifactory Docker images can be pulled from Bintray and run as a Docker container.
To do this, you need to have Docker client properly installed and configured on your machine. For
details about installing and using Docker, please refer to the Docker documentation.
Running with Docker for Artifactory 4.x
Artifactory as a Docker container has been completely redesigned in version 5.0. If you
are running previous versions of Artifactory, please refer to Running with Docker in the
Artifactory 4.x User Guide

Docker Compose
The way we recommend running Artifactory on Docker is to orchestrate your setup using
Docker Compose. This will ensure you have all the required services specified in a single
YAML file with pre-configured parameters.

Using Docker Compose
To setup an Artifactory environment made of multiple containers (for example, a database, an
Nginx load balancer and Artifactory each running in a different container), you can use docker-co
mpose.
For more details on Docker Compose, please refer to the Docker documentation.
Artifactory OSS, Artifactory Pro and Artifactory HA can all be run using Docker Compose. For
detailed documentation and sample Compose files showing a variety of ways to setup Artifactory
with Docker Compose, please refer to the artifactory-docker-examples repository on GitHub.

Page contents
Overview
Using Docker Compose
Artifactory on Docker
Pulling the
Artifactory
Docker Image
Running an
Artifactory
Container
Managing Data
Persistence
Using Host
Directories
Using a Docker
Named Volume
Upgrading Artifactory
Running Artifactory With
a Different Database
Building Artifactory OSS
From Sources
Accessing Artifactory
Troubleshooting Docker
Container State
Logs
Connect to a
Running
Container
Run an
Alternate
Entrypoint
Watch the Screencast

Read more
Building Artifactory OSS
Changing the Database

Artifactory on Docker
Running Artifactory as a container is simple and straightforward, and involves the following basic steps:
Pulling the Artifactory Docker Image
Running the Artifactory Container
Since the Artifactory instance running in a Docker container is mutable, all data and configuration files will be lost once the container is

removed. If you want your data to persist (for example when upgrading to a new version), you should also follow the next step.
Managing Data Persistence

Pulling the Artifactory Docker Image
The Artifactory Docker image may be pulled from Bintray by executing the corresponding Docker command below depending on whether you
are pulling Artifactory OSS or Artifactory Pro:

Pulling the Artifactory Pro Docker Image
docker pull docker.bintray.io/jfrog/artifactory-pro:latest

Pulling the Artifactory OSS Docker Image
docker pull docker.bintray.io/jfrog/artifactory-oss:latest

Running an Artifactory Container
You can list the Docker images you have downloaded using the docker images command, which should display something like the following
output:

$ docker images
REPOSITORY
CREATED
SIZE
docker.bintray.io/jfrog/artifactory-pro
2 days ago
861.5 MB
...

TAG
latest

IMAGE ID
da70b82904e7

To start an Artifactory container, use the corresponding command below according to whether you are running Artifactory Pro or Artifactory
OSS:

Running Artifactory Pro in a container
$ docker run --name artifactory -d -p 8081:8081
docker.bintray.io/jfrog/artifactory-pro:latest

Running Artifactory OSS in a container
$ docker run --name artifactory -d -p 8081:8081
docker.bintray.io/jfrog/artifactory-oss:latest

Managing Data Persistence
For your data and configuration to remain once the Artifactory Docker container is removed, you need to store them on an external volume

mounted to the Docker container. There are two ways to do this:
Using Host Directories
Using a Docker Named Volume

Using Host Directories
The external volume is a directory in your host's file system (such as /var/opt/jfrog/artifactory). When you pass this to the docker run com
mand, the Artifactory process will use it to read configuration and store its data.
To mount the above example, you would use the following command:

$ docker run --name artifactory-pro -d -v
/var/opt/jfrog/artifactory:/var/opt/jfrog/artifactory -p 8081:8081
docker.bintray.io/jfrog/artifactory-pro:latest

This mounts the /var/opt/jfrog/artifactory directory on your host machine to the container's /var/opt/jfrog/artifactory and will then be used
by Artifactory for configuration and data.

Using a Docker Named Volume
In this case, you create a docker named volume and pass it to the container. By default, the named volume is a local directory under /var/l
ib/docker/volumes/, but can be set to work with other locations. For more details, please refer to the Docker documentation for
Docker Volumes.
The example below creates a Docker named volume called artifactory_data and mounts it to the Artifactory container under /var/opt/jfrog/a
rtifactory:

$ docker volume create --name artifactory5_data
$ docker run --name artifactory-pro -d -v
artifactory5_data:/var/opt/jfrog/artifactory -p 8081:8081
docker.bintray.io/jfrog/artifactory-pro:latest

In this case, even if the container is stopped and removed, the volume persists and can be attached to a new running container using the
above docker run command.

Upgrading Artifactory
For details on how to upgrade Artifactory running in a Docker container, please refer to Running in a Docker Container in the Upgrading
Artifactory page.

Running Artifactory With a Different Database
By default, Artifactory runs with an embedded Derby Database that comes built-in, however, Artifactory supports additional databases. To
switch to one of the other supported databases, please refer to Changing the Database.

Building Artifactory OSS From Sources
The Artifactory OSS Docker image sources are available for download allowing you to build the image yourself. For details, please refer to Bu
ilding Artifactory OSS.

Accessing Artifactory
Once the Artifactory container is up and running, you access Artifactory in the usual way by browsing to:

http://SERVER_DOMAIN:8081/artifactory

For example, if you are testing on your local machine you would use: http://localhost:8081/artifactory

Troubleshooting Docker
This section describes different ways you can troubleshoot a running or stopped Docker container that is not functioning as expected.

Container State
The docker ps command lists containers in your system.

$ docker ps
$ docker ps -a

# Lists running containers
# Lists all containers

Logs
Artifactory logs are stored in the Artifactory container under /var/opt/jfrog/artifactory/logs.
If you ran the container with a mounted volume for Artifactory data (/var/opt/jfrog/artifactory/), you can also access the logs
locally on your host.
An easy way to see the logged output of a running container is through the docker logs command

$ docker logs

This will output all of the container's STDOUT and STDERR to the screen both for running and stopped containers.

Connect to a Running Container
You can connect to a running container's file system and open an interactive command prompt in the container with the docker exec comm
and

$ docker exec -it /bin/bash

This will open a command prompt in the running Artifactory container, logging you in as root and placing you in the / directory.

Run an Alternate Entrypoint
There are cases where you want to run the container, but not start up Artifactory. To do this, you need to override the configured entrypoint
script using docker run --entrypoint=bash

$ docker run -it --entrypoint=/bin/bash -v
/var/opt/jfrog/artifactory:/var/opt/jfrog/artifactory -p 8081:8018
docker.bintray.io/jfrog/artifactory-pro:latest

This will run the container, presenting you with a prompt in the container, but without executing the /entrypoint-artifactory.sh file.
You can then make changes to the container configuration execute /entrypoint-artifactory.sh to start up Artifactory in your

container.

Watch the Screencast

Building Artifactory OSS
Overview

Page contents
Overview
Getting the
Artifactory OSS
Sources
Building the
Artifactory OSS
Docker Image
Running the
Artifactory OSS
Container
Accessing
Artifactory

The Artifactory OSS Docker image sources are freely available for download allowing you to build
and if necessary, tune it according to your needs.

Getting the Artifactory OSS Sources
For Artifactory OSS, the latest sources can be downloaded from Bintray to be built on your own
machines using the following link:

Building the Artifactory OSS Docker Image
To build the image, you can use the Docker native client or install Docker for your platform by downloading Docker for Macor Docker for
Windows.
The following code snippet shows an example of how to build the Artifactory OSS 5.0 Docker image on a Mac:

$ mkdir ~/git/artifactory.5.0/
$ cd ~/git/artifactory.5.0/
$ # unzip the Artifactory source bundle you downloaded from Bintray in
to the directory you created
$ cd ~/git/artifactory.5.0/artifactory-oss/distribution/docker
$ mvn clean package -Pdocker

Running the Artifactory OSS Container
You can list the Docker images you have built using the docker images command, which should display something like the following output:

$ docker images
REPOSITORY
CREATED
SIZE
jfrog/artifactory-oss
minutes ago
741.7 MB
...

TAG
5.0.0

To start an Artifactory OSS container for the image shown in the example above, use:

IMAGE ID
da70b82904e7

$ docker run --name artifactory-5.0.0 -d -p 8081:8081
jfrog/artifactory-oss:5.0.0

Accessing Artifactory
Once the Artifactory container is up and running, you access Artifactory in the usual way by browsing to:
http://SERVER_DOMAIN:8081/artifactory.
For example, if you are testing on your local machine you would use: http://localhost:8081/artifactory

Changing the Database
Overview

Page contents

By default, Artifactory runs with an embedded Derby database that comes built-in. However,
Artifactory supports additional databases as described in Configuring the Database.
To configure your Artifactory Docker container to run with one of the other supported databases,
you need to:
1. Mount the relevant database driver into Artifactory's tomcat/lib directory
Using PostgreSQL
If you are changing the database to PostgreSQL, note that the Artifactory
Docker image comes pre-loaded with the PostgreSQL database driver.
2. Pass environment variables to Artifactory in the docker run command
3. Pass database parameters as Docker environment variables telling Artifactory how to
configure the database in the docker run command

Overview
Mounting the
Database
Driver
Passing
Environment
Variables
Pass Database
Parameters
Examples
Postgr
eSQL
MySQ
L

Mounting the Database Driver
To mount the database driver, you first need to download its corresponding jar file from the vendor's web site provided in the following links:
MySQL
Oracle JDBC
MS SQL
PostgreSQL

Passing Environment Variables
Once you have the downloaded the database driver JAR file, you mount it into the Artifactory container using docker run with the -v option:

docker run ... -v
:/opt/jfrog/artifactory/tomcat/lib/

Without passing the DB parameters mentioned below, Artifactory will ignore the added jar.

Pass Database Parameters

For Artifactory in Docker to know what database to use, you need to pass in some parameters as Docker environment variables using docke
r run with the -e option

docker run ... -e PARAM=

The following table describes the parameters supported:
Values: postgresql, mysql, oracle or mssql
DB_TYPE

Default: blank indicating Artifactory should run with the built-in Derby database
The hostname/ip of the server where the database is installed

DB_HOST

If this value is omitted, DB_HOST defaults to the value set in DB_TYPE
The database port

DB_PORT

Defaults to the value set in the corresponding db.properties file
The full database URL

DB_URL

Defaults to the value set in the corresponding db.properties file
The database username

DB_USER

Defaults to the value set in the corresponding db.properties file
The database password

DB_PASSWORD

Defaults to the value set in the corresponding db.properties file

During execution of the docker run, an entrypoint script will copy the matching db.properties from the misc/db/ directory to the etc/
directory and configure it.
If etc/db.properties already exists, the script will just validate it and Artifactory will work with the specified database.

Examples
Below are examples that show how Artifactory can be run in Docker with a custom database.
PostgreSQL

In this example for PostgreSQL, since only DB_TYPE is specified, the rest of the parameters will be set to their defaults taken from the
PostgreSQL db.properties file.
The PostgreSQL database driver is already in the Artifactory Docker image, so you don't need to mount it.

$ docker run -d
-e
-v
-p

--name artifactory-5 \
DB_TYPE=postgresql \
/var/opt/jfrog/artifactory:/var/opt/jfrog/artifactory \
8081:8081 docker.bintray.io/jfrog/artifactory-pro:latest

You can verify that Artifactory is running with PostgreSQL under Admin | System Info which specifies the Database Type.
MySQL

This example for MySQL uses custom database host, port, username and password settings.
The MySQL database driver is mounted in to the container's /opt/jfrog/artifactory/tomcat/lib/ directory.

$ docker run -d --name artifactory-5 \
-e DB_TYPE=mysql \
-e DB_HOST=mysql5srv.jfrog.local \
-e DB_PORT=33307 \
-e DB_USER=artifactory17 \
-e DB_PASSWORD=pass17arti56_x \
-v
~/mysql-connector-java-5.1.40-bin.jar:/opt/jfrog/artifactory/tomcat/lib/
mysql-connector-java-5.1.40-bin.jar \
-v /var/opt/jfrog/artifactory:/var/opt/jfrog/artifactory \
-p 8081:8081 docker.bintray.io/jfrog/artifactory-pro:latest

You can verify that Artifactory is running with MySQL under Admin | System Info which specifies the Database Type.

Upgrading Artifactory
Overview
The procedure to upgrade Artifactory depends on your installation type. We strongly recommend
reading through this page before proceeding with your upgrade. Detailed upgrade instructions are
provided in dedicated pages for the following installation types:
ZIP file
RPM
Debian
Docker
In addition, within each installation type, there may be slight variation in instructions if you are
upgrading from older versions of Artifactory.

Before You Proceed
Before you upgrade
We strongly recommend that you take the following actions to ensure you can roll back
your system in case you encounter any issues during the upgrade process:
1. 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.
2. Back up your database.
Before proceeding, there are a few points you need to address:
1. JDK Version
From version 4.0, Artifactory requires JDK 8. If your current version is v3.x, before you
upgrade to Artifactory 5.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 version is 3.x and the 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. 'Slash' character encoding for NPM builds
Handling of 'slash' character encoding for NPM has been moved from the artifactory.syste
m.properties file to the catalina.properties file of your Tomcat. For details, please refer to N
pm Scope Packages.

Page Contents
Overview
Before
You
Proce
ed
Upgrading
Artifactory
Enterprise / HA
Upgrading to
the Latest
Version
ZIP
Install
ation
Debia
n
Install
ation
Docke
r
Install
ation
RPM
Install
ation
RPM
OSS
Install
ation
Using SHA256
Checksums
Upgrading from
OSS to Pro
Upgrading from
Version 3.x
Single
Packa
ge
Type
Reposi
tories
Migrati
ng to
Single
Packa
ge
Type
Reposi
tories
Fixing
Multipl
e
Packa
ge
Type
Reposi
tories
Upgrading from
Any Version
Below v3.0
Downgrading
Artifactory
Watch the
Screencast

Learn more
Upgrading an
Enterprise HA
Cluster

Upgrading Artifactory Enterprise / HA
There are different instructions for upgrading Artifactory HA
When upgrading an HA cluster, the procedure for upgrading each node is similar to upgrading a single instance (Non-HA)
installation, however, there are additional actions required for the nodes to operate as a high availability cluster.
If you are upgrading an Artifactory HA cluster, please refer to Upgrading an Enterprise HA Cluster.

Upgrading to the Latest Version
Upgrading from version 4.x or 5.x to the latest version is a simple procedure. Please refer to the sections below with specific instructions for
your installation type.

ZIP Installation
Upgrading a ZIP 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. Backup files to a temporary location according to the conditions described below:
a. In all cases, backup $ARTIFACTORY_HOME/bin/artifactory.default
b. If Artifactory is configured to work with a database that is not Derby, backup the $ARTIFACTORY_HOME/tomcat/lib/ driver.
4. Remove the following files and folders from your $ARTIFACTORY_HOME folder:
webapps/artifactory.war
webapps/access.war (this will only be present if your current version is 5.4.0 and above
due to addition of the Access Service)
tomcat
bin
misc
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.
Running Artifactory as ROOT
If you have configured Artifactory to run as the ROOT application in Tomcat, before you proceed, you need to follow
the steps described in this Knowledge Base article.

Upgrading to version 5.4.0 and above
From version 5.4.0, Artifactory's management of Access Tokens was moved to a separate service, Access, installed
as a separate web application under the same Tomcat as Artifactory. This requires your Tomcat's server.xml to be
configured to allow running 2 processes. If you are using a server.xml file from a previous installation, when returning
it, make sure it is configured to allow 2 start/stop threads as shown below (see ):

...

7. If you installed Artifactory as a service, you now need to run the service
a. For a Linux service, browse to $ARTIFACTORY_HOME/bin and execute the following command as root: $ARTIFACTO
RY_HOME/bin/installService.sh [USER [GROUP]]
b. For Windows service, browse to %ARTIFACTORY_HOME%\bin and run InstallService.bat.

Debian Installation
Upgrading a Debian installation...
1. Log in as root (or use sudo su -).
2. Execute the following command:

dpkg -i $jfrog-artifactory--5.y.z.deb

Managing Configuration Files
When upgrading a Debian installation the upgrade process overwrites the following set of configuration files:
system.properties
config.xml
default
logback.xml
mimetypes.xml
All files under opt/jfrog/artifactory/misc
All files under opt/jfrog/artifactory/webapps
If any of these files were modified, 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.
Running Artifactory as ROOT
If you have configured Artifactory to run as the ROOT application in Tomcat, before you proceed, you need to follow the steps
described in this Knowledge Base article.

Upgrading to version 5.4.0 and above
From version 5.4.0, Artifactory's management of Access Tokens was moved to a separate service, Access, installed as a
separate web application under the same Tomcat as Artifactory. This requires your Tomcat's server.xml to be configured to
allow running 2 processes. If you are using a server.xml file from a previous installation, when returning it, make sure it is
configured to allow 2 start/stop threads as shown below (see ):

...

Docker Installation
Upgrading a Docker installation...
In order to keep your data and configuration between versions, when upgrading the Artifactory Docker image, you need to use an
external mounted volume as described under Managing Data Persistence.
To upgrade the Artifactory Docker image, follow these steps:
1. Stop current container
2. Start a container with new version, using same data and configuration
3. Remove old container
The example below shows this process for upgrading Artifactory from v5.0.0 to v5.1.0.

$ # Stop the currently running container
$ docker stop artifactory-5.0.0
$ # Start a new container from the new version image
$ docker run -d --name artifactory-5.1.0
--volumes-from=artifactory-5.0.0 -p 8081:8081
docker.bintray.io/jfrog/artifactory-pro:5.1.0
$ # Remove old container
$ docker rm artifactory-5.0.0

Once these commands have completed successfully, you would have the new version (5.1.0 in the above example) running with the data
and configuration from the old version that was removed.
Running Artifactory as ROOT
If you have configured Artifactory to run as the ROOT application in Tomcat, you need to follow the steps described in this
Knowledge Base article.

Upgrading to version 5.4.0 and above
From version 5.4.0, Artifactory's management of Access Tokens was moved to a separate service, Access, installed as a
separate web application under the same Tomcat as Artifactory. This requires your Tomcat's server.xml to be configured to
allow running 2 processes. If you are using a server.xml file from a previous installation, when returning it, make sure it is
configured to allow 2 start/stop threads as shown below (see ):

...

1. Download the Artifactory Pro RPM Installer. The latest version can be downloaded from the JFrog Artifactory Pro Download
Page. Previous versions can be downloaded from JFrog Bintray.
2. Log in as root (or use sudo su -).
3. Execute the following command:

rpm -U jfrog-artifactory-pro-5.y.z.rpm

Switching from Artifactory OSS to Pro
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-pro-5.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.

Upgrading Using YUM
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.
Upgrading an Artifactory HA cluster?
If you are upgrading an Artifactory HA cluster, and you are running with a version that is older than version 5.4.6, you should
review the instructions on Upgrading an Enterprise HA Cluster prior to upgrading.
If your current version is 3.6 and above:

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

If your current version is below 3.6:

Running Artifactory as ROOT
If you have configured Artifactory to run as the ROOT application in Tomcat, before you proceed, you need to follow the steps
described in this Knowledge Base article.

Upgrading to version 5.4.0 and above
From version 5.4.0, Artifactory's management of Access Tokens was moved to a separate service, Access, installed as a
separate web application under the same Tomcat as Artifactory. This requires your Tomcat's server.xml to be configured to
allow running 2 processes. If you are using a server.xml file from a previous installation, when returning it, make sure it is
configured to allow 2 start/stop threads as shown below (see ):

...

RPM OSS Installation
Click here to expand...
1. Download the Artifactory OSS RPM Installer. The latest version can be downloaded from the JFrog Open Source page.
Previous versions can be downloaded from JFrog Bintray.
2. Log in as root (or use sudo su -).
3. Execute the following command:

rpm -U jfrog-artifactory-oss-5.y.z.rpm

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:

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 Artifactory as ROOT
If you have configured Artifactory to run as the ROOT application in Tomcat, before you proceed, you need to follow the steps
described in this Knowledge Base article.

Upgrading to version 5.4.0 and above
From version 5.4.0, Artifactory's management of Access Tokens was moved to a separate service, Access, installed as a
separate web application under the same Tomcat as Artifactory. This requires your Tomcat's server.xml to be configured to
allow running 2 processes. If you are using a server.xml file from a previous installation, when returning it, make sure it is
configured to allow 2 start/stop threads as shown below (see ):

...

Using SHA256 Checksums
From version 5.5, Artifactory natively supports SHA-256. New artifacts that are uploaded will automatically have their SHA-256 checksum
calculated, however, artifacts that were already hosted in Artifactory prior to the upgrade will not have their SHA-256 checksum in the
database yet.
To make full use of Artifactory's SHA-256 capabilities after upgrading to version 5.5 and above, you need to run a process that migrates
Artifactory's database making sure that the record for each artifact includes its SHA-256 checksum. For full details on Artifactory's SHA-256
support and instructions on how to migrate your database, please refer to SHA-256 Support.

Upgrading from OSS to Pro
Even if you're just switching your current version of Artifactory OSS to the same version of Artifactory Pro, please follow the instructions under
Upgrading to the Latest Version according to your installation type (ZIP, RPM, Debian or Docker)

Upgrading from Version 3.x
Single Package Type Repositories
Single Package Type
To work with version 4.x or 5.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.
Generic repositories
In version 4.x and 5.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 the single package types 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 $ARTIFACTOR
Y_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.

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.

Downgrading Artifactory
The procedure to downgrade Artifactory may vary depending on the version you are using. For more details, please contact JFrog Support.

Watch the Screencast

Upgrading an Enterprise HA Cluster
Overview
This page describes the process to upgrade your Artifactory Enterprise HA cluster.
No down time
Since your cluster contains more than one node, you may complete the upgrade process
without incurring any down time to the Artifactory service your organization is using.

Upgrading from 5.4.5 and below to 5.5 and above
In version 5.5, Artifactory's database underwent a schema change to accommodate
SHA256 checksums. As a result, when upgrading from version 5.4.5 and below to
version 5.5 and above, you need to follow one of the options described in the detailed
instructions below.

Before You Begin
1. Backup your system: As a precaution, before you begin the upgrade process,
we strongly recommend performing a complete Complete System Backup.
2. Backup your database
3. Read through the process: The backup procedure may vary slightly depending
on your current version and your installation type (ZIP, RPM, Debian or Docker).
To familiarize yourself with the specific backup process that you should use, we
recommend reading through all the steps of the process before you begin.

Page Contents
Overview
The Upgrade
Process
Upgra
ding
From
Versio
n 5.4.5
and
Below
to
Versio
n 5.5
and
Above

Using SHA256 Check
Recov
ering
from
an
Attem
pt to
Upgra
de
Directl
y to
Versio
n 5.5
and
Above

Reinstalling Your Cur
Upgra
ding
from
Versio
n 4.x
or 5.x

Upgrading the Primar
Docke
r
Install
ation

Upgrading the Second
Docke
r
Install
ation

Verify the HA Installat
Troubleshootin
g the Upgrade
Process

The Upgrade Process
Upgrading Artifactory HA depends on which version you are starting from. Read the sections below carefully to make sure you complete the
process correctly.
Upgrading to 5.x for the first time? NFS is no longer required
From version 5.0, Artifactory HA does not require a network file system (NFS) to store data. If you wish to migrate your filestore to
alternative storage locations, please refer to Migrating Data from NFS.

Upgrading From Version 5.4.5 and Below to Version 5.5 and Above
Artifactory 5.5 implements a database schema change to support SHA-256 checksums. If your current version is 5.4.6, you may proceed
with the normal upgrade procedure described in Upgrading from Version 4.x or 5.x below.
If your current version is below 5.4.6, to accommodate this change, you may select one of the following two upgrade options:
1. Two-phase, zero downtime
In this option, you first need to upgrade your HA cluster to version 5.4.6. Once this upgrade is completed, you can then proceed to
upgrade your HA cluster to version 5.5. In both phases, you follow the normal upgrade procedure described in in Upgrading from
Version 4.x or 5.x below.
2. One phase with downtime
This option requires you to execute the following preprocessing
While the primary and all secondary nodes are up and running, add the following flag to artifactory.system.properti
es on the primary node:

artifactory.upgrade.allowAnyUpgrade.forVersion=
For example:
artifactory.upgrade.allowAnyUpgrade.forVersion=5.5.0

Wait until this property is synchronized to the database. You can verify that it has been synchronized by checking the artif
actory.log file in each of the secondary nodes. Your nodes should display a message that looks like this:
[Node ID: some_node_id] detected remote modify for config 'artifactory.system.properties'
Now you can proceed with the normal upgrade procedure described in in Upgrading from Version 4.x or 5.x below.
System will be down during this particular upgrade
Normally, upgrading an enterprise HA cluster does not incur downtime. As you upgrade each node, the other
nodes continue to provide service.
In this particular scenario of upgrading from version 5.4.5 and below to version 5.5 and above in a single phase,
once you upgrade your primary node, your cluster will be in an incoherent state and will not be able to provide
service until all nodes in the cluster have been upgraded. You can expect to see many errors in the log file until
the upgrade is complete.
As a result, we recommend completely taking down the whole cluster (i.e. taking down all cluster nodes), and then
following the upgrade procedure, bringing up each node as it is upgraded.
If you try upgrading directly to version 5.5 without following one of these options, the upgrade will fail and the following message will be
logged in the artifactory.log file:
To upgrade your HA installation to this version, you first need to upgrade to version 5.4.6 which
implements changes required to accommodate a database schema change.

Recovering from an Attempt to Upgrade Directly to Version 5.5 and Above
If you try to upgrade from version 5.4.5 and below to version 5.5 and above without following the procedure in one of the two options above,
the upgrade will fail with the following message:
To upgrade your HA installation to this version, you first need to upgrade to version 5.4.6 which
implements changes required to accommodate a database schema change.
Depending on your installation type, the message may be displayed in the artifactory.log file, the $ARTIFACTORY_HOME/tomcat/log
s/localhost.log file or in the command line output.
To recover from this error and, you first need to replace your current version as described below (according to your installation type).

Then you can proceed with upgrading to version 5.4.6 as required using the normal upgrade procedure, and then on to your final desired
version, also, using the normal upgrade procedure.

Reinstalling Your Current Version
Reinstalling is similar to the process you went through when upgrading to your current version according to your installatian type.
For example, if you tried to upgrade from version 5.2 directly to version 5.5, you now need to reinstall version 5.2 and follow the instructions
below, according to your installation type.
Zip Installation

Follow the upgrade instructions for a Zip installation using your current version.
Debian Installation

Follow the upgrade instructions for a Debian installation using your current version.
If your current version is below 5.4.0, make sure to remove the $ARTIFACTORY_HOME/tomcat/webapps/access folder. This folder is a
remnant of the failed attempt to upgrade to version 5.5 and is not needed in versions previous to 5.4 where the Access Service is bundled
together with the Artifactory WAR.
Docker Installation

Follow the upgrade instructions for a Docker installation using your current version.
RPM Installation

Follow the upgrade instructions for an RPM installation using your current version.
If your current version is below 5.4.0, make sure to remove the $ARTIFACTORY_HOME/tomcat/webapps/access folder. This folder is a
remnant of the failed attempt to upgrade to version 5.5 and is not needed in versions previous to 5.4 where the Access Service is bundled
together with the Artifactory WAR.

Upgrading from Version 4.x or 5.x
Upgrading to the latest version is conducted in three phases:
1. Upgrading the primary node
2. Upgrading the secondary nodes
3. Verifying the HA installation and configuration

Want to stop using NFS?
If you want to stop using a shared NFS once the upgrade procedure is complete (this is optional), please refer to Migrating Data
from NFS to migrate to alternative storage.

Upgrading the Primary Node
1. Remove the primary node from the load balancer, so all requests are directed to the secondary nodes. You may look at $ARTIFACT
ORY_NODE_HOME/logs/request.log and ARTIFACTORY_URL/api/tasks (search for "running") to ensure that Artifactory is
completely inactive.
2. Perform a graceful shutdown of the primary node. While the primary node is down, the load balancer should redirect all queries to the
secondary nodes.
3. Continue with the upgrade according to the instructions for your installation type.
Upgrading from 3.x?
If your current version is 3.5 or higher, you first need to upgrade to the latest version 4.x using the procedure in this link an
d then upgrade to 5.x.
Upgrading Artifactory HA from a version below 3.5 to version 5.x directly is not supported. To upgrade to version 5.x, you
first need to upgrade your system to v3.5+, and then upgrade again to the final version 4.x, and then finally to 5.x.

c. Backup files to a temporary location according to the conditions described below:
i. In all cases, backup $ARTIFACTORY_HOME/bin/artifactory.default
ii. If Artifactory is configured to work with a database that is not Derby, backup the $ARTIFACTORY_HOME/tomcat/l
ib/ driver.
d. Remove the following files and folders from your $ARTIFACTORY_HOME folder:
webapps/artifactory.war
webapps/access.war (this will only be present if your current version is 5.4.0 and
above due to addition of the Access Service)
tomcat
bin
misc
e. Replace the removed files and folders with the corresponding ones from the new unzipped version.
f. Any files that were stored in temporary locations should now be returned to their original location under the new
installation.
Running Artifactory as ROOT
If you have configured Artifactory to run as the ROOT application in Tomcat, before you proceed, you need to
follow the steps described in this Knowledge Base article.

Upgrading to version 5.4.0 and above
From version 5.4.0, Artifactory's management of Access Tokens was moved to a separate service, Access,
installed as a separate web application under the same Tomcat as Artifactory. This requires your Tomcat's
server.xml to be configured to allow running 2 processes. If you are using a server.xml file from a previous
installation, when returning it, make sure it is configured to allow 2 start/stop threads as shown below (see
):

...

g. If you installed Artifactory as a service, you now need to run the service
i. For a Linux service, browse to $ARTIFACTORY_HOME/bin and execute the following command as root: $ART
IFACTORY_HOME/bin/installService.sh [USER [GROUP]]
ii. For Windows service, browse to %ARTIFACTORY_HOME%\bin and run InstallService.bat.

Debian Installation
Upgrading a Debian installation...
a. Log in as root (or use sudo su -).
b. Execute the following command:

dpkg -i $jfrog-artifactory--5.y.z.deb

Managing Configuration Files

If any of these files were modified, 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.
Running Artifactory as ROOT
If you have configured Artifactory to run as the ROOT application in Tomcat, before you proceed, you need to follow
the steps described in this Knowledge Base article.

...

Docker Installation
Upgrading a Docker installation...
In order to keep your data and configuration between versions, when upgrading the Artifactory Docker image, you need to use
an external mounted volume as described under Managing Data Persistence.
To upgrade the Artifactory Docker image, follow these steps:
a. Stop current container
b. Start a container with new version, using same data and configuration
c. Remove old container
The example below shows this process for upgrading Artifactory from v5.0.0 to v5.1.0.

Once these commands have completed successfully, you would have the new version (5.1.0 in the above example) running with
the data and configuration from the old version that was removed.
Running Artifactory as ROOT
If you have configured Artifactory to run as the ROOT application in Tomcat, you need to follow the steps described in
this Knowledge Base article.

Upgrading to version 5.4.0 and above
From version 5.4.0, Artifactory's management of Access Tokens was moved to a separate service, Access, installed

as a separate web application under the same Tomcat as Artifactory. This requires your Tomcat's server.xml to be
configured to allow running 2 processes. If you are using a server.xml file from a previous installation, when returning
it, make sure it is configured to allow 2 start/stop threads as shown below (see ):

...

RPM Installation
Upgrading an RPM installation...
Make sure you are upgrading from v3.6 or above
When running as an RPM installation, you can only upgrade to v5.x if your current version is 3.6 or above. If
necessary, first upgrade your current version to 3.6, and then upgrade to v5.x .
If you try to upgrade a version below 3.6 using rpm --force you may end up deleting all of your data.
a. Download the Artifactory Pro RPM Installer. The latest version can be downloaded from the JFrog Artifactory Pro
Download Page. Previous versions can be downloaded from JFrog Bintray.
b. Log in as root (or use sudo su -).
c. Execute the following command:

rpm -U jfrog-artifactory-pro-5.y.z.rpm

Switching from Artifactory OSS to Pro
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-pro-5.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 .rpm
orig 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.
Upgrading Using YUM

If you are upgrading an Artifactory HA cluster, and you are running with a version that is older than version 5.4.6, you
should review the instructions on Upgrading an Enterprise HA Cluster prior to upgrading.
If your current version is 3.6 and above:

If your current version is below 3.6:

Running Artifactory as ROOT
If you have configured Artifactory to run as the ROOT application in Tomcat, before you proceed, you need to follow
the steps described in this Knowledge Base article.

...

4. Start up the primary node. When the primary node starts up, it will recognize that the HA cluster nodes are not all running the same
version of Artifactory, and consequently, the system will be limited to allowing uploads and downloads.
Any attempt to perform other actions such as changing the DB schema, modifying permissions, changing repository configuration
and more, are strictly blocked. This limitation will continue until all the cluster nodes are once again running the same version.

Version inconsistency generates exceptions
Running the HA cluster nodes with different versions generates exceptions. These can be seen in the log files and reflect
the temporary inconsistent state during the upgrade process. This is normal and should be ignored until all the cluster
nodes are, once again, running the same version.
5. Put the primary node back to the load balancer.

Upgrading the Secondary Node
For each secondary node in your HA cluster, perform the following steps:
1. Remove the node from the load balancer, so all requests are directed to the other nodes. You may look at $ARTIFACTORY_NODE

1.
_HOME/logs/request.log and ARTIFACTORY_URL/api/tasks (search for "running") to ensure that Artifactory is completely inactive.
2. Perform a graceful shutdown of the node. While the node is down, the load balancer should redirect all queries to the other nodes.
3. Continue with the upgrade according to the instructions for your installation type.
If your current version is 3.5 or higher, you first need to upgrade to the latest version 4.x using the following procedure and
then upgrade to 5.x.
Upgrading Artifactory HA from a version below 3.5 to version 5.x directly is not supported. To upgrade to version 5.x, you
first need to upgrade your system to v3.5+, and then upgrade again to the final version 4.x, and then finally to 5.x.

ZIP Installation
Upgrading a ZIP installation...
a. Unzip the Artifactory distribution archive.
b. If the $ARTIFACTORY_HOME/tomcat/conf/server.xml has been modified keep it in a temporary location.
c. Backup files to a temporary location according to the conditions described below:
i. In all cases, backup $ARTIFACTORY_HOME/bin/artifactory.default
ii. If Artifactory is configured to work with a database that is not Derby, backup the $ARTIFACTORY_HOME/tomcat/l
ib/ driver.
d. Remove the following files and folders from your $ARTIFACTORY_HOME folder:
webapps/artifactory.war
webapps/access.war (this will only be present if your current version is 5.4.0 and
above due to addition of the Access Service)
tomcat
bin
misc
e. Replace the removed files and folders with the corresponding ones from the new unzipped version.
f. Any files that were stored in temporary locations should now be returned to their original location under the new
installation.
Running Artifactory as ROOT
If you have configured Artifactory to run as the ROOT application in Tomcat, before you proceed, you need to
follow the steps described in this Knowledge Base article.

Upgrading to version 5.4.0 and above
From version 5.4.0, Artifactory's management of Access Tokens was moved to a separate service, Access,
installed as a separate web application under the same Tomcat as Artifactory. This requires your Tomcat's
server.xml to be configured to allow running 2 processes. If you are using a server.xml file from a previous
installation, when returning it, make sure it is configured to allow 2 start/stop threads as shown below (see
):

...

Debian Installation
Upgrading a Debian installation...
a. Log in as root (or use sudo su -).
b. Execute the following command:

dpkg -i $jfrog-artifactory--5.y.z.deb

Managing Configuration Files

When upgrading a Debian installation the upgrade process overwrites the following set of configuration files:
system.properties
config.xml
default
logback.xml
mimetypes.xml
All files under opt/jfrog/artifactory/misc
All files under opt/jfrog/artifactory/webapps
If any of these files were modified, 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.
Running Artifactory as ROOT
If you have configured Artifactory to run as the ROOT application in Tomcat, before you proceed, you need to follow
the steps described in this Knowledge Base article.

...

Docker Installation
Upgrading a Docker installation...
In order to keep your data and configuration between versions, when upgrading the Artifactory Docker image, you need to use
an external mounted volume as described under Managing Data Persistence.
To upgrade the Artifactory Docker image, follow these steps:
a. Stop current container
b. Start a container with new version, using same data and configuration
c. Remove old container
The example below shows this process for upgrading Artifactory from v5.0.0 to v5.1.0.

Once these commands have completed successfully, you would have the new version (5.1.0 in the above example) running with
the data and configuration from the old version that was removed.
Running Artifactory as ROOT
If you have configured Artifactory to run as the ROOT application in Tomcat, you need to follow the steps described in
this Knowledge Base article.

...

rpm -U jfrog-artifactory-pro-5.y.z.rpm

Switching from Artifactory OSS to Pro
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-pro-5.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 .rpm
orig 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.
Upgrading Using YUM

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.
Upgrading an Artifactory HA cluster?
If you are upgrading an Artifactory HA cluster, and you are running with a version that is older than version 5.4.6, you
should review the instructions on Upgrading an Enterprise HA Cluster prior to upgrading.
If your current version is 3.6 and above:

If your current version is below 3.6:

Running Artifactory as ROOT
If you have configured Artifactory to run as the ROOT application in Tomcat, before you proceed, you need to follow
the steps described in this Knowledge Base article.

...

4. Start up the secondary node.
5. Add the secondary node back to the load balancer.
6. Repeat this process for each secondary node.
Upgrading to version 5.2.1 and above and using an NFS mount?
Once you have completed an upgrade, if your new version is 5.2.1 and above, and you are using a shared NFS mount,
make sure to remove the Bootstrap bundle archive from the $NFS_MOUNT/ha-etc folder.

Check your installation
After starting up each secondary node, we recommend inspecting the ha-node.properties, db.properties and binary
store.xml files (under $ARTIFACTORY_NODE_HOME/etc) to ensure they are correctly configured

Verify the HA Installation and Configuration
Once you have completed upgrading your HA cluster, you can verify that your cluster has been installed and configured correctly use the
following series of tests:
1. Directly Access the Artifactory UI for the server you have just configured
2. In the Admin module go to Advanced | System Logs to view the log and verify that you see an entry for HA Node ID.

3. The bottom of the module navigation bar should also indicate that you are running with an Enterprise licens. In case of an error you
will see an error message in the page header.

4. Access Artifactory through your load balancer and log in as Admin.
5. In the Admin module go to Configuration. There should be a section called High Availability. When selected you should see a
table with details on all the Artifactory nodes in your cluster as displayed below.

6. In the Admin module under Configuration | General, verify that the Custom URL Base field is correctly configured to the URL of
the Load Balancer.

Want to stop using NFS?
If you want to stop using a shared NFS once the upgrade procedure is complete (this is optional), please refer to Migrating Data
from NFS to migrate to alternative storage.

Troubleshooting the Upgrade Process
If you run into any problems during the upgrade process, please refer to Troubleshooting HA for a possible resolution.

Using Artifactory
Overview
Artifactory provides you with the features you need to manage your binary repositories, both through an
intuitive UI and with an extensive set of APIs.
The Artifactory UI is divided into four main modules:

Home
The Home module serves as a dashboard where you can easily access general information and commonly
used features. For more details, please refer to General Information.

Artifacts
The Artifacts module is used to browse the repositories in your system and search for artifacts using a
number of different methods. While browsing through repositories, Artifactory displays useful information and
provides you with tools to perform essential actions to manage your repositories.

Search
The Search module is where you can search for Artifacts by name, package type, properties and a variety of
additional methods offered by Artifactory. For more details, please refer to Searching for Artifacts.

Build
The Build module displays the Build Browser where you can view all the CI server projects that output their
builds to Artifactory. Here you can drill down to view detailed build information and compare one build to
another.

Admin
The Admin tab is only available to users who are defined as administrators in the system, and is used to

perform a variety of administration and maintenance activities such as:
Configuring different entities such as repositories, software licenses, proxies, mail servers and more
Managing different aspects of system security such as user definitions, groups, permissions, LDAP
integration and more
Managing backup and indexing of repositories
Managing import and export of repositories or of the entire system
Accessing system information and scheduling different cleanup operations
This functionality is available through the Admin menu which is displayed when a logged-in administrator
hovers the mouse over Admin in the navigation bar.
To help locate a specific action, you can enter a search term in the Filter field and have Artifactory
emphasize matching menu items.

In addition to the feature set offered by the UI, Artifactory provides an extensive REST API to facilitate
integration with build automation and continuous integration systems.
Page Contents
Overview
Help Menu
Set Me Up
Inserting User Credentials
Keyboard Shortcuts

Read more
Getting Started
General Information
Browsing Artifactory
Using WebDAV
Searching for Artifacts
Deploying Artifacts
Manipulating Artifacts
Updating Your Profile
Authentication
Artifactory REST API

Help Menu
On every screen of Artifactory, you can click the Help menu to display a list of help topics relevant for the current screen. Selecting any of the help
topics opens a new browser tab displaying the corresponding Artifactory documentation.

Set Me Up
Artifactory's Set Me Up feature provides you with the commands you can use to deploy and resolve artifacts to and from specific repositories.
Simply select any item in the Tree Browser or Simple Browser and click Set Me Up.

Regardless of what was selected when you pop up this dialog, you can select a Tool and a specific Repository (the list of repositories displayed
corresponds to the tool you selected), and Artifactory will provide the relevant commands according to your selection.

Inserting User Credentials
Every Set Me Up dialog includes an "Insert Credentials" button. When pressed, Artifactory will prompt you for your password and will then replace
generic credential placeholders used in code snippets with your own corresponding credentials.

This means that you may now copy the code snippets and use them "as is". For example, for the Set Me Up screen displayed above, clicking
"Insert Credentials" will replace the placeholder with your API Key as displayed below.

To undo the change, click "Remove Credentials".
Inserted user data is not persistent
Once you close the Set Me Up dialog, any user data that was inserted is removed. To insert user data into code snippets, you need to
invoke it each time you display a Set Me Up dialog.

Keyboard Shortcuts
To facilitate easy navigation through its UI, Artifactory offers the following set of keyboard shortcuts:
Ctrl/Cmd + Alt
+B

Display the Build Browser in the Build module

Ctrl/Cmd + Alt
+R

Display the Artifact Repository Browser in the Artifacts module

Ctrl/Cmd + Alt
+N

Create a new item (where relevant). For example, when viewing the list of local repositories, Ctrl/Cmd + Alt + N will pop up a
dialog to create a new one.

Ctrl/Cmd + Alt
+>

Open the Admin module menu. Once in the menu, you can browse through items using the up/down arrow keys or the tab
key.

Ctrl/Cmd + Alt
+<

Close the Admin module menu.

Getting Started
Overview

Page contents

To get you up and running as quickly and easily as possible for a new installation, Artifactory offers
two ways to configure your basic initial setup:
Onboarding Wizard: The onboarding wizard is invoked first time you start up Artifactory. It
will take you through the steps of initial configuration using a convenient and intuitive UI.
YAML Configuration File: The YAML configuration file offers an alternative way to specify
your initial settings allowing you to skip the onboarding wizard.
In addition, you may use a combination of these two methods, specifying some of your initial setup
in the YAML file, and then skipping the corresponding sections in the onboarding wizard.
The initial setup lets you configure the following basic settings:
License
Base URL (through the YAML configuration file only)
Admin password (through the onboarding wizard only)
Proxy server
Initial default repositories

Overview
Onboarding
Wizard
YAML
Configuration
File
Limitat
ions
Locati
on and
Usage
Exporti
ng a
Config
uration

Bootstrapping only
Remember that both the onboarding wizard and the YAML configuration file can only be
used to configure Artifactory upon bootstrapping it for the first time. Once Artifactory has
been started up or a repository has been set up or used, the onboarding wizard is no
longer accessible, and the YAML configuration file is not read.

Onboarding Wizard
The onboarding wizard makes sure you get Artifactory set up with the minimal information needed to get started.

Welcome: The beginning of the onboarding wizard.
Click Next to get started.

License: Enter your license key and click Next to
continue.

Admin password: Set the admin passwor
(recommended) and click Next to continue
kip to stay with the default admin password

Proxy: Configure a proxy server and click Next to
continue, or click Skip to configure one later.

Create Repositories: Select the package formats for
which Artifactory should create default repositories
and click Create to continue.

Summary: Displays the default repositories
according to your selection. Click Finish to
the wizard and get started with Artifactory.

YAML Configuration File
Setting up Artifactory using the YAML configuration file is a convenient alternative to going through the startup wizard. In addition, it gives you
an easy way to save the basic configuration of one instance and then quickly and easily reproduce that configuration in other instances you
set up.
When using the YAML configuration file, you don't have to configure all the parameters described in the Overview above. You may
configure only some of the parameters using the YAML file, and then configure the others through the start up wizard, or manually
later on after Artifactory has started up.

Limitations
These limitations stem from the principle that the YAML configuration file is designated for configuration of new Artifactory instances that
essentially, have not been used before. When bootstrapping a new instance of Artifactory, it will load the configuration specified in this file if
all of the following conditions are met:
No repositories have been created
A proxy has not been set up, or a proxy has been set up and you did not configure proxy setup through the YAML configuration file
The base URL has not been set up, or the base URL has been set up and you did not configure the base URL through the YAML
configuration file
Artifactory has not been activated with a license, or it has been activated with a license and you did not configure the license through
the YAML configuration file

Location and Usage
The YAML configuration file template can be found under $ARTIFACTORY_HOME/misc/artifactory.config.template.yml. To
specify your initial bootstrap configuration, uncomment the relevant sections in the file and provide the configuration details. Rename the file,
save it as artifactory.config.import.yml and place it under Artifactory's etc folder. When done you should have the following
configuration file: $ARTIFACTORY_HOME/etc/artifactory.config.import.yml
An example of the YAML configuration file template used for Artifactory 5.0 can be found below:
YAML configuration file template...

--version: 1
## This file is complementary to the JFrog Artifactory startup wizard,
and may be used to specify the initial basic
## settings for a new Artifactory installation, namely:
## * License Key(s)
## * Base URL
## * Proxy
## * Default repositories
##
##
## HOW TO USE THIS FILE:
##
## To import these settings when bootstrapping Artifactory, save this
file as artifactory.config.import.yml under Artifactory’s /etc folder
## Artifactory will load this file if all of the following conditions
are met:
## - no repositories have been created
## - a proxy has not been set up, or you did set up a proxy

externally, but did not configure proxy setup through this file
## - the base URL has not been set up, or you did set up the base URL
externally, but did not configure the base URL setup through this file
## - Artifactory has not been activated with a license, or Artifactory
has been activated with a license, and you did not specify a license
in this file
##
## To have any of these parameters automatically configured when you
bootstrap an Artifactory instance using this file,
## simply uncomment the relevant sections below, and where required,
provide values.
#####################################################################
#############
# General Configurations #
#####################################################################
#############
GeneralConfiguration:
## License key to import in onboarding
licenseKey : "Enter your license key"
## Setup the Artifactory base URL
## For more information about the Artifactory base URL, please refer
to
##
https://www.jfrog.com/confluence/display/RTF/Configuring+Artifactory#
ConfiguringArtifactory-GeneralSettings
## Uncomment the line below to set the Artifactory base URL
# baseUrl : "https://mycomp.arti.co"
## Configure proxies for artifactory
## For more information on configuring a proxy in Artifactory, please
refer to
## https://www.jfrog.com/confluence/display/RTF/Managing+Proxies
## Uncomment the lines below to setup a proxy
# proxies :
# - key : "proxy1"
# host : "https://proxy.mycomp.io"
# port : 443
#
userName : "admin"
#
password : "password"
#
defaultProxy : true
#
- key : "proxy2"
#
...
#####################################################################
#############
# Onboarding Configurations #
#####################################################################
#############
OnboardingConfiguration:
## Uncomment the package types for which you want to create default
repositories
repoTypes :

#
#
#
#
#
#
#
#
#
#
#
#
#
#
#

- bower
- cocoapods
- conan
- debian
- docker
- gems
- gradle
- ivy
- maven
- npm
- nuget
- opkg
- composer
- pypi
- sbt

#
#
#

- vagrant
- rpm
- gitlfs

For example, to set your base URL to be "https://acme.artifactory.com", you should uncomment the baseUrl section and, while keeping the
same indentation, set:

baseUrl : "https://acme.artifactory.com"

Indentation
Indentation is significant in YAML. Make sure to maintain the same indentation levels when editing the YAML configuration file.

Exporting a Configuration
When Artifactory is bootstrapped for the first time, it stores a copy of its initial configuration under $ARTIFACTORY_HOME/etc/artifactor
y.config..yml regardless of whether it was bootstrapped using the Onboarding Wizard, or using a YAML configuration file.
To use this configuration to bootstrap additional Artifactory instances, copy the file into the new instance's $ARTIFACTORY_HOME/etc folder
and rename it to artifactory.config.import.yml.

General Information
Overview
The Home screen is divided into convenient sections and panels that provide useful information or
quick links to commonly used features.

Page contents
Overview
Top
Ribbo
n
Basic
Inform
ation
Searc
h
Panel
Set
Me
Up
Downl
oad
and
Deploy
Statisti
cs
Quick
Reposi
tory
Setup
Refere
nce
Panel
Featur
es
Panel

Top Ribbon
The top ribbon in Artifactory displays the logged-in user, and provides access to Quick Search and Help. Admin users may click the user
name to display a menu of common actions for easy access.

Basic Information
At the top of the Home Screen, Artifactory displays basic information such as total number of artifacts, version information and uptime.

Search Panel
The Search Panel provides quick links to the different searches you can perform in Artifactory. For more details, please refer to Searching for
Artifacts.

Set Me Up
The Set Me Up panel provides quick access to details on how to configure your different clients to work with the corresponding repositories
you have created. Just click one of the repositories to view its "Set Me Up" screen.

For more details, please refer to Set Me Up.

Download and Deploy Statistics
These panels provide information on your last deployed builds and most downloaded artifacts.

Quick Repository Setup
The "Quick Repository Setup" button offers a quick and easy way to set up default repositories for any of the supported package formats for
which you have not yet set up repositories.

Reference Panel
The Reference Panel provides links to useful references such as the JFrog Artifactory User Guide (this guide) and Artifactory's REST API doc
umentation, as well as additional useful links such as the Support Portal, blog, webinar signup page and questions tagged with "Artifactory"
on Stack Overflow.

Features Panel
The Features Panel at the bottom of the screen displays all the features available to you according to the license you have used to activate
Artifactory. Hover over any feature to get quick links to more information and a link to the relevant section in this user guide

Browsing Artifactory
Overview
The Artifacts module in Artifactory displays the Artifact Repository Browser that provides two ways to
browse through repositories:
Tree Browser: Displays the repository as a tree
Simple Browser: Focuses on the currently selected item and displays the level below it in the
repository hierarchy as a flat list
Both browsers adhere to the security rules defined in the system, and only allow you to perform actions
authorized by the system security policies.
To switch between browsing modes, simply select the corresponding link at the top of the Artifact
Repository Browser.

Both the Tree Browser and Simple Browser have features to help you navigate them and search for
repositories:
Repository type icon: Each repository is displayed with a distinct icon that represents its type
(local, cache, remote and virtual).
Search in the browser: You can search for a specific repository in both browsers by clicking on the
filter icon.
Keyboard navigation: While in the browser, type the name of the repository you are searching for
and Artifactory will navigate you to that repository.
Filters: Click the filter icon to filter the repositories displayed in the browser to only display the types
that interest you. You can also simply type the filter expression while on the browser.
Page Contents
Overview
Tree Browsing
Sorting the Tree Browser
Simple Browsing
Filters
Information Tabs
List Browsing
Remote Browsing
Trash Can
WebDAV Browsing

Tree Browsing
The Tree Browser lets you drill down through the repository hierarchy
and displays full information for each level within it. For any repository,
folder or artifact selected in the tree, a tabbed panel displays detailed
data views and a variety of actions that can be performed on the
selected item. The information tabs available are context sensitive and
depend on the item selected. For example, if you select an npm
package, an Npm Info tab displays information specific to Npm
packages. Similarly for NuGet, RubyGems and any other supported
package formats.
Collapse All
Click on the "Tree" link at the top of the tree browser to
collapse all open nodes in the tree.

Sorting the Tree Browser
The default order in which repositories appear in the Tree Browser is:
Distribution, Local, Remote, Virtual.
You can modify this order through the artifactory.treebrowser.s
ortRepositories.sortByType system property.
For example, to reverse the order, you would set:

artifactory.treebrowser.sortRepo
sitories.sortByType=virtual,remo
te,local,distribution

If you omit any repository type in the specified sort order, it will be
ordered according to the default setting.

Simple Browsing
The simple browser lets you browse repositories using simple
path-driven URLs, which are the same URLs used by build tools such as
Maven. It provides lightweight, view-only browsing.
A unique feature of this browsing mode is that you can also view remote
repositories (when enabled for the repository), and virtual repositories to
see the true location of each folder and artifact

Filters
You can apply a filter to both the Tree Browser and the Simple Browser, either by clicking the search icon, or just typing out the filter expression
while on the browser.
By repository name: To filter by repository name, just type the name you want to filter by
By package type: To only display repositories for a particular package type, type pkg:. For example, typing pkg:docker will
filter out any repositories that are not Docker repositories

By repository type: To only display particular repository types, type repo:. For example, typing repo:local will filter out
any repositories that are not local repositories. The options are local, cached, remote and virtual.

Information Tabs
Selecting any item in the Tree or Simple browser displays tabs which provide information regarding the metadata associated with the selected
item:

General

Info: General Information including download statistics such as the total number of downloads, time stamp of last download
and the last user who downloaded.
Xray: Indicates if, and when the last time the selected artifact was indexed by JFrog Xray, as well as the Top Severity reported
for the selected item and when the reporting alert was last updated.
Dependency Declaration: For Maven artifacts, this section provides code snippets for common build tools' dependency
declaration
Virtual Repository Associations: Indicates which virtual repositories "contain" the selected artifact.
Checksums displays SHA1, SHA-256 and MD5 checksums automatically.

Effective
Permissions

The permissions (Delete/Overwrite, Deploy/Cache, Annotate, Read) that each user or group regarding the selected item.
Permissions for groups are as specifically assigned to them. Permissions for individual users are the union of permissions
specifically assigned as well as those inherited by virtue of the user being included in groups.
The list of properties annotating the selected item.

Properties

The list of users watching this item.
Watchers

The list of builds that either produce or use the selected item.
Builds

Information on the selected item retrieved from Black Duck Code Center.
Governance

XML and POM files also display a tab through which you can view the file contents.
Xml/Pom
View

List Browsing
List Browsing lets you browse the contents of a repository outside of the
Artifactory UI. It provides a highly responsive, read-only view and is
similar to a directory listing provided by HTTP servers.
To use List Browsing, click the icon to the right of a repository name in
the Simple Browser (indicated in red in the screenshot above).
Creating public views with List Browsing
List browsing can be used to provide public views of a
repository by mounting it on a well-known path prefix such as
list (see example below).
This allows the system administrator to create a virtual host
that only exposes Artifactory's List Browsing feature to public
users (while maintaining write and other advanced privileges),
but limiting access to the intensive UI and REST API features
for internal use only.

http://host:port/artifacto
ry/list/repo-path

Remote Browsing
Artifactory remote browsing capabilities let you navigate the contents of the remote repository even if the artifacts have not been cached locally.
To enable remote browsing, you need to set the List Remote Folder Items checkbox in the remote repository configuration. Once this is set you
can navigate that repository using the Simple or List Browser.
In the Simple Browser, an item that is not cached is indicated by an icon on its right when you hover over the item. In the List Browser, an item
that is not cached is indicated by an arrow.
Simple Browser

List Browser

Initial responsiveness of remote repositories
Initial remote browsing may be slow, especially when browsing a virtual repository containing multiple remote repositories. However,
browsing speeds up since remote content is cached for browsing according to the Retrieval Cache Period defined in the remote
repository configuration panel.

Trash Can
Artifactory provides a trash can as an easy way to recover items that have been inadvertently deleted from local repositories.
The trash can can be enabled or disabled in the Trash Can Settings by an Artifactory administrator.
When enabled, the trash can is displayed at the bottom of the Artifact Repository Browser and it holds all artifacts or repository paths that have
been deleted from local repositories for the period of time specified in the Retention Period field.

Right-click on an item in the trash can gives you the option to Refresh, Restore it to its original location, or Delete permanently.
Right-click on the trash can icon gives you the option to Refresh the whole trash can, Search Trash for specific items, or Empty Trash which
means that all items in the trash can will be permanently deleted.
Click the pin icon to pin the trash can so it remains visible even if you scroll the tree.

WebDAV Browsing
Artifactory fully supports browsing with WebDAV. For full details please refer to Using WebDAV.

Using WebDAV
Overview
Artifactory supports WebDAV shares. A

local or cached repository may be mounted as a
secure WebDAV share, and made accessible from any WebDAV-supporting file
manager, by referencing the URL of the target repository as follows:
http://host:port/artifactory/repo-path
When trying to deploy a file through WebDAV where file locking is enabled, the Artifactory log may display
the following message:
"Received unsupported request method: lock".
In some cases this can be solved by disabling file locking before mounting the repository and is done
differently for each WebDAV client. For example, for davfs2 file locking is disabled as follows:

echo "use_locks 0" >> /etc/davfs2/davfs2.conf
Note that while for some clients file locking is disabled by default, it is not necessarily possible to disable file
locking in all clients.
Page Contents
Overview
Authentication for davfs2 Clients

Authentication for Windows and other WebDAV clients

Authentication for davfs2 Clients
Davfs2 does not use preemptive authentication. Therefore, in order to authenticate using the user credentials, the client must be authenticated
using two requests. The first request is sent without credentials, and receives a 401 challenge in response. Then, a second request is sent, this
time with the credentials.

Anonymous access with Artifactory
Artifactory may be configured to allow anonymous access and it will therefore accept requests without authentication.
In this case, Artifactory will not respond with a 401 challenge and you will get file access with anonymous user permissions which may
be less than your own user permissions.

To access your repository through Artifactory with your full user permissions you need add an authorization header to the client configuration.
This way, the requests sent to Artifactory will be authenticated and there is no need to receive a 401 challenge and respond with a second
request.
Thus you are given anonymous access to Artifactory, and yet can still authenticate with your own credentials.
This can be done as follows:
1. Encode your username and password credentials in base64 using the following Groovy script:

Groovy script
Basic ${”username:password".bytes.encodeBase64()}

2. Edit the file /etc/davfs2/davfs2.conf or ~/.davfs2/davfs2.conf and add the encoded credentials to the authorization header
as follows:

Adding authorization header
add_header Authorization “Basic c2hheTpwYXNzd29yZA==”

Authentication for Windows and other WebDAV clients
We suggest utilizing a tool such as Cyberduck (Open Source) when using Windows (see the note below) with WebDAV shared Artifactory
repositories.

Limitation
Although the use of Windows WebDAV/WebClient components to map/mount a Windows Drive for a WebDAV shared Artifactory does
provide a listing of the files - other operations such as copy/move operations are utilizing WebDAV commands which are not supported
by Artifactory.

Searching for Artifacts
Overview
Artifactory provides several Search Types you can use to search for artifacts in the Search module:
Quick: Search by artifact file name.
Package: Search for artifacts according to the criteria specific to the package format.
Archive Entries: Search for files that reside within archives (e.g. within a jar file).
Property: Search for artifacts based on names and values of properties assigned to them.
Checksum: Search for artifacts based on their checksum value.

JCenter: Search for artifacts in Bintray's JCenter repository.
Trash Can: Search for artifacts in Artifactory's trash can
Additional advanced search features are available through the REST API.
Search in Artifactory provides true real-time results that always reflect the current state of the repository with
no need to periodically rebuild indexes. Therefore, search results will immediately show any artifacts
deployed, and will not show any artifacts removed. The * and ? wildcards are supported in your search term
to help you narrow down your search. After conducting a search, you can hover over any result item for
available actions such as:
Download the artifact
Download

Displays the artifact within the Tree Browser where you can view its full details
Show in Tree

Delete the artifact
Delete

Using wildcards
When searching with the Artifactory UI, Artifactory performs prefix matching for search terms in all
the different search modes. For example, searching for jfrog is equivalent to searching for jfrog
*. You can still use the * and ? wildcards by placing in your search term in double-quotes to help
you narrow down your search (for example, "a*.jar").

Page Contents
Overview
General
Quick Search
Archive Search
Package Search
Property Search
Checksum Search
JCenter
Trash Can
Search Results Stash

General
The different search features are available in the Search module. To start a search, simply select the search method you want to use.

Each search method offers a set of input fields corresponding to the type of search you have selected to help narrow down your search. For
example, you can always narrow down your search by Selecting Limit toSpecific Repositories as one of your search criteria.

Case Sensitive
For all searches, the search term is case-sensitive.

Quick Search
Using Quick Search you can search for artifacts by name. Select Quick, enter your search term and then click the "Search" button.

For readability, you can limit the number of results displayed by setting the following two parameters in the $ARTIFACTORY_HOME/etc/artifa
ctory.system.properties file:

Configuring the number of search results
## Maximum number of results to return when searching through the UI
#artifactory.search.maxResults=500
## The backend limit of maximum results to return from sql queries issued
by users. Should be higher than maxResults.
#artifactory.search.userQueryLimit=1000

You can run a Quick Search from any screen
You can also run a Quick Search from any screen using the search field in the top-right corner of the screen.

Archive Search
Archive search performs a search for all files that match your search parameters in an archive. Typical examples are a zip or jar file, however, all
file types defined in the MIME types configuration are supported. You can specify the following parameters for your search:
The term to search for within the file name.
Name

Allows you to specify a path filter for the search.
Path

When checked, only class resources are searched. Any other file type is filtered out of the search.
Search class resources only

When checked, inner classes are excluded from the search.
Exclude Inner Classes

Limits search to the specified repositories.
Limit to Specific Repositories

View the source file
You can hover over a class file and select View to view the corresponding source file if it's available.

Package Search
Package search enables you to run a search based on a specific packaging type. For each type, you can specify search parameters based on the
relevant metadata for the selected package type. For example, Docker search is suitable for searching through Docker repositories.

The following table displays the parameters you may use for each package type:
Search type

Search parameters
Package name, Version

Bower

Package name, Version
CocoaPods

Package name, Version
Composer

Package name, Version, User , Channel, OS, Architecture, Build Type, Compiler
Conan

File name (without the .deb extension), Distribution, Component, Architecture
Debian

Full Image Namespace, Image Tag, Image Digest
Docker

Package name, Version
Gems

Group ID, Artifact ID, Version, Classifier
Maven GAVC

Package name, Version, Scope
Npm

Package ID, Version
NuGet

Package name, Version, Architecture, Priority, Maintainer
Opkg

Package name, Version
PyPI

Package name, Version, Architecture, Release
RPM

Box Name, Version, Provider
Vagrant

All these search fields support the "?" and "*" wildcard characters.
Package search as an AQL query
For most package formats, package search is implemented as an AQL query. Click the "AQL" button to view the AQL query used in the
search. You may also click the "Copy" icon in the AQL code snippet to copy the query to your clipboard.

Limit search to specific repositories
When limiting search to specific repositories, Artifactory will only let you select repositories with the corresponding package type.
Package search depends on those repositories having the correct layout. Searching through repositories with the wrong layout will have
unpredictable and unreliable results.
The example below shows the results of searching for any Docker image with "mysql" in its name:

Under the hood
Package search is based on standard properties that Artifactory attaches to packages according to their type. For example, when
searching for NuGet packages, Artifactory is actually matching the search terms to the values for the nuget.id and nuget.version
properties that should be attached to every NuGet package.

Limitation
Package search does not currently work on remote repository caches for RubyGems and Debian repositories.

Property Search
Artifactory Pro allows you to search for artifacts or folders based on Properties assigned to them, whether they are standard properties assigned
by Artifactory, or custom properties which you can freely assign yourself.
To define your search parameters, in the Key field, enter the name of the property to search for, or select one from the list provided.
Then, in the Value field, set the value you are searching for in the specified property. To add more properties to the search use the Add search
criteria drop list.
You can repeat this process to specify any number of properties and values for your search.
Wildcards can be used in the Property Value field
You can use the "?" or "*" wildcards in the Value field.

Combining properties and values
Properties are combined using the AND operator.
Different values assigned to a specific property are also combined using the AND operator.
This means that only artifacts that meet all the search criteria specified will be found.
The example below shows a search for artifacts that have a build.number property with a value of 2

Checksum Search
Artifactory allows you to search for artifacts based on MD5, SHA1 or SHA2 checksum value.
This can be especially useful if you want to identify an artifact whose name has been changed.
Wildcard characters are not supported in Checksum Search, so the term entered in the search field must be valid MD5 or SHA1 value.
The example below shows a search for an artifact using its SHA1 checksum.

JCenter
Bintray is JFrog's software distribution platform. Using this free cloud-based service, you can publish, download and share your binaries with the
developer community.
For more details, please refer to the JFrog website Bintray page.
Artifactory provides a direct connection to Bintray's JCenter repository which contains a comprehensive collection of popular Apache Maven
packages.
To search for packages on Bintray, select JCenter as the Search Type and enter the name of the package you are looking for.

You can hover over any search result and click Show in Bintray to display the selected artifact in Bintray.

Trash Can
Artifactory lets you search for artifacts you have "removed" to the trash can by selecting Trash Can as the Search Type.
Enter the artifact's name in the Query field, or use Add search criteria... and enter the artifact's checksum.

Search Results Stash
Requires Artifactory Pro
This feature is available with an Artifactory Pro license
Artifactory maintains a stash where you can save search results. This provides easy access to artifacts found without having to run the search
again and also provides a convenient way to perform bulk operations on the result set.
For details, please refer to Saving Search Results in the Stash.

Deploying Artifacts
Overview
You can deploy artifacts into a local repository of Artifactory from the Artifacts module by clicking Deploy to
display the Deploy dialog. Artifacts can be deployed individually or in multiples.

Using Import to "deploy" a whole repository
If you want to "deploy" a whole repository, you should actually import it using the Import Repository
feature in the Admin tab under Import & Export | Repositories.

You can also deploy artifacts to any repository using Artifactory's REST API, see this example for a quick
start.
Page Contents
Overview
Deploying a Single Artifact
Deploying According to Layout
Deploying Maven Artifacts
Deploying with Properties
Deploying with Multiple Properties
Deploying an Artifact Bundle
Deploying to a Virtual Repository
Failed Uploads

Deploying a Single Artifact
To deploy a single artifact, simply fill in the fields in the Deploy dialog and click "Deploy".

Deploying According to Layout
The Deploy dialog displays the repository package type and layout configured. To deploy your package according to the configured layout, check
Deploy According to Layout.
Artifactory displays entry fields corresponding to the layout tokens for you to fill in.

If you are deploying a Maven artifact, you may need to configure additional attributes as described in the next section.
Suggested Target Path
Artifactory will suggest a Target Path based on the details of your artifact (this works for both Maven and Ivy). For example, if a JAR
artifact has an embedded POM under its internal META-INF directory, this information is used.

Deploying Maven Artifacts
If you are deploying an artifact that conforms to the Maven repository layout, you should set Deploy as Maven Artifact to expose fields that
specify the corresponding Maven attributes - GroupID, ArtifactID, Version, Classifier and Type.
The fields are automatically filled in according to the artifact name, however you can edit them and your changes will also be reflected in the Targ
et Path.
If your target repository does not include a POM, set Generate Default POM/Deploy Jar's Internal POM, to use the POM within the artifact you
are deploying, or generate a default POM respectively.
Take care when editing the POM manually
If you are editing the POM manually, be very careful to keep it in a valid state.

Deploying with Properties
Properties can be attached to the uploaded file by specifying them on the Target Path.
First, unset the Deploy as Maven Artifact check box, if necessary.
Then, in the TargetPath field, add the properties delimited from the path and from each other by semicolons.
For example, to upload an artifact with the property qa set to "passed", and build.number set to "102", use the following Target Path:

dir1/file.zip;qa=passed;build.number=102

Deploying with Multiple Properties
To deploy multiple values to the same key add the same key again with the new value, e.g. key1=value1;key1=value2 will deploy the file with
property key1 with value of value1,value2.
For example, to upload a file with property passed and values qa, stress use the following Target Path:

dir1/file.zip;passed=qa;passed=stress

Deploying Multiple Files
To deploy multiple files together, simple set the deploy Type to Multi, fill in the rest of the fields in the dialog and click "Deploy".

Deploying an Artifact Bundle
An artifact bundle is deployed as a set of artifacts packaged in an archive with one of the following supported extensions: zip, tar, tar.gz, tgz.
When you specify that an artifact should be deployed as a bundle, Artifactory will extract the archive contents when you deploy it.
File structure within the archive
Artifacts should be packaged within the archive in the same file structure with which they should be deployed to the target repository.
To deploy an artifact bundle, in the Deploy dialog, first upload the archive file you want to deploy.
Check the Deploy as Bundle Artifact checkbox and click Deploy.

Deploying to a Virtual Repository
From version 4.2, Artifactory supports deploying artifacts to a virtual repository.
To enable this, you first need to designate one of the local repositories that is aggregated by the virtual repository as a deployment target. This
can be done through the UI by setting the Default Deployment Repository in the Basic Settings of the Edit Repository screen.

You can also set the Default Deployment Repository using the defaultDeploymentRepo parameter of the Virtual Repository Configuration
JSON used in the Create or Replace Repository Configuration and Update Repository Configuration REST API endpoints. Once the deployment
target is configured, you may deploy artifacts to it using any packaging format client configured to work with Artifactory. For example, docker
push, npm publish, NuGet push, gem push etc.

You can also use Artifactory's REST API to deploy an artifact and use the virtual repository key in the path to deploy.
From version 4.4, if you do specify a Default Deployment Repository for a virtual repository, the corresponding Set Me Up dialog for the
repository will also include instructions and code snippets for deploying to that repository.

Failed Uploads
The most common reasons for a rejected deployment are:
Lack of permissions
A conflict with the target repository's includes/excludes patterns
A conflict with the target repository's snapshots/releases handling policy.

Manipulating Artifacts
Overview
Artifactory supports move, copy and deletion of artifacts to keep your repositories consistent and coherent.
When an artifact is moved, copied or deleted, Artifactory immediately and automatically updates the
corresponding metadata descriptors (such as maven-metadata.xml, RubyGems, Npm and more) to reflect
the change and keep your repositories consistent with the package clients.
In addition, as a convenience feature, Artifactory provides a simple way to do a complete version cleanup.
Page Contents
Overview
Deleting a Single Item
Deleting a Version
Moving and Copying Artifacts
Simulating a Move or Copy
Downloading a Folder
Configuring Folder Download

Deleting a Single Item
To delete a single artifact or directory, select the item in the Tree Browser, and click Delete from the Actions menu or the right-click menu.
Once the item is deleted, the corresponding metadata file is updated to reflect the change so the item will not be found in a search.

Deleting a Version
It is common for a repository to accumulate many different artifacts deployed under the same group (or path prefix) and the same version. This is

especially true for snapshot deployments of multi-module projects, where all deployed artifacts use the same version. To delete a version by
individually deleting its constituent artifacts can be tedious, and would normally be managed by writing a dedicated script. Artifactory lets you
select one of the artifacts in a version and then delete all artifacts with the same version tag in a single click while keeping the corresponding meta
data descriptors up to date.
To delete a version, right-click a folder in the Tree Browser and select Delete Versions...
Artifactory drills down into the selected folder and returns with a list of all the groups and versions that can be deleted.

Select the versions you want to clean up and click Delete Selected
Limit to number of versions displayed
To avoid an excessively long search, Artifactory only displays the different version numbers assigned to the first 1000 artifacts found in
the selected level of the repository hierarchy. If you do not see the version number you wish to delete, filter the artifacts displayed in the
Delete Versions dialog by Group ID or Version number.

Moving and Copying Artifacts
To move or copy an artifact or folder, select it in the Tree Browser and then click Move... or Copy... from the Actions menu or from the right-click
menu.

Artifactory will display a list of repositories from which you need to select your Target Repository for the operation.
The list of target repositories will contain all the local repositories, or virtual repositories with a "Default Deployment Repository" configured that
are configured with the same package type as the source repository, or configured as generic repositories. This mean, for example, you can only
move an artifact from a debian repository to a generic repository or to a local debian repository.

After selecting your Target Repository, you can specify a custom Target Path if you want your source artifacts moved to a different location the
Target Repository.
Copy operations are executed using Unix conventions
Copy operations are executed using Unix conventions. For example, copying org/jfrog/1 from a source repository to org/jfrog/1 in a
target repository will result in the contents of the source being copied to org/jfrog/1/1.
To achieve the same path in the target repository, copy the source into one folder up in the hierarchy. In the above example, that would
mean copying source org/jfrog/1 into target org/jfrog.
If you leave the Target Path empty, the source will be copied into the target repository's root folder.

Custom target path supresses cross-layout translation
If you are copying or moving your source artifacts to a repository with a different layout, specifying a Custom Target Path suppresses
cross-layout translation. This means that your client may NOT be able to resolve the artifacts, even in cases of a same-layout operation.

Once you have selected your Target Repository (and Custom Target Path if needed), click Move... or Copy... to
complete the operation.

All metadata is updated to reflect the operation once completed.

Simulating a Move or Copy
Note that an operation may fail or generate warnings for several reasons. For example, the target repository may not accept all the items due to
its own specific policies, or you may not have the required permissions to perform the operation.
Before actually doing an operation, we recommend that you check if it will succeed without errors or warnings by clicking Dry Run.
Artifactory will run a simulation and display any errors and warnings that would appear when doing the actual operation.

Permissions required
To successfully complete a move, you need to have DELETE permission on your source repository, and DEPLOY permission on your
target repository

Downloading a Folder
Artifactory allows the download of a complete folder that is selected in the Tree Browser or Simple Browser.
This ability is configurable by an Artifactory administrator, and if allowed, when a folder is selected the Download function is available in the Actio
ns menu.

The Archive Type. Currently, zip, tar, tar.gz and tgz are supported.
Archive
Type

Include
Checksum
Files

Include SHA1, SHA256 and MD5 files - In Artifactory, checksum files (.sha1, .sha256 and .md5 files) are displayed and are
downloadable in the HTML browsing endpoint (for example, http:///artifactory/),
depending on one of the below pre-conditions:
1.The artifact was originally uploaded with its checksum value (i.e the deploying client provided a checksum header such as the
"X-Checksum-Sha1" header on the request).
2.The repository Checksum Policy is set to "Trust Server Generated Checksums".
If the latter applies, there is no need to provide the artifact checksums during the upload in order for its checksum files to be
visible.
The Download Folder functionality mimics this mechanism, and will write checksum files to the output archive based on the same
conditions.
*With remote repository caches, there is no distinction for the checksum policy of the repository. Simply checking this checkbox
will always result in checksum files being added.

You can also download a folder using the Rest API.

Configuring Folder Download
An Artifactory administrator can enable complete folder download in the Admin module under Admin | General Configuration. This
configuration will apply to all Artiactory users.

The maximum size (MB) of artifacts that can be downloaded in a folder download.
Max Size

The maximum number of artifacts that may be downloaded from the selected folder and all its sub-folders.
Max Number of Files

The maximum number of concurrent folder downloads allowed.
Max Parallel Folder Downloads

Updating Your Profile

Overview
Your profile page is used to manage the following aspects of your user profile:
API Key
Password
Email
Bintray Settings
Binding OAuth Accounts
To display your profile page, click your login name on the top right-hand corner of the screen.

Unlocking Your Profile
To edit your profile, you first need to unlock it by entering your current password and clicking Unlock.
Once unlocked, you can modify all the elements of your user profile.
Page Contents
Overview
Unlocking Your Profile
Changing your Personal Settings
API Key
Revoking or Regenerating an API Key
REST API
Changing Your Password and Email
Password Reminder
Bintray Settings
SSH Key
Binding OAuth Accounts

Saving your changes
Be sure to click Update to save any changes to your profile.

Using external authentication
If you are using an external authentication server (such as HTTP SSO, OAuth SSO, or SAML SSO ), you can ask your administrator
to give you access to your API key, Bintray credentials and SSH public key without having to unlock your profile.

Changing your Personal Settings
Personal settings include your Artifactory API Key, password and email address.
You are not able to change your password if Artifactory is configured to use external authentication such as LDAP.

API Key
Artifactory allows authentication for REST API calls using your API key as an alternative to your username and password in two ways: you may
either using the X-JFrog-Art-API header with which you can specify an API key , or you may use basic authentication using your username
and API key (instead of your password). For more details, please refer to the REST API documentation.
Artifactory version
To use your API key for authentication, it must be generated using Artifactory 4.4.3 or later. If generate before, you must regenerate
your API key and use the new key as a password for basic authentication.

Creating an API Key
To create an API Key, once you have unlocked your profile, click the "Generate" button next to the API Key field.

Revoking or Regenerating an API Key
Once an API Key is created, it displayed, masked, in the corresponding field. Click the "View" icon to see the API Key in clear-text, or the "Copy"
icon to copy the API Key to the clipboard.
To revoke the current API Key, click "Revoke API Key" Note that any REST API calls using the current API key for authentication will no longer be
valid.
You may revoke the current API Key and create a new one in a single action by clicking "Regenerate". Any REST API calls using the current API
key for authentication will no longer be valid, until you replace the API Key with the new one you just generated.

REST API
The following REST API endpoints are available with regard to API Keys:

Endpoint

Description

Create an API key for the current user.
Create API Key

Get the current user's own API key.
Get API Key

Revokes the current user's API key.
Revoke API Key

Revokes the API key of another user (requires Admin privileges).
Revoke User API Key

Revokes all API keys currently defined in the system (requires Admin privileges).
Revoke All API Keys

Changing Your Password and Email
Once your profile is unlocked, Artifactory displays your password in an encrypted format that can be used whenever you need to provide your
password in an environment that is not secure. For example, when making REST API calls over HTTP.
The encrypted password is initially masked, but you may click the "View" icon to view the encrypted password in clear-text. You may also click the
"Copy" icon to copy the encrypted password to the clipboard.
To change your Artifactory password, enter your new password and verify it.
You can also modify your email address.

For more information about using secured passwords with your profile, please refer to Centrally Secure Passwords.

Password Reminder
If you forget your password, on the Artifactory Login dialog, select Forgot Password, and enter your username in the following dialog that is
displayed.

When you click Submit, Artifactory will send a message to the email address configured for your user account, with a link you can click on to
reset your password.

Bintray Settings
Bintray is JFrog's platform to store and distribute your software libraries. For more details please refer to the JFrog Bintray Page.
Upon installation, Artifactory has Bintray's JCenter Java repository defined as a remote repository.
You may freely read from JCenter, and other Bintray repositories, however to upload an artifact, or perform other operations on Bintray through
Artifactory such as search, you must have a Bintray account and provide your credentials through your profile page.
To provide your Bintray credentials, enter your Bintray Username and the Bintray API Key you received when registering to Bintray into the
specified fields in Artirfactory.
To verify that your credentials are valid you can click Test.

SSH Key
From version 4.4, Artifactory supports authentication via SSH for the Git LFS client and the Artifactory CLI.
To be authenticated via SSH, you need to enter your SSH public key in the SSH Public Key (RSA) field.

Binding OAuth Accounts
From version 4.2, Artifactory is integrated with OAuth allowing you to log in through your account with one of the configured OAuth providers. To
do so, you need to bind your OAuth account to your Artifactory user by clicking Click to bind next to the corresponding OAuth provider. For more
details, please refer to OAuth Integration.

Authentication
Overview
The following sections describe all the means of authentication available in Artifactory.

Basic Authentication
Artifactory provides a detailed and flexible permission-based system to control users' access to different
features and artifacts.
To learn more, please refer to Configuring Security.

LDAP
Artifactory supports authenticating users against an LDAP server out-of-the-box. When LDAP authentication
is active, Artifactory first attempts to authenticate the user against the LDAP server. If LDAP authentication
fails, Artifactory tries to authenticate via its internal database. For every LDAP authenticated user Artifactory
creates a new user in the internal database (provided that the user does not already exist), and automatically
assigns that user to the default groups.
To learn more, please refer to Managing Security with LDAP.
Page Contents
Overview
Basic Authentication
LDAP
Active Directory
Single Sign-On
SAML
OAuth
SSH
Atlassian Crowd
Integration
Access Tokens
Custom Authentication
with User Plugins

Active Directory
Artifactory supports integration with an Active Directory server to authenticate users and synchronize groups. When authentication using Active
Directory is configured and active, Artifactory first attempts to authenticate the user against the Active Directory server. If the authentication fails,

Artifactory tries to authenticate via its internal database. For every externally authenticated user configured in your Active Directory server,
Artifactory creates a new user in the internal database (provided the user does not already exist), and automatically assigns that user to the
default groups.
To learn more, please refer to Managing Security with Active Directory.

Single Sign-On
The Single Sign-on (SSO) Add-on allows you to reuse existing HTTP-based SSO infrastructures with Artifactory, such as the SSO modules
offered by Apache HTTPd. Artifactory's authentication will work with commonly available SSO solutions, such as native NTLM, Kerberos, etc...
SSO works by letting Artifactory know what trusted information it should look for in the HTTP request, assuming that this request has already
been authenticated by the SSO infrastructure, which sits in front of Artifactory.
To learn more, please refer to Single Sign-on.

SAML
SAML is an XML standard that allows you to exchange user authentication and authorization information between web domains. JFrog’s
Artifactory offers a SAML-based Single Sign-On service allowing federated Artifactory partners (identity providers) full control over the
authorization process. Using SAML, Artifactory acts as service provider which receives users authentication information from external identity
providers. In such case Artifactory is no longer responsible to authenticate the user although it still has to redirect the login request to the identity
provider and verify the integrity of the identity provider’s response.
To learn more, please refer to SAML SSO Integration.

OAuth
OAuth integration allows you to delegate authentication requests to external providers and let users login to Artifactory using their accounts with
those providers. Currently, Google, OpenID Connect, GitHub Enterprise and Cloud Foundry UAA are supported.
To learn more, please refer to OAuth Integration.

SSH
Artifactory supports SSH authentication for Git LFS and the JFrog CLI using RSA public and private keys. SSH has the benefit of two-way
authentication. In other words, before any sensitive data is exchanged between Artifactory and the client, the Artifactory server is authenticated to
the client, and then the user operating Git LFS or JFrog CLI client is authenticated to Artifactory.
To learn more, please refer to SSH Integration.

Atlassian Crowd Integration
The Atlassian Crowd Integration allows you to delegate authentication requests to Atlassian Crowd, use authenticated Crowd users and have
Artifactory participate in a transparent SSO environment managed by Crowd. In addition, Atlassian Crowd Integration allows the use of JIRA User
Server as an authentication server, but without support of SSO.
To learn more, please refer to Atlassian Crowd and JIRA Integration.

Access Tokens
Artifactory offers the option for authentication through access tokens. An access token may be assigned to a user, or to an entity that is not an
Artifactory user such as a job in a CI server. Permissions are assigned to access tokens by including them in Groups. Access tokens offer
advantages such as cross-site authentication, limited-time access, authenticated access for non-users and more.
To learn more, please refer to Access Tokens.

Custom Authentication with User Plugins
You can use User Plugins to implement custom authentication policies.

To learn more, please refer to Management of Security Realms.

Artifactory REST API
Overview
Artifactory exposes its REST API through an auto-generated WADL file (courtesy of the Jersey REST
framework).
This provides a convenient and up-to-date self-descriptive API and can be used by various tools/frameworks
to automate the creation of REST calls.
The WADL file is available at the following URL:
http://server:port/artifactory/api/application.wadl

Usage
Artifactory REST API endpoints can be invoked in any of the standard ways to invoke a RESTful API. This
section describes how to use the Artifactory REST API using cURL as an example.
Using and Configuring cURL
You can download cURL here. Learn how to use and configure cURL here.

Authentication
Artifactory's REST API supports four forms of authentication:
Basic authentication using your username and password
Basic authentication using your username and API Key.
Using a dedicated header (X-JFrog-Art-Api) with your API Key.
Using an access token instead of a password for basic authentication.
Using an access token as a bearer token in an authorization header (Authorization: Bearer)
with your access token.
Artifactory version
To use your API key for Basic Authentication, it must be generated using Artifactory 4.4.3 or
later. If generated on a previous version, you must regenerate your API key and use the new key
as a password for basic authentication.

Using JFrog CLI
JFrog CLI is a compact and smart client that provides a simple interface to automate access to Artifactory. As
a wrapper to the REST API, it offers a way to simplify automation scripts making them more readable and
easier to maintain, features such as parallel uploads and downloads, checksum optimization and
wildcards/regular expressions make your scripts more efficient and reliable. Please note that several of the
functions available through the REST API are also available through JFrog CLI and you should consider
which method best meets your needs.
For more details on download, installation and usage of JFrog CLI, please refer to the JFrog CLI User Guide.

Example - Deploying an Artifact
The example below demonstrates how to invoke the Deploy Artifact REST API.
You are using cURL from the unix command line, and are presently working from the home (~)
directory of the user 'myUser'
You wish to deploy the file 'myNewFile.txt', which is located in your Desktop directory, ('~/Deskt
op/myNewFile.txt')
You have Artifactory running on your local system, on port 8081
You wish to deploy the artifact into the 'my-repository' repository, under the 'my/new/artifact
/directory/' folder structure, and wish to store the file there as 'file.txt'
You have configured a user in Artifactory named 'myUser', with password 'myP455w0rd!', and this

user has permissions to deploy artifacts
Your API Key is 'ABcdEF'
Where possible, the same example is demonstrated using JFrog CLI
To deploy the file using your username and password for authentication, you would use the following
command:

Using cURL with the REST API
curl -u myUser:myP455w0rd! -X PUT
"http://localhost:8081/artifactory/my-repository/my/n
ew/artifact/directory/file.txt" -T
Desktop/myNewFile.txt

Using JFrog CLI
jfrog rt u file.txt
my-repository/my/new/artifact/directory/
--user=myUser --password=myP455w0rd!

To deploy the file using your API Key for basic authentication, you would use the following command:

Using cURL with the REST API
curl -u myUser:ABcdEF -X PUT
"http://localhost:8081/artifactory/my-repository/my/n
ew/artifact/directory/file.txt" -T
Desktop/myNewFile.txt

Using JFrog CLI
jfrog rt u file.txt
my-repository/my/new/artifact/directory/
--apiKey=ABcdEF

To deploy the file using your API Key in a header, you would use the following command:

Using cURL with the REST API
curl -H "X-JFrog-Art-Api:ABcdEF" -X PUT
"http://localhost:8081/artifactory/my-repository/my/n
ew/artifact/directory/file.txt" -T
Desktop/myNewFile.txt

To deploy the file using your access token for basic authentication, you would use the following command:

Using cURL with an access token
curl -u myUser: -X PUT
"http://localhost:8081/artifactory/my-repository/my/n
ew/artifact/directory/file.txt" -T
Desktop/myNewFile.txt

To deploy the file using your access token in a header, you would use the following command:

Using cURL with an access token
curl -H "Authorization: Bearer " -X PUT
"http://localhost:8081/artifactory/my-repository/my/n
ew/artifact/directory/file.txt" -T
Desktop/myNewFile.txt

Working with Artifactory SaaS
JFrog Artifactory SaaS offers the same extensive functionality and capabilities for automation as an on-prem
installation, including authentication, use of JFrog CLI and the REST API endpoints.
As a SaaS service, the URL is different from an on-prem installation and the REST API endpoints can be
reached at:

http://.jfrog.io/

Example
The snippets below apply the same example described above to an Artifactory SaaS instance named
"myArtifactorySaas" (instead of to an on-prem installation).
To deploy the file using your username and password for authentication, you would use the following
command:

Using cURL with the REST API for Artifactory SaaS
curl -u myUser:myP455w0rd! -X PUT
"http://myartifactorysaas.jfrog.io/myartifactorysaas/
my-repository/my/new/artifact/directory/file.txt" -T
Desktop/myNewFile.txt

Using JFrog CLI
jfrog rt u file.txt
my-repository/my/new/artifact/directory/
--user=myUser --password=myP455w0rd!

Note that using JFrog CLI is identical with an Artifactory SaaS instance. You only need to configure JFrog CLI
with the correct URL for your instance.

REST Resources
The sections below provide a comprehensive listing of the REST resources exposed by Artifactory.
For details on handling errors please refer to ERROR RESPONSES below.
Usage of REST resources is subject to security restrictions applicable to each individual resource.

BUILDS
All Builds
Description: Provides information on all builds
Since: 2.2.0
Security: Requires a privileged user (can be anonymous)
Usage: GET /api/build
Produces: application/vnd.org.jfrog.build.Builds+json
Sample Output:

GET /api/build
{
"uri":
"http://localhost:8081/artifactory/api/build"
"builds" : [
{
"uri" : "/my-build",
"lastStarted" : ISO8601
(yyyy-MM-dd'T'HH:mm:ss.SSSZ)
},
{
"uri" : "/jackrabbit",
"lastStarted" : ISO8601
(yyyy-MM-dd'T'HH:mm:ss.SSSZ)
}
]
}

Build Runs
Description: Build Runs
Since: 2.2.0
Security: Requires a privileged user (can be anonymous)
Usage: GET /api/build/{buildName}
Produces: application/vnd.org.jfrog.build.BuildsByName+json
Sample Output:

GET /api/build/my-build
{
"uri":
"http://localhost:8081/artifactory/api/build/my-build
"
"buildsNumbers" : [
{
"uri" : "/51",
"started" : ISO8601
(yyyy-MM-dd'T'HH:mm:ss.SSSZ)
},
{
"uri" : "/52",
"started" : ISO8601
(yyyy-MM-dd'T'HH:mm:ss.SSSZ)
}
]
}

Build Upload
Description: Upload Build
Security: Requires a privileged user (can be anonymous)
Notes: All build modules must have the build.name and build.number properties set as well as the
correct SHA1 and MD5 in order to be properly linked in the build info.
Usage: PUT /api/build/ -H "Content-Type: application/json" --upload-file build.json
Consumes: application/vnd.org.jfrog.build.BuildsByName+json
Example: curl -X PUT "http://localhost:8081/artifactory/api/build" -H "Content-Type: application/json"
--upload-file build.json
Sample format:
Click to view sample build.json

{
"properties" : {
/* Environment variables and properties
collected from the CI server.
The "buildInfo.env." prefix is added to
environment variables and build related properties.
For system variables there's no prefix. */
"buildInfo.env.JAVA_HOME" : "",
...
},
"version" : "1.0.1", // Build Info schema version
"name" : "My-build-name", // Build name
"number" : "28", // Build number
"type" : "MAVEN", // Build type (values currently
supported: MAVEN, GRADLE, ANT, IVY and GENERIC)
"buildAgent" : { // Build tool information
"name" : "Maven", // Build tool type
"version" : "3.0.5" // Build tool version

},
"agent" : { // CI Server information
"name" : "Jenkins", // CI server type
"version" : "1.554.2" // CI server version
},
"started" : "2014-09-30T12:00:19.893+0300", //
Build start time in the format of
yyyy-MM-dd'T'HH:mm:ss.SSSZ
"artifactoryPluginVersion" : "2.3.1",
"durationMillis" : 9762, // Build duration in
milliseconds
"artifactoryPrincipal" : "james", // Artifactory
principal (the Artifactory user used for
deployment)
"url" :
"http://my-ci-server/jenkins/job/My-project-name/2
8/", // CI server URL
"vcsRevision" :
"e4ab2e493afd369ae7bdc90d69c912e8346a3463", // VCS
revision
"vcsUrl" :
"https://github.com/github-user/my-project.git", //
VCS URL
"licenseControl" : { // Artifactory License
Control information
"runChecks" : true, // Artifactory will run
automatic license scanning after the build is
complete (true/false)
"includePublishedArtifacts" : true, // Should
Artifactory run license checks on the build
artifacts, in addition to the build dependecies
(true/false)
"autoDiscover" : true, // Should Artifactory
auto discover licenses (true/false)
"scopesList" : "", // A space-separated list of
dependency scopes/configurations to run license
violation checks on. If left empty all dependencies
from all scopes will be checked.
"licenseViolationsRecipientsList" : "" //
Emails of recipients that should be notified of
license violations in the build info
(space-separated list)
},
"buildRetention" : { // Build retention
information
"deleteBuildArtifacts" : true, // Automatically
remove build artifacts stored in Artifactory
(true/false)
"count" : 100, // The maximum number of builds
to store in Artifactory.
"minimumBuildDate" : 1407345768020, // Earliest
build date to store in Artifactory
"buildNumbersNotToBeDiscarded" : [ ] // List of

build numbers that should not be removed from
Artifactory
},
/* List of build modules */
"modules" : [ { // The build's first module
"properties" : { // Module properties
"project.build.sourceEncoding" : "UTF-8"
},
"id" : "org.jfrog.test:multi2:4.2-SNAPSHOT", //
Module ID
/* List of module artifacts */
"artifacts" : [ {
"type" : "jar",
"sha1" :
"2ed52ad1d864aec00d7a2394e99b3abca6d16639",
"md5" : "844920070d81271b69579e17ddc6715c",
"name" : "multi2-4.2-SNAPSHOT.jar"
}, {
"type" : "pom",
"sha1" :
"e8e9c7d790191f4a3df3a82314ac590f45c86e31",
"md5" : "1f027d857ff522286a82107be9e807cd",
"name" : "multi2-4.2-SNAPSHOT.pom"
} ],
/* List of module dependencies */
"dependencies" : [ {
"type" : "jar",
"sha1" :
"99129f16442844f6a4a11ae22fbbee40b14d774f",
"md5" : "1f40fb782a4f2cf78f161d32670f7a3a",
"id" : "junit:junit:3.8.1",
"scopes" : [ "test" ]
} ]
}, { // The build's second module
"properties" : { // Module properties
"project.build.sourceEncoding" : "UTF-8"
},
"id" : "org.jfrog.test:multi3:4.2-SNAPSHOT", //
Module ID
/* List of module artifacts */
"artifacts" : [ { // Module artifacts
"type" : "war",
"sha1" :
"df8e7d7b94d5ec9db3bfc92e945c7ff4e2391c7c",
"md5" : "423c24f4c6e259f2774921b9d874a649",
"name" : "multi3-4.2-SNAPSHOT.war"
}, {
"type" : "pom",
"sha1" :
"656330c5045130f214f954643fdc4b677f4cf7aa",
"md5" : "b0afa67a9089b6f71b3c39043b18b2fc",
"name" : "multi3-4.2-SNAPSHOT.pom"
} ],

/* List of module dependencies */
"dependencies" : [ {
"type" : "jar",
"sha1" :
"a8762d07e76cfde2395257a5da47ba7c1dbd3dce",
"md5" : "b6a50c8a15ece8753e37cbe5700bf84f",
"id" : "commons-io:commons-io:1.4",
"scopes" : [ "compile" ]
}, {
"type" : "jar",
"sha1" :
"342d1eb41a2bc7b52fa2e54e9872463fc86e2650",
"md5" : "2a666534a425add50d017d4aa06a6fca",
"id" :
"org.codehaus.plexus:plexus-utils:1.5.1",
"scopes" : [ "compile" ]
}, {
"type" : "jar",
"sha1" :
"449ea46b27426eb846611a90b2fb8b4dcf271191",
"md5" : "25c0752852205167af8f31a1eb019975",
"id" :
"org.springframework:spring-beans:2.5.6",
"scopes" : [ "compile" ]
} ]
} ],
/* List of issues related to the build */
"issues" : {
"tracker" : {
"name" : "JIRA",
"version" : "6.0.1"
},
"aggregateBuildIssues" : true, //whether or
not there are issues that already appeared in
previous builds
"aggregationBuildStatus" : "Released",
"affectedIssues" : [ {
"key" : "RTFACT-1234",
"url" :
"https://www.jfrog.com/jira/browse/RTFACT-1234",
"summary" : "Description of the relevant
issue",
"aggregated" : false //whether or not this
specific issue already appeared in previous builds
}, {
"key" : "RTFACT-5469",
"url" :
"https://www.jfrog.com/jira/browse/RTFACT-5678",
"summary" : "Description of the relevant
issue",
"aggregated" : true
} ]

},
}
}

Build Info
Description: Build Info
Since: 2.2.0
Security: Requires a privileged user with deploy permissions (can be anonymous)
Usage: GET /api/build/{buildName}/{buildNumber}
Produces: application/vnd.org.jfrog.build.BuildInfo+json
Sample Output:

GET /api/build/my-build/51
{
"uri":
"http://localhost:8081/artifactory/api/build/my-build
/51"
"buildInfo" : {
...
}
}

Builds Diff
Description: Compare a build artifacts/dependencies/environment with an older build to see what has
changed (new artifacts added, old dependencies deleted etc).
Since: 2.6.6
Security: Requires a privileged user (can be anonymous)
Usage: GET /api/build/{buildName}/{buildNumber}?diff={OlderbuildNumber}
Produces: application/vnd.org.jfrog.build.BuildsDiff+json
Sample Output:

GET /api/build/my-build/51?diff=50
{
"artifacts": {
"updated": [],
"unchanged": [],
"removed": [],
"new": []
}, "dependencies": {
"updated": [],
"unchanged": [],
"removed": [],
"new": []
}, "properties": {
"updated": [],
"unchanged": [],
"removed": [],
"new": []
}
}

Page contents
Overview
Usage
Authentication
Using JFrog CLI
Example - Deploying an Artifact
Working with Artifactory SaaS
Example
REST Resources
BUILDS
All Builds
Build Runs
Build Upload
Build Info
Builds Diff
Build Promotion
Promote Docker Image
Delete Builds
Build Rename
Push Build to Bintray
Distribute Build
Control Build Retention
ARTIFACTS & STORAGE
Folder Info
File Info
Get Storage Summary Info
Item Last Modified
File Statistics
Item Properties
Set Item Properties
Delete Item Properties
Set Item SHA256 Checksum
Retrieve Artifact
Retrieve Latest Artifact
Retrieve Build Artifacts Archive
Retrieve Folder or Repository Archive
Trace Artifact Retrieval
Archive Entry Download
Create Directory
Deploy Artifact

Deploy Artifact by Checksum
Deploy Artifacts from Archive
Push a Set of Artifacts to Bintray
Push Docker Tag to Bintray
Distribute Artifact
File Compliance Info
Delete Item
Copy Item
Move Item
Get Repository Replication Configuration
Set Repository Replication Configuration
Update Repository Replication Configuration
Delete Repository Replication Configuration
Scheduled Replication Status
Pull/Push Replication
Pull/Push Replication (Deprecated)
Create or Replace Local Multi-push Replication
Update Local Multi-push Replication
Delete Local Multi-push Replication
Enable or Disable Multiple Replications
Get Global System Replication Configuration
Block System Replication
Unblock System Replication
Artifact Sync Download
Folder Sync (Deprecated)
File List
Get Background Tasks
Empty Trash Can
Delete Item From Trash Can
Restore Item from Trash Can
Optimize System Storage
Get Puppet Modules
Get Puppet Module
Get Puppet Releases
Get Puppet Release
SEARCHES
Artifactory Query Language (AQL)
Artifact Search (Quick Search)
Archive Entries Search (Class Search)
GAVC Search
Property Search
Checksum Search
Bad Checksum Search
Artifacts Not Downloaded Since
Artifacts With Date in Date Range
Artifacts Created in Date Range
Pattern Search
Builds for Dependency
License Search
Artifact Version Search
Artifact Latest Version Search Based on Layout
Artifact Latest Version Search Based on Properties
Build Artifacts Search
List Docker Repositories
List Docker Tags
SECURITY
Get Users
Get User Details
Get User Encrypted Password
Create or Replace User
Update User
Delete User
Expire Password for a Single User
Expire Password for Multiple Users
Expire Password for All Users
Unexpire Password for a Single User
Change Password
Get Password Expiration Policy
Set Password Expiration Policy
Configure User Lock Policy
Retrieve User Lock Policy
Get Locked Out Users

Unlock Locked Out User
Unlock Locked Out Users
Unlock All Locked Out Users
Create API Key
Regenerate API Key
Get API Key
Revoke API Key
Revoke User API Key
Revoke All API Keys
Get Groups
Get Group Details
Create or Replace Group
Update Group
Delete Group
Get Permission Targets
Get Permission Target Details
Create or Replace Permission Target
Delete Permission Target
Effective Item Permissions
Security Configuration
Save Security Configuration (Deprecated)
Activate Master Key Encryption
Deactivate Master Key Encryption
Set GPG Public Key
Get GPG Public Key
Set GPG Private Key
Set GPG Pass Phrase
Create Token
Refresh Token
Revoke Token
Get Service ID
Get Certificates
Add Certificate
Delete Certificate
REPOSITORIES
Get Repositories
Repository Configuration
Create Repository
Update Repository Configuration
Delete Repository
Remote Repository Configuration (Deprecated)
Calculate YUM Repository Metadata
Calculate NuGet Repository Metadata
Calculate Npm Repository Metadata
Calculate Maven Index
Calculate Maven Metadata
Calculate Debian Repository Metadata
Calculate Opkg Repository Metadata
Calculate Bower Index
SYSTEM & CONFIGURATION
System Info
System Health Ping
Verify Connection
General Configuration
Save General Configuration
Update Custom URL Base
License Information
Install License
HA License Information
Install HA Cluster Licenses
Delete HA Cluster License
Version and Add-ons information
Get Reverse Proxy Configuration
Update Reverse Proxy Configuration
Get Reverse Proxy Snippet
Create Bootstrap Bundle
PLUGINS
Execute Plugin Code
Retrieve Plugin Code
Retrieve Plugin Info
Retrieve Plugin Info Of A Certain Type
Retrieve Build Staging Strategy

Execute Build Promotion
Reload Plugins
IMPORT & EXPORT
Import Repository Content
Import System Settings Example
Full System Import
Export System Settings Example
Export System
SUPPORT
Create Bundle
List Bundles
Get Bundle
Delete Bundle
ERROR RESPONSES

Read More
Repository Configuration JSON
Security Configuration JSON
System Settings JSON

Build Promotion
Description: Change the status of a build, optionally moving or copying the build's artifacts and its dependencies to a target repository and
setting properties on promoted artifacts.
All artifacts from all scopes are included by default while dependencies are not. Scopes are additive (or).
Since: 2.3.3
Notes: Requires Artifactory Pro
Security: Requires a privileged user (can be anonymous)
Usage: POST /api/build/promote/{buildName}/{buildNumber}
Consumes: application/vnd.org.jfrog.artifactory.build.PromotionRequest+json

POST /api/build/promote/my-build/51
{
"status": "staged",
// new build status (any string)
"comment" : "Tested on all target platforms.", // An optional comment
describing the reason for promotion. Default: ""
"ciUser": "builder",
// The user that invoked promotion from the CI
server
"timestamp" : ISO8601,
// the time the promotion command was received
by Artifactory (It needs to be unique),
// the format is: 'yyyy-MM-dd'T'HH:mm:ss.SSSZ'. Example:
'2016-02-11T18:30:24.825+0200'.
"dryRun" : false,
// run without executing any operation in
Artifactory, but get the results to check if the operation can succeed.
Default: false
"sourceRepo" : "libs-snapshot-local",
// optional repository from which
the build's artifacts will be copied/moved
"targetRepo" : "libs-release-local",
// optional repository to move or
copy the build's artifacts and/or dependencies
"copy": false,
// whether to copy instead of move, when a target
repository is specified. Default: false
"artifacts" : true,
// whether to move/copy the build's artifacts.
Default: true
"dependencies" : false,
// whether to move/copy the build's
dependencies. Default: false.
"scopes" : [ "compile", "runtime" ],
// an array of dependency scopes
to include when "dependencies" is true
"properties": {
// a list of properties to attach to the build's
artifacts (regardless if "targetRepo" is used).
"components": ["c1","c3","c14"],
"release-name": ["fb3-ga"]
},
"failFast": true
// fail and abort the operation upon receiving an
error. Default: true
}

Produces: application/vnd.org.jfrog.artifactory.build.PromotionResult+json
Sample Output:

{
"messages" : [
{
"level": "error",
"message": "The repository has denied...."
},...
]
}

Promote Docker Image
Description: Promotes a Docker image from one repository to another

Since: 3.7
Notes: Requires Artifactory Pro
Security: Requires a privileged user
Usage: POST api/docker//v2/promote
Consumes: application/json

{
"targetRepo" : "",
// The target repository for the
move or copy
"dockerRepository" : "",
// The docker repository
name to promote
"targetDockerRepository" : "" // An optional
docker repository name, if null, will use the same name as
'dockerRepository'
"tag" : "",
// An optional tag name to promote, if null the entire docker repository will be promoted. Available from v4.10.
"targetTag" : "",
// An optional target
tag to assign the image after promotion, if null - will use the same tag
"copy": false
// An optional value to set whether to copy
instead of move. Default: false
}

Produces: application/text
Sample Usage:

POST api/docker/docker-local/v2/promote
{
"targetRepo": "docker-prod",
"dockerRepository": "jfrog/ubuntu"
}

Delete Builds
Description: Removes builds stored in Artifactory. Useful for cleaning up old build info data.
If the artifacts parameter is evaluated as 1 (0/false by default), build artifacts are also removed provided they have the corresponding build.
name and build.number properties attached to them.
If the deleteAll parameter is evaluated as 1 (0/false by default), the whole build is removed.
Since: 2.3.0; artifact removal since 2.3.3;
Notes: Requires Artifactory Pro
Security: Requires an admin user
Usage: DELETE /api/build/{buildName}[?buildNumbers=n1[,n2]][&artifacts=0/1][&deleteAll=0/1]
Produces: application/text
Sample Usage:

DELETE /api/build/my-build?buildNumbers=51,52,55&artifacts=1
The following builds has been deleted successfully: 'my-build#51',
'my-build#52', 'my-build#55'.
DELETE /api/build/my-build?deleteAll=1
All 'my-build' builds have been deleted successfully.

Build Rename
Description: Renames a build stored in Artifactory. Typically used to keep the build info in sync with a renamed build on the CI server.
Since: 2.2.5
Notes: Requires Artifactory Pro
Security: Requires a valid user with deploy permissions
Usage: POST /api/build/rename/{buildName}?to=newBuildName
Produces: application/text
Sample Usage:

POST /api/build/rename/myJobName?to=myNewJobName
Build renaming of 'myJobName' to 'myNewJobName' was successfully started.

Push Build to Bintray
Deprecated: This endpoint is deprecated and is replaced with Distribute Build
Description: Push a build to Bintray as a version.
Uses a descriptor file (that must have 'bintray-info' in it's filename and a .json extension) that is included with the build artifacts. For more details,
please refer to Pushing a Build.
Signing a version is controlled by the gpgSign parameter in the descriptor file, and the gpgSign paramater passed to this command. The value
passed to this command always takes precedence over the value in the descriptor file.
If you also want a passphrase to be applied to your signature, specify gpgPassphrase=.
You may omit the descriptor file by passing 6 override parameters (see below). If you wish to use the descriptor file you should pass an empty
json string instead.
Since: 3.5.0
Security: Requires a valid user with deploy permissions and Bintray credentials defined (for more details, please refer to Entering your Bintray
credentials).
Usage: POST /api/build/pushToBintray/{build.name}/{build.number}?gpgPassphrase=[&gpgSign=true\false]
Consumes: application/vnd.org.jfrog.artifactory.build.BintrayDescriptorOverrideParams+json
Sample Input:

POST
/api/build/pushToBintray/testBuild/1?gpgPassphrase=password&gpgSign=true
{
"subject": "myUser",
"repoName": "test",
"packageName": "overridePkg",
"versionName": "overrideVer",
"licenses": ["MIT"],
"vcs_url": "https://github.com/bintray/bintray-client-java"
}

Produces: application/vnd.org.jfrog.artifactory.bintray.BintrayPushResponse+json
Sample Output:

{"Message": "Pushing build to Bintray finished successfully."}

Distribute Build
Description: Deploys builds from Artifactory to Bintray, and creates an entry in the corresponding Artifactory distribution repository specified.
Notes: Requires Artifactory Pro
Since: 4.8
Security: Requires an authenticated user.

Usage: POST /api/build/distribute/{buildName}/{buildNumber}
Consumes: application/json

{
"publish" : ""
// Default: true. If true, builds are
published when deployed to Bintray
"overrideExistingFiles" : "" // Default: false. If true,
Artifactory overwrites builds already existing in the target path in
Bintray.
// Existing version attributes are also overridden if defined
in the distribution repository Advanced Configuration
"gpgPassphrase" : ""
// If specified, Artifactory will GPG
sign the build deployed to Bintray and apply the specified passphrase
"async" : ""
// Default: false. If true, the build will
be distributed asynchronously. Errors and warnings may be viewed in the log
file
"targetRepo" : "", // The Distribution Repository
into which artifacts should be deployed
"sourceRepos" : [""]
// An array of local repositories from
which build artifacts should be deployed
"dryRun" : ""
// Default: false. If true, distribution
is only simulated. No files are actually moved.
}

Sample input:

POST /api/build/distribute/my-build/1
{
"targetRepo" : "dist-repo-jfrog-artifactory",
"sourceRepos" : ["yum-local"]
}

Control Build Retention
Description: Specifies retention parameters for build info
Since: 5.2.1
Security: Requires a privileged user with deploy permissions (can be anonymous)
Usage: POST /api/build/retention/{buildName}?async=
Consumes: application/json

{
"deleteBuildArtifacts" : , // When true, automatically
removes build artifacts stored in Artifactory
"count" : ,
// The maximum number of builds to store in
Artifactory.
"minimumBuildDate" : ,
// Earliest build date to store in
Artifactory - ISO8601 (yyyy-MM-dd'T'HH:mm:ss.SSSZ)
"buildNumbersNotToBeDiscarded" : [ ]
// List of build numbers that
should not be removed from Artifactory
}

Sample Usage:

POST /api/build/retention/myBuild?async=true
{
"deleteBuildArtifacts" : true,
"count" : 100, //
"minimumBuildDate" : 1407345768020,
"buildNumbersNotToBeDiscarded" : [ 5, 9]
}

ARTIFACTS & STORAGE
Folder Info
Description: Folder Info
For virtual use, the virtual repository returns the unified children. Supported by local, local-cached and virtual repositories.
Since: 2.2.0
Security: Requires a privileged user (can be anonymous)
Usage: GET /api/storage/{repoKey}/{folder-path}
Produces: application/vnd.org.jfrog.artifactory.storage.FolderInfo+json
Sample Output:

GET /api/storage/libs-release-local/org/acme
{
"uri":
"http://localhost:8081/artifactory/api/storage/libs-release-local/org/acme
",
"repo": "libs-release-local",
"path": "/org/acme",
"created": ISO8601 (yyyy-MM-dd'T'HH:mm:ss.SSSZ),
"createdBy": "userY",
"lastModified": ISO8601 (yyyy-MM-dd'T'HH:mm:ss.SSSZ),
"modifiedBy": "userX",
"lastUpdated": ISO8601 (yyyy-MM-dd'T'HH:mm:ss.SSSZ),
"children": [
{
"uri" : "/child1",
"folder" : "true"
},{
"uri" : "/child2",
"folder" : "false"
}
]
}

File Info
Description: File Info
For virtual use the virtual repository returns the resolved file. Supported by local, local-cached and virtual repositories.
Since: 2.2.0
Security: Requires a privileged user (can be anonymous)

Usage: GET /api/storage/{repoKey}/{filePath}
Produces: application/vnd.org.jfrog.artifactory.storage.FileInfo+json
Sample Output:

GET /api/storage/libs-release-local/org/acme/lib/ver/lib-ver.pom
{
"uri":
"http://localhost:8081/artifactory/api/storage/libs-release-local/org/acme
/lib/ver/lib-ver.pom",
"downloadUri":
"http://localhost:8081/artifactory/libs-release-local/org/acme/lib/ver/lib
-ver.pom",
"repo": "libs-release-local",
"path": "/org/acme/lib/ver/lib-ver.pom",
"remoteUrl": "http://some-remote-repo/mvn/org/acme/lib/ver/lib-ver.pom",
"created": ISO8601 (yyyy-MM-dd'T'HH:mm:ss.SSSZ),
"createdBy": "userY",
"lastModified": ISO8601 (yyyy-MM-dd'T'HH:mm:ss.SSSZ),
"modifiedBy": "userX",
"lastUpdated": ISO8601 (yyyy-MM-dd'T'HH:mm:ss.SSSZ),
"size": "1024", //bytes
"mimeType": "application/pom+xml",
"checksums":
{
"md5" : string,
"sha1" : string,
"sha256" : string
},
"originalChecksums":{
"md5" : string,
"sha1" : string,
"sha256" : string
}
}

Get Storage Summary Info
Description: Returns storage summary information regarding binaries, file store and repositories.
Since: 4.2.0
Security: Requires a privileged user (Admin only)
Usage: GET /api/storageinfo
Produces: application/json
Sample Output:

GET /api/storageinfo
{
"binariesSummary": {
"binariesCount": "125,726",
"binariesSize": "3.48 GB",
"artifactsSize": "59.77 GB",
"optimization": "5.82%",
"itemsCount": "2,176,580",
"artifactsCount": "2,084,408"
},
"fileStoreSummary": {
"storageType": "filesystem",
"storageDirectory": "/home/.../artifactory/devenv/.artifactory/data/filestore",
"totalSpace": "204.28 GB",
"usedSpace": "32.22 GB (15.77%)",
"freeSpace": "172.06 GB (84.23%)"
},
"repositoriesSummaryList": [
{
"repoKey": "plugins-release",
"repoType": "VIRTUAL",
"foldersCount": 0,
"filesCount": 0,
"usedSpace": "0 bytes",
"itemsCount": 0,
"packageType": "Maven",
"percentage": "0%"
},
{
"repoKey": "repo",
"repoType": "VIRTUAL",
"foldersCount": 0,
"filesCount": 0,
"usedSpace": "0 bytes",
"itemsCount": 0,
"packageType": "Generic",
"percentage": "0%"
},

...
{
"repoKey": "TOTAL",
"repoType": "NA",
"foldersCount": 92172,
"filesCount": 2084408,
"usedSpace": "59.77 GB",
"itemsCount": 2176580
}
]
}

Item Last Modified
Description: Retrieve the last modified item at the given path. If the given path is a folder, the latest last modified item is searched for recursively.
Supported by local and local-cached repositories.
Since: 2.2.5
Notes: Requires Artifactory Pro
Security: Requires a valid user with deploy permissions
Usage: GET /api/storage/{repoKey}/{item-path}?lastModified
Produces: application/vnd.org.jfrog.artifactory.storage.ItemLastModified+json
Sample Output:

GET /api/storage/libs-release-local/org/acme?lastModified
{
"uri":
"http://localhost:8081/artifactory/api/storage/libs-release-local/org/acme
/foo/1.0-SNAPSHOT/foo-1.0-SNAPSHOT.pom",
"lastModified": ISO8601
}

File Statistics
Description: Item statistics record the number of times an item was downloaded, last download date and last downloader. Supported by local
and local-cached repositories.
Since: 3.1.0
Security: Requires read privileges
Usage: GET /api/storage/{repoKey}/{item-path}?stats
Produces: application/vnd.org.jfrog.storage.StatsInfo+json
Sample Output:

GET /api/storage/libs-release-local/org/acme/foo/1.0/foo-1.0.jar?stats
{
"uri":
"http://localhost:8081/artifactory/api/storage/libs-release-local/org/acme
/foo/1.0/foo-1.0.jar",
"lastDownloaded": Timestamp (ms),
"downloadCount": 1337,
"lastDownloadedBy": "user1"
}

Item Properties
Description: Item Properties. Optionally return only the properties requested.
Since: 2.2.1
Security: Requires a privileged user (can be anonymous)
Usage: GET /api/storage/{repoKey}/{itemPath}?properties[=x[,y]]
Produces: application/vnd.org.jfrog.artifactory.storage.ItemProperties+json
Sample Output:

GET /api/storage/libs-release-local/org/acme?properties\[=x[,y]\]
{
"uri":
"http://localhost:8081/artifactory/api/storage/libs-release-local/org/acme"
"properties":{
"p1": ["v1","v2","v3"],
"p2": ["v4","v5","v6"]
}
}

Set Item Properties
Description: Attach properties to an item (file or folder). When a folder is used property attachment is recursive by default.

In order to supply special characters (comma (,), backslash(\), pipe(|), equals(=)) as key/value you must add an encoded backslash (%5C) before
them. For example: ..?properties=a=1%5C=1 will attach key a with 1=1 as value.
To specify multiple properties, you can separate the items in one of the following ways:
Use a semicolon - ; (recommended)
Use the encoding for the pipe ("|") character - %7C
Alternatively, you may configure your NGINX to encode URLs so that if an unencoded pipe is used in the URL, NGINX will encode it to
%7C. We recommend that you verify that this configuration does not break any other systems served by NGINX
Supported by local and local-cached repositories.
Notes: Requires Artifactory Pro
The following special characters are forbidden in the key field: )(}{][*+^$\/~`!@#%&<>;=,±§ and the Space character.
Since: 2.3.0
Security: Requires a privileged user (can be anonymous)
Usage: PUT /api/storage/{repoKey}{itemPath}?properties=p1=v1[,v2][|p2=v3][&recursive=1]
Sample Usage:

PUT
/api/storage/libs-release-local/ch/qos/logback/logback-classic/0.9.9?prope
rties=os=win,linux;qa=done&recursive=1

Delete Item Properties
Description: Deletes the specified properties from an item (file or folder). When a folder is used property removal is recursive by default. Support
ed by local and local-cached repositories.
Notes: Requires Artifactory Pro
Since: 2.3.2
Security: Requires a privileged user (can be anonymous)
Usage: DELETE /api/storage/{repoKey}{itemPath}?properties=p1[,p2][&recursive=1]
Sample Usage:

DELETE
/api/storage/libs-release-local/ch/qos/logback/logback-classic/0.9.9?prope
rties=os,qa&recursive=1

Set Item SHA256 Checksum
Description: Calculates an artifact's SHA256 checksum and attaches it as a property (with key "sha256"). If the artifact is a folder, then
recursively calculates the SHA256 of each item in the folder and attaches the property to each item.
Since: 4.2.1
Security: Requires an admin user
Consumes: application/json
Usage: POST /api/checksum/sha256 -H "Content-Type: application/json"
Sample Usage:

POST /api/checksum/sha256 -H "Content-Type: application/json"
{
"repoKey":"ext-snapshot-local",
"path":"artifactory-powerpack-3.9.3/bin/"
}

Retrieve Artifact
Description: Retrieves an artifact from the specified destination.
You can also use Property-based Resolution as part of retrieving artifacts.
Security: Requires a user with 'read' permission (can be anonymous)

Usage: GET /repo-key/path/to/artifact.ext
Sample Usage:

GET
http://localhost:8081/artifactory/libs-release-local/ch/qos/logback/logbac
k-classic/0.9.9/logback-classic-0.9.9.jar

Retrieve Latest Artifact
Description: Retrieves the latest artifact version from the specified destination.
Latest Maven Release/Integration: Specify SNAPSHOT or [RELEASE] for the version in the requested path to get the latest Maven integration or
release artifact.
Latest Non-Maven Release/Integration: Specify [INTEGRATION] or [RELEASE] for the version in the requested path (replacing the [folder
ItegRev] and [fileItegRev]
as defined by the repository's layout) to get the latest integration version or latest release version artifact accordingly based on alphabetical
sorting.
Integration and release tokens cannot be mixed together.
You can also use property-based resolution as part of retrieving artifacts to restrict resolution of artifacts assigned with specific properties.
NOTE:
1. Only local, cache and virtual repositories will be used.
2. To change the retrieve latest behavior to retrieve the latest version based on the created date you can add the following flag to $ARTIFA
CTORY_HOME/etc/artifactory.system.properties and add the following flag artifactory.request.searchLatestReleaseByDat
eCreated=true and restart Artifactory service.
Notes: Requires Artifactory Pro.
Since: Latest Maven: 2.6.0; Latest non-Maven: 2.6.2
Security: Requires a user with 'read' permission (can be anonymous)
Usage: GET /repo-key/path/to/artifact.ext
Sample Usage:
Download the latest Maven unique snapshot artifact:

GET
http://localhost:8081/artifactory/libs-release-local/ch/qos/logback/logbac
k-classic/0.9.9-SNAPSHOT/logback-classic-0.9.9-SNAPSHOT.jar

Download the latest release artifact:

GET
http://localhost:8081/artifactory/ivy-local/org/acme/[RELEASE]/acme-[RELEA
SE].jar

Download the latest integration artifact:

GET
http://localhost:8081/artifactory/ivy-local/org/acme/1.0-[INTEGRATION]/acm
e-1.0-[INTEGRATION].jar

Retrieve Build Artifacts Archive
Description: Retrieves an archive file (supports zip/tar/tar.gz/tgz) containing all the artifacts related to a specific build, you can optionally provide
mappings to filter the results,
the mappings support regexp capturing groups which enables you to dynamically construct the target path inside the result archive file.

Notes: Requires Artifactory Pro
Since: 2.6.5
Security: Requires a privileged user (can be anonymous)
Usage: POST /api/archive/buildArtifacts -H "Content-Type: application/json"
Consumes: application/vnd.org.jfrog.artifactory.build.BuildArtifactsRequest+json
Produces: application/zip (for zip archive type), application/x-tar (for tar archive type), application/x-gzip (for tar.gz/tgz archive type)
Sample Usage:

POST /api/archive/buildArtifacts -H "Content-Type: application/json"
{
+"buildName": "build-name" // The build name for search by
+"buildNumber": "15" // The build number to search by, can be LATEST to
search for the latest build number
-"buildStatus": "Released" // Optionally search by latest build status
(e.g: "Released")
-"repos": ["libs-release-local,ext-release-local"] // Optionally refine
search for specific repos, omit to search within all repositories
+"archiveType": "tar/zip/tar.gz/tgz" // The archive file type to return
-"mappings": [ // Optionally refine the search by providing a list of
regexp patterns to search by
{
"input": "(.+)/(.+)-sources.jar",
"output": "$1/sources/$2.jar" // Optionally provide different path of the
found artifacts inside the result archive, supports regexp groups tokens
},
{
"input": "(.+)-release.zip"
}
]
}

Retrieve Folder or Repository Archive
Description: Retrieves an archive file (supports zip/tar/tar.gz/tgz) containing all the artifacts that reside under the specified path (folder or
repository root). Requires Enable Folder Download to be set.
Notes: Requires Artifactory Pro
Since: 4.1.0
Security: Requires a privileged user with read permissions on the path.
Usage: GET /api/archive/download/{repoKey}/{path}?archiveType={archiveType}[&includeChecksumFiles=true]
Produces: */*
Sample Usage:

GET /api/archive/download/my-local-repo/path/to/folder?archiveType=zip
{Stream containing contents of path my-local-repo/path/to/folder}
GET /api/archive/download/my-local-repo?archiveType=zip
{Stream containing contents of repo my-local-repo}

Trace Artifact Retrieval
Description: Simulates an artifact retrieval request from the specified location and returns verbose output about the resolution process.
This API is useful for debugging artifact retrieval issues.
Security: As applied to standard artifact retrieval by the requesting user.
Since: 2.6.0
Usage: GET /repo-key/path/to/artifact.ext?trace

Produces: text/plain
Sample Output:

GET
http://localhost:8081/artifactory/libs-release-local/jmock/jmock/1.0.1/jmo
ck-1.0.1.jar?trace
Request ID: 51c808f6
Repo Path ID: libs-release-local:jmock/jmock/1.0.1/jmock-1.0.1.jar
Method Name: GET
User: resolver
Time: 2012-05-06T10:49:09.528+03:00
Thread: pool-1-thread-31
Steps:
2012-05-06T10:49:09.587+03:00 Received request
2012-05-06T10:49:09.588+03:00 Request source = 0:0:0:0:0:0:0:1, Last
modified = 01-01-70 01:59:59 IST, If modified since = -1, Thread name =
pool-1-thread-31
2012-05-06T10:49:09.697+03:00 Retrieving info
2012-05-06T10:49:09.723+03:00 Identified resource as a file
...
2012-05-06T10:49:09.788+03:00 Responding with selected content handle
2012-05-06T10:49:09.807+03:00 Request succeeded

Archive Entry Download
Description: Retrieves an archived resource from the specified archive destination.
Security: Requires a user with 'read' permission (can be anonymous)
Usage: GET /repo-key/path/to/artifact.jar*!*/path/to/archived/resource (NOTE! the '!' between the archive file name and the archive entry path)
Sample Output:

GET
http://localhost:8081/artifactory/repo1-cache/commons-lang/commons-lang/2.
6/commons-lang-2.6.jar!/META-INF/LICENSE.txt

Create Directory
Description: Create new directory at the specified destination.
Notes: You can also attach properties as part of creating directories.
Security: Requires a user with 'deploy' permissions (can be anonymous)
Usage: PUT /repo-key/path/to/directory/
Produces: application/vnd.org.jfrog.artifactory.storage.ItemCreated+json
Sample Usage:

PUT /libs-release-local/path/to/directory/
{
"uri":
"http://localhost:8081/artifactory/libs-release-local/path/to/directory",
"repo": "libs-release-local",
"path": "/path/to/directory",
"created": ISO8601 (yyyy-MM-dd'T'HH:mm:ss.SSSZ),
"createdBy": "userY",
"children" : [ ]
}

Deploy Artifact
Description: Deploy an artifact to the specified destination.
Notes: You can also attach properties as part of deploying artifacts.
Security: Requires a user with 'deploy' permissions (can be anonymous)
Usage: PUT /repo-key/path/to/artifact.ext
Produces: application/vnd.org.jfrog.artifactory.storage.ItemCreated+json
Sample Usage:

PUT /libs-release-local/my/jar/1.0/jar-1.0.jar
{
"uri":
"http://localhost:8081/artifactory/libs-release-local/my/jar/1.0/jar-1.0.j
ar",
"downloadUri":
"http://localhost:8081/artifactory/libs-release-local/my/jar/1.0/jar-1.0.j
ar",
"repo": "libs-release-local",
"path": "/my/jar/1.0/jar-1.0.jar",
"created": ISO8601 (yyyy-MM-dd'T'HH:mm:ss.SSSZ),
"createdBy": "userY",
"size": "1024", //bytes
"mimeType": "application/java-archive",
"checksums":
{
"md5" : string,
"sha1" : string
},
"originalChecksums":{
"md5" : string,
"sha1" : string
}
}

Deploy Artifact by Checksum
Description: Deploy an artifact to the specified destination by checking if the artifact content already exists in Artifactory.
If Artifactory already contains a user readable artifact with the same checksum the artifact content is copied over to the new location and return a
response without requiring content transfer.
Otherwise, a 404 error is returned to indicate that content upload is expected in order to deploy the artifact.

Notes: You can also attach properties as part of deploying artifacts.
Security: Requires a user with 'deploy' permissions (can be anonymous)
Usage: PUT /repo-key/path/to/artifact.ext
Headers: X-Checksum-Deploy: true, X-Checksum-Sha1: sha1Value, X-Checksum-Sha256: sha256Value, X-Checksum: checksum value (type is
resolved by length)
Produces: application/vnd.org.jfrog.artifactory.storage.ItemCreated+json
Since: 2.5.1
Sample Output:

Deploy Artifacts from Archive
Description: Deploys an archive containing multiple artifacts and extracts it at the specified destination maintaining the archive's file structure.
Deployment is performed in a single HTTP request and only the extracted content is deployed, not the archive file itself.
Supported archive types are: zip; tar; tar.gz; and tgz. NOTE! that deployment of compressed archives (unlike tar) may incur considerable CPU
overhead.
Notes: Requires Artifactory Pro
Security: Requires a user with 'deploy' permissions (can be anonymous)
Usage: PUT path1/to/repo-key/ /path2/to/archive.zip
Headers: X-Explode-Archive: true - archive will be exploded upon deployment, X-Explode-Archive-Atomic: true - archive will be
exploded in an atomic operation upon deployment
Produces: text/plain
Since: 2.6.3
Sample Usage:

PUT /libs-release-local/ /Users/user/Desktop/archive.zip

Push a Set of Artifacts to Bintray
Deprecated: This endpoint is deprecated and is replaced with Distribute Artifact

Description: Push a set of artifacts to Bintray as a version.
Uses a descriptor file (that must have 'bintray-info' in it's filename and a .json extension) that was deployed to artifactory, the call accepts the full
path to the descriptor as a parameter.
For more details, please refer to Pushing a Set of Files.
Signing a version is controlled by the gpgSign parameter in the descriptor file, and the gpgSign paramater passed to this command. The value
passed to this command always takes precedence over the value in the descriptor file.
If you also want a passphrase to be applied to your signature, specify gpgPassphrase=.
Security: Requires a valid user with deploy permissions and Bintray credentials defined (for more details, please refer to Entering your Bintray
credentials).
Usage: POST /api/bintray/push?descriptor=pathToDescriptorFile[&gpgPassphrase=passphrase][&gpgSign=true\false]
Since: 3.5.0
Produces: application/vnd.org.jfrog.artifactory.bintray.BintrayPushResponse+json
Sample Output:

{"Message": "Pushing build to Bintray finished successfully."}

Push Docker Tag to Bintray
Description: Push Docker tag to Bintray
Calculation can be synchronous (the default) or asynchronous.
Security: Requires a valid user with deploy permissions and Bintray credentials defined (for more details, please refer to Entering your Bintray
credentials).
Usage: POST /api/bintray/docker/push/{repoKey}
Since: 3.6.0
Produces: text/plain
Sample Output:

POST api/bintray/docker/push/docker-local
{
"dockerImage": "jfrog/ubuntu:latest", // The docker image to push, use
':' for specific tag or leave blank for 'latest'
"bintraySubject": "shayy", // The Bintray Subject
"bintrayRepo": "containers", // The Bintray Subject's repository
"async": false // Optionally execute the push asynchronously. Default:
false
}

Distribute Artifact
Description: Deploys artifacts from Artifactory to Bintray, and creates an entry in the corresponding Artifactory distribution repository specified
Notes: Requires Artifactory Pro
Since: 4.8
Security: Requires an authenticated user.
Usage: POST /api/distribute
Consumes: application/json

{
"publish" : ""
// Default: true. If true, artifacts are
published when deployed to Bintray
"overrideExistingFiles" : "" // Default: false. If true,
Artifactory overwrites files already existing in the target path in
Bintray.
// Existing version attributes are also overridden if defined
in the distribution repository Advanced Configuration
"gpgPassphrase" : ""
// If specified, Artifactory will GPG
sign the version deployed to Bintray and apply the specified passphrase
"async" : ""
// Default: false. If true, the artifact
will be distributed asynchronously. Errors and warnings may be viewed in
the log file
"targetRepo" : "", // The Distribution Repository
into which artifacts should be deployed
"packagesRepoPaths" : ["",
""]
// An array of local or distribution
repositories and corresponding paths to artifacts that should be deployed
to the specified target repository in Bintray
"dryRun" : ""
// Default: false. If true, distribution
is only simulated. No files are actually moved.
}

Sample input:

POST /api/distribute
{
"targetRepo" : "dist-repo-jfrog-artifactory",
"packagesRepoPaths" : ["yum-local/jfrog-artifactory-pro-4.7.6.rpm"]
}

File Compliance Info
Description: Get compliance info for a given artifact path. The result includes license and vulnerabilities, if any. Supported by local and
local-cached repositories.
Notes: Requires Artifactory Pro, requires Black Duck addon enabled.
Since: 3.0.0
Security: Requires an authenticated user.
Usage: GET: /api/compliance/{repoKey}/{item-path}
Produces: application/json
Sample output:

GET:
/api/compliance/libs-release-local/ch/qos/logback/logback-classic/0.9.9/lo
gback-classic-0.9.9.jar
{
"licenses" : [ {"name":"LGPL v3", "url": "http://"}, {"name":"APL v2",
"url": "http://"}... ],
"vulnerabilities" : [ {"name":"CVE-13427", "url": "http://"},
{"name":"CVE-1041", "url": "http://"}... ]
}

Delete Item
Description: Deletes a file or a folder from the specified destination.
Security: Requires a user with 'delete' permission (can be anonymous)
Usage: DELETE /repo-key/path/to/file-or-folder
Sample Usage:

DELETE
http://localhost:8081/artifactory/libs-release-local/ch/qos/logback/logbac
k-classic/0.9.9

Copy Item
Description: Copy an artifact or a folder to the specified destination. Supported by local repositories only.
Optionally suppress cross-layout module path translation during copy.
You can test the copy using a dry run.
Copy item behaves similarly to a standard file system and supports renames. If the target path does not exist, the source item is copied and
optionally renamed. Otherwise, if the target exists and it is a directory,
the source is copied and placed under the target directory.
Notes: Requires Artifactory Pro
Security: Requires a privileged user (can be anonymous)
Usage: POST /api/copy/{srcRepoKey}/{srcFilePath}?to=/{targetRepoKey}/{targetFilePath}[&dry=1][&suppressLayouts=0/1(default)][&failFast=0/1]
Produces: application/vnd.org.jfrog.artifactory.storage.CopyOrMoveResult+json
Since: 2.2.2
Sample Output:

POST
/api/copy/libs-release-local/org/acme?to=/ext-releases-local/org/acme-new&
dry=1
{
"messages" : [
{
"level": "error",
"message": "The repository has denied...."
},...
]
}

Move Item

Description: Moves an artifact or a folder to the specified destination. Supported by local repositories only.
Optionally suppress cross-layout module path translation during move.
You can test the move using dry run.
Move item behaves similarly to a standard file system and supports renames. If the target path does not exist, the source item is moved and
optionally renamed. Otherwise, if the target exists and it is a directory,
the source is moved and placed under the target directory.
Notes: Requires Artifactory Pro
Security: Requires a privileged user (can be anonymous)
Usage: POST /api/move/{srcRepoKey}/{srcFilePath}?to=/{targetRepoKey}/{targetFilePath}[&dry=1][&suppressLayouts=0/1(default)][&failFast=0/1]
Produces: application/vnd.org.jfrog.artifactory.storage.CopyOrMoveResult+json
Since: 2.2.2
Sample Output:

POST
/api/move/libs-release-local/org/acme?to=/ext-releases-local/org/acme-new&
dry=1
{
"messages" : [
{
"level": "error",
"message": "The repository has denied...."
},...
]
}

Get Repository Replication Configuration
Description: Returns the replication configuration for the given repository key, if found. Supported by local and remote repositories. Note: The
'enableEventReplication' parameter refers to both push and pull replication.
Notes: Requires Artifactory Pro
Security: Requires a privileged user
Usage: GET /api/replications/{repoKey}
Produces: application/vnd.org.jfrog.artifactory.replications.ReplicationConfigRequest+json
Since: 3.1.1
Sample Usage:

GET /api/replications/libs-release-local
{
"url" : "http://localhost:8081/artifactory/remote-repo",
"socketTimeoutMillis" : 15000,
"username" : "admin",
"password" : "password",
"enableEventReplication" : false,
"enabled" : true,
"cronExp" : "0 0 12 * * ?",
"syncDeletes" : true,
"syncProperties" : true,
"syncStatistics" : false,
"repoKey" : "libs-release-local",
"pathPrefix" : "/path/to/repo"
}

Set Repository Replication Configuration
Description: Add or replace replication configuration for given repository key. Supported by local and remote repositories. Accepts the JSON

payload returned from Get Repository Replication Configuration for a single and an array of configurations. If the payload is an array of replication
configurations, then values for cronExp and enableEventReplication in the first element in the array will determine the corresponding
values when setting the repository replication configuration.
Notes: Requires Artifactory Pro
Security: Requires a privileged user
Usage: PUT /api/replications/{repoKey}
Consumes: application/vnd.org.jfrog.artifactory.replications.ReplicationConfigRequest+json
Since: 3.1.1
Sample Usage:

PUT /api/replications/libs-release-local

Update Repository Replication Configuration
Description: Update existing replication configuration for given repository key, if found. Supported by local and remote repositories.
Notes: Requires Artifactory Pro
Security: Requires a privileged user
Usage: POST /api/replications/{repoKey}
Consumes: full or partial application/vnd.org.jfrog.artifactory.replications.ReplicationConfigRequest+json
Since: 3.1.1
Sample Usage:

POST /api/replications/libs-release-local

Delete Repository Replication Configuration
Description: Delete existing replication configuration for given repository key. Supported by local and local-cached repositories.
Notes: Requires Artifactory Pro
Security: Requires a privileged user
Usage: DELETE /api/replications/{repoKey}
Since: 3.1.1
Sample Usage:

DELETE /api/replications/libs-release-local

Scheduled Replication Status
Description: Returns the status of scheduled cron-based replication jobs define via the Artifactory UI on repositories. Supported by local,
local-cached and remote repositories.
Notes: Requires Artifactory Pro
Security: Requires a user with 'read' permission (can be anonymous)
Usage: GET /api/replication/{repoKey}
Produces: application/vnd.org.jfrog.artifactory.replication.ReplicationStatus+json

GET /api/replication/remote-libs
{
"status": {status},
"lastCompleted": {time},
"targets":
[
{ "url" : targetUrl, "repoKey": {repoKy}, "status" : {status},
"lastCompleted" : {time} },
...
{ "url" : targetUrl, "repoKey": {repoKy}, "status" : {status},
"lastCompleted" : {time}}
],
"repositories":
{
{repoKy} : { "status" : {status}, "lastCompleted" : {time} },
...
{repoKy} : { "status" : {status}, "lastCompleted" : {time} }
}
}
where:
{status}= never_run|incomplete(running or
interrupted)|error|warn|ok|inconsistent
{time}= time in ISO8601 format (yyyy-MM-dd'T'HH:mm:ss.SSSZ), or null if
never completed

Since: 2.4.2
Sample Usage:

GET /api/replication/remote-libs
{
"status" : "ok",
"lastCompleted" : 2015-12-27T15:08:49.050+02:00",
"targets":
[
{ "url": "http://remote_host/remote-libs1", "repoKey": "remote-libs1",
"status" : {status}, "lastCompleted" : "2015-12-27T15:07:49.050+02:00" },
...
{ "url" : "http://remote_host/remote-libs2", "repoKey": "remote-libs2",
"status" : {status}, "lastCompleted" : "2015-12-27T15:07:49.050+02:00" }
],
"repositories":
{
"remote-libs1" : { "status" : "ok", "lastCompleted" :
"2015-12-27T15:07:49.050+02:00" },
...
"remote-libs2" : { "status" : "ok", "lastCompleted" :
"2015-12-27T15:07:49.050+02:00" }
}
}

Pull/Push Replication
Description: Schedules immediate content replication between two Artifactory instances.
Replication can optionally include properties and delete items if they do not exist in the source repository.
This API completes the existing cron-based replication exposed via the Artifactory UI and allows for pre-scheduled execution.
Pull Replication - pulls content from a remote Artifactory repository to a local cache of the remote repository.
Push Replication - pushes content from a local repository into a local repository of another Artifactory instance.
Multi-push Replication - pushes content from a local repository into a local repository of several Artifactory instances. This feature is only
available with Artifactory Enterprise license.
The type of replication initiated depends on the type of repository specified in the repoPath parameter.
If repoPath is a local repository, a push replication will be triggered. You may specify multiple target repositories in the payload for multi-push
replication, but all must be local to their respective instances.
If repoPath is a remote repository cache, a pull replication will be triggered. Note that in this case you may only specify a single repository in the
payload.
Important note - If no repositories are provided in the payload, Artifactory will trigger all existing replication configurations.
Security: Requires a privileged user (can be anonymous) For non-admin users, the maximum number of files that will be replicated is as defined
by the artifactory.search.userQueryLimit system property.
Usage: POST /api/replication/execute/{repoPath}
Consumes: application/json

[
{
+ "url" : "",
+ "username" : "",
+ "password" : "",
- "proxy" : ""
- "properties" : "", // When true, properties of replicated
artifacts will be synchronized also
- "delete" : ""
// When true, items that were deleted
remotely will also be deleted locally (including properties metadata)
}
]

+=mandatory; -=optional
Since: 4.7.5
Sample Usage:

// Single push replication
POST /api/replication/execute/libs-release-local
{
[
{
"url":"http://localhost:8082/artifactory/libs-release-local",
"username":"admin",
"password":"password",
"proxy":"localProxy"
}
]
}

// Pull replication
POST /api/replication/execute/libs-remote
{
[
{
"properties" : "true",
"delete" : "true"
}
]
}
// Multi-push replication
POST /api/replication/execute/libs-release-local
{
[
{
"url":"http://localhost:8082/artifactory/libs-release-local",
"username":"admin",
"password":"password",
"proxy":"localProxy",
"properties" : "true",
"delete" : "true"
},
{
"url":"http://localhost:8082/artifactory/ext-release-local",
"username":"admin",
"password":"password"
"properties" : "true",
"delete" : "true"
},
{
"url":"http://localhost:8082/artifactory/plugins-release-local",
"username":"admin",
"password":"password"
"properties" : "true",
"delete" : "true"
}
]
}
// Trigger configured push replication
POST /api/replication/execute/libs-release-local

// Trigger configured pull replication
POST /api/replication/execute/libs-remote

Pull/Push Replication (Deprecated)
Description: Schedules immediate content replication between two Artifactory instances. Replication can include properties and can optionally
delete local items if they do not exist in the source repository.
This API completes the existing cron-based replication exposed via the Artifactory UI and allows for on-demand execution.
Pull Replication - pulls content from a remote Artifactory repository to a local cache of the remote repository.
Push Replication - pushes content from a local repository into a remote Artifactory local repository.
Supported by local, local-cached and remote repositories.
Notes: Requires Artifactory Pro
Security: Requires a privileged user (can be anonymous) For non-admin users will replicate at max the number of files as defined by the artifa
ctory.search.userQueryLimit system property.
Usage: POST /api/replication/{srcRepoKey}/{srcPath}
Consumes: application/vnd.org.jfrog.artifactory.replication.ReplicationRequest+json
Since: 2.4.0
Sample Usage:

POST /api/replication/libs-release-local/com/acme
{
//The following is only applicable for push replication
+ "url" : "https://repo.nmiy.org/repo-key", // The remote repository URL
+ "username": "replicator", //The name of a user with deploy permissions
on the remote repository
+ "password": "***", //The remote repository password
- "properties": true, //Sync item properties (true by default)
- "delete": true, //Sync deletions (false by default)
- "proxy": "org-prox", //A name of an Artifactory-configured proxy to use
for remote requests
}

+=mandatory; -=optional

Create or Replace Local Multi-push Replication
Description:Creates or replaces a local multi-push replication configuration. Supported by local and local-cached repositories.
Notes: Requires an enterprise license
Security: Requires an admin user.
Usage: PUT /api/replications/multiple/{repo-key}
Consumes: application/vnd.org.jfrog.artifactory.replications.MultipleReplicationConfigRequest+json
Since: 3.7
Sample Usage:

PUT /api/replications/multiple/libs-release-local
{
"cronExp":"0 0/9 14 * * ?",
"enableEventReplication":true,
"replications":[
{
+ "url": "http://localhost:8081/artifactory/repo-k",
+ "socketTimeoutMillis": 15000,
+ "username": "admin",
+ "password": "password",
- "enableEventReplication": true,
- "enabled": true,
- "syncDeletes": false,
- "syncProperties": true,
"syncStatistics" : false,
- "repoKey": "libs-release-local"
}
,
{
+ "url": "http://localhost:8081/artifactory/repo-v",
+ "socketTimeoutMillis": 15000,
+ "username": "admin",
+ "password": "password",
- "enableEventReplication": true,
- "enabled": true,
- "syncDeletes": false,
- "syncProperties": true,
"syncStatistics" : false,
- "repoKey": "libs-release-local"
}
]
}

+=mandatory; -=optional

Update Local Multi-push Replication
Description:Updates a local multi-push replication configuration. Supported by local and local-cached repositories.
Notes: Requires an enterprise license
Security: Requires an admin user.
Usage: POST /api/replications/multiple/{repo-key}
Consumes: application/vnd.org.jfrog.artifactory.replications.MultipleReplicationConfigRequest+json
Since: 3.7
Sample Usage:

POST /api/replications/multiple/libs-release-local
{
"cronExp":"0 0/9 14 * * ?",
"enableEventReplication":true,
"replications":[
{
+
"url": "http://localhost:8081/artifactory/repo-k",
+
"socketTimeoutMillis": 15000,
+
"username": "admin",
+
"password": "password",
"enableEventReplication": true,
"enabled": true,
"syncDeletes": false,
"syncProperties": true,
"syncStatistics" : false,
"repoKey": "libs-release-local"
}
,
{
+
"url": "http://localhost:8081/artifactory/repo-v",
+
"socketTimeoutMillis": 15000,
+
"username": "admin",
+
"password": "password",
"enableEventReplication": true,
"enabled": true,
"syncDeletes": false,
"syncProperties": true,
"syncStatistics" : false,
"repoKey": "libs-release-local"
}
]
}

+=mandatory; -=optional

Delete Local Multi-push Replication
Description:Deletes a local multi-push replication configuration. Supported by local and local-cached repositories.
Notes: Requires an enterprise license
Security: Requires an admin user.
Usage: DELETE /api/replications/{repoKey}?url={replicatedURL}
If the url parameter is omitted, all multi-push replication configurations for the source repository are deleted.
Produces: application/vnd.org.jfrog.artifactory.replications.ReplicationConfigRequest+json, application/vnd.org.jfrog.artifactory.replications.Multipl
eReplicationConfigRequest+json
Since: 3.7
Sample Usage:

DELETE
/api/replications/libs-release-local?url=http://10.0.0.1/artifactory/libsrelease-local
//Delete all multi-push replication configurations for libs-release-local
DELETE /api/replications/libs-release-local

Enable or Disable Multiple Replications
Description: Enables/disables multiple replication tasks by repository or Artifactory server based in include and exclude patterns.
Notes: Requires Artifactory Pro
Security: Requires a privileged user
Usage: POST /api/replications/{enable | disable}
Consumes: application/json
Since: 4.4.3
Sample Usage:

//Enable/disable all push replications except those going out to
http://artimaster:port/artifactory and
https://somearti:port/artifactory/local-repo.
POST /api/replications/{enable | disable}
{
"include" : [ "**" ],
"exclude" : [ "http://artimaster:port/artifactory/**",
"https://somearti:port/artifactory/local-repo" ]
}
//Enable/disable all push replications expect those going out to
http://artidr:port/artifactory
POST /api/replications/{enable | disable}
{
"include" : [ "**" ],
"exclude" : [ "http://artidr:port/artifactory/**" ]
}

Get Global System Replication Configuration
Description: Returns the global system replication configuration status, i.e. if push and pull replications are blocked or unblocked.
Notes: Requires Artifactory Pro
Security: Requires an admin user
Usage: GET /api/system/replications
Produces: application/json
Since: 4.7.2
Sample Usage:

GET /api/system/replications
{
"blockPullReplications": false,
"blockPushReplications": false
}

Block System Replication
Description: Blocks replications globally. Push and pull are true by default. If false, replication for the corresponding type is not blocked.
Notes: Requires Artifactory Pro
Security: Requires an admin user
Usage: POST api/system/replications/block?push=[true|false]&pull=[true|false]
Produces: text/plain
Since: 4.7.2
Sample Usage:

POST /api/system/replications/block
Successfully blocked all replications, no replication will be triggered.

Unblock System Replication
Description: Unblocks replications globally. Push and pull are true by default. If false, replication for the corresponding type is not unblocked.
Notes: Requires Artifactory Pro
Security: Requires an admin user
Usage: POST api/system/replications/unblock?push=[true|false]&pull=[true|false]
Produces: text/plain
Since: 4.7.2
Sample Usage:

POST /api/system/replications/unblock
Successfully unblocked all replications

Artifact Sync Download
Description: Downloads an artifact with or without returning the actual content to the client. When tracking the progress marks are printed (by
default every 1024 bytes). This is extremely useful if you want to trigger downloads on a remote Artifactory server,
for example to force eager cache population of large artifacts, but want to avoid the bandwidth consumption involved in transferring the artifacts to
the triggering client. If no content parameter is specified the file content is downloaded to the client.
Notes: This API requires Artifactory Pro.
Security: Requires a privileged user (can be anonymous)
Usage: GET /api/download/{repoKey}/{filePath}[?content=none/progress][&mark=numOfBytesToPrintANewProgressMark]
Produces: application/octet-stream, text/plain (depending on content type)
Since: 2.2.2
Sample Output:

GET
/api/download/my-remote/org/acme/1.0/acme-1.0.jar?content=progress&mark=512
.....................................................
.....................................................
.....
Completed: 150/340 bytes

Folder Sync (Deprecated)
Description: Triggers a no-content download of artifacts from a remote Artifactory repository for all artifacts under the specified remote folder.
Can optionally delete local files if they do not exist in the remote folder,

overwrite local files only if they are older than remote files or never overwrite local files.
The default is not to delete any local files and to overwrite older local files with remote ones. By default progress marks of the sync are displayed.
The default timeout for the remote file list is 15000 milliseconds (15 seconds).
Notes: This API is deprecated. Requires Artifactory Pro
Security: Requires a privileged user (can be anonymous) For non-admin users will replicate at max the number of files as defined by the artifa
ctory.search.userQueryLimit system property.
Usage: GET
/api/sync/{remoteRepositoryKey}/{folderPath}[?progress=showProgress][&mark=numOfBytesToPrintANewProgressMark][&delete=deleteExisting
Files][&overwrite=never/force][&timeout=fileListTimeoutInMillis]
Produces: text/plain
Since: 2.2.4
Sample Output:

GET /api/sync/my-remote/org/acme/1.0?progress=1&delete=1
.....................................................
.....................................................
.....................................................
..........................................
Completed: 970/1702 bytes
.....................................................
..................
Completed: 1702/1702 bytes
Completed with 0 errors and 2 warnings (please check the server log for
more details).

File List
Description: Get a flat (the default) or deep listing of the files and folders (not included by default) within a folder.
For deep listing you can specify an optional depth to limit the results.
Optionally include a map of metadata timestamp values as part of the result (only properties are displayed in since 3.0.0).
folder inclusion since 2.3.2; checksum inclusion since: 2.3.3; include folder root path since: 2.5.2. Supported by all types of repositories.
Since: 2.2.4
Notes: Requires Artifactory Pro
Security: Requires a non-anonymous privileged user.
Usage: GET /api/storage/{repoKey}/{folder-path}?list[&deep=0/1][&depth=n][&listFolders=0/1][&mdTimestamps=0/1][&includeRootPath=0/1]
Produces: application/vnd.org.jfrog.artifactory.storage.FileList+json
Sample Output:

GET
/api/storage/libs-release-local/org/acme?list&deep=1&listFolders=1&mdTimes
tamps=1
{
"uri":
"http://localhost:8081/artifactory/api/storage/libs-release-local/org/acme
",
"created": ISO8601,
"files" : [
{
"uri": "/archived",
"size": "-1",
"lastModified": ISO8601,
"folder": "true"
},
{
"uri": "/doc.txt",
"size": "253207", //bytes
"lastModified": ISO8601,
"folder": "false",
"sha1": sha1Checksum,
"mdTimestamps": { "properties" : lastModified (ISO8601) }
},
{
"uri": "/archived/doc1.txt",
"size": "253100", //bytes
"lastModified": ISO8601,
"folder": "false",
"sha1": sha1Checksum,
"mdTimestamps": { "properties" : lastModified (ISO8601) }
},...
]
}

Get Background Tasks
Description: Retrieves list of background tasks currently scheduled or running in Artifactory. In HA, the nodeId is added to each task. Task can
be in one of few states: scheduled, running, stopped, cancelled. Running task also shows the task start time.
Since: 4.4.0
Security: Requires a valid admin user
Usage: GET /api/tasks
Produces: application/json
Sample Output:

{
"tasks" : [ {
"id" :
"artifactory.UpdateIndicesJob#d7321feb-6fd9-4e27-8f0e-954137be855b",
"type" :
"org.artifactory.addon.gems.index.GemsVirtualIndexHandler$UpdateIndicesJob
",
"state" : "scheduled",
"description" : "Gems Virtual Repositories Index Calculator",
"nodeId" : "artifactory-primary"
}, {
"id" :
"artifactory.VirtualCacheCleanupJob#82bb1514-ea34-4a71-940d-78a61887981e",
"type" : "org.artifactory.repo.cleanup.VirtualCacheCleanupJob",
"state" : "scheduled",
"description" : "",
"nodeId" : "artifactory-primary"
}, {
"id" :
"artifactory.BinaryStoreGarbageCollectorJob#039664ac-990d-4a32-85e1-decd0b
508142",
"type" :
"org.artifactory.storage.binstore.service.BinaryStoreGarbageCollectorJob",
"state" : "running",
"started" : "2015-05-15T15:39:37.566+02:00"
"description" : "Binaries Garbage Collector",
"nodeId" : "artifactory-primary"
} ]
}

Empty Trash Can
Description: Empties the trash can permanently deleting all its current contents.
Notes: Requires Artifactory Pro
Security: Requires a valid admin user
Usage: POST /api/trash/empty
Since: 4.4.3

Delete Item From Trash Can
Description: Permanently deletes an item from the trash can.
Notes: Requires Artifactory Pro
Security: Requires a valid admin user
Usage: DELETE /api/trash/clean/{repoName/path}
Since: 4.4.3
Sample usage:

DELETE /api/trash/clean/npm-local

Restore Item from Trash Can
Description: Restore an item from the trash can.

Notes: Requires Artifactory Pro
Security: Requires a valid admin user
Usage: POST /api/trash/restore/{from path}?to={to path}
Since: 4.4.3
Sample usage:

POST /api/trash/restore/npm-local?to=npm-local2
Successfully restored trash items

Optimize System Storage
Description: Raises a flag to invoke balancing between redundant storage units of a sharded filestore following the next garbage collection.
Since: 4.6.0
Notes: This is an advanced feature intended for administrators.
Security: Requires a valid admin user.
Usage: POST /api/system/storage/optimize
Produces: text/plain
Sample Usage:

POST /api/system/storage/optimize
200 OK

Get Puppet Modules
Description: Returns a list of all Puppet modules hosted by the specified repository. Results are paginated and all of the parameters in the
pagination section are optional.
Notes: Requires Artifactory Pro. This endpoint will work only on local and remote repositories.
Usage: GET /api/puppet/{repoKey}/v3/modules
Security: Requires a privileged user (can be anonymous)
Produces: application/json
Click here to expand...

{
"total": 0,
"limit": 0,
"offset": 0,
"current": "uri",
"next": "uri",
"previous": "uri",
"results": [
{
"uri": "uri",
"name": "",
"downloads": 0,
"created_at": "date-time",
"updated_at": "date-time",
"supported": false,
"owner": {
"uri": "",
"username": ""
},
"current_release": {
"uri": "",
"version": "",
"module": "object",
"metadata": "object",
"tags": [
""
],
"supported": false,
"file_size": 0,
"file_md5": "",
"downloads": 0,
"readme": "",
"changelog": "",
"license": "",
"created_at": "date-time",
"updated_at": "date-time",
"deleted_at": "date-time"
},
"releases": [
{
"uri": "uri",
"version": ""
}
],
"homepage_url": "uri",
"issues_url": "uri"
}
]
}

Sample Usage:

GET /api/puppet/puppet-local/v3/modules/
Response:
{
"pagination" : {
"limit" : 20,
"offset" : 0,
"first" : "/v3/modules?limit=20&offset=0",
"previous" : null,
"current" : "/v3/modules?limit=20&offset=0",
"next" : null,
"total" : 1
},
"results" : [ {
"uri" : "/v3/modules/maestrodev-wget",
"slug" : "maestrodev-wget",
"name" : "wget",
"downloads" : 0,
"created_at" : "2017-07-16 12:07:715 +0300",
"updated_at" : "2017-07-16 12:07:00 +0300",
"supported" : false,
"endorsement" : null,
"module_group" : "base",
"owner" : {
"uri" : "/v3/users/maestrodev",
"slug" : "maestrodev",
"username" : "maestrodev",
"gravatar_id" : null
},
"current_release" : {
"uri"
...
} ]
}

Get Puppet Module
Description: Returns information about a specific Puppet module.
Notes: Requires Artifactory Pro. This endpoint will work only on local and remote repositories.
Usage: GET /api/puppet/{repoKey}/v3/modules/{user}-{module}
Security: Requires a privileged user (can be anonymous)
Produces: application/json
Click here to expand...

{
"uri": "uri",
"name": "",
"downloads": 0,
"created_at": "date-time",
"updated_at": "date-time",
"supported": false,
"owner": {
"uri": "",
"username": ""
},
"current_release": {
"uri": "",
"version": "",
"module": "object",
"metadata": "object",
"tags": [
""
],
"supported": false,
"file_size": 0,
"file_md5": "",
"downloads": 0,
"readme": "",
"changelog": "",
"license": "",
"created_at": "date-time",
"updated_at": "date-time",
"deleted_at": "date-time"
},
"releases": [
{
"uri": "uri",
"version": ""
}
],
"homepage_url": "uri",
"issues_url": "uri"
}

Get Puppet Releases
Description: Returns a list of all Puppet releases hosted by the specified repository. Results are paginated and all of the parameters in the
pagination section are optional.
Notes: Requires Artifactory Pro. This endpoint will work only on local and remote repositories.
Usage: GET /api/puppet/{repoKey}/v3/releases
Security: Requires a privileged user (can be anonymous)
Produces: application/json

{
"total": 0,
"limit": 0,
"offset": 0,
"current": "uri",
"next": "uri",
"previous": "uri",
"results": [
{
"uri": "uri",
"version": "",
"module": {
"uri": "",
"name": ""
},
"metadata": "object",
"tags": [
""
],
"supported": false,
"file_size": 0,
"file_md5": "",
"downloads": 0,
"readme": "",
"changelog": "",
"license": "",
"created_at": "date-time",
"updated_at": "date-time",
"deleted_at": "date-time"
}
]
}

Get Puppet Release
Description: Returns information about the specific Puppet module's release.
Notes: Requires Artifactory Pro. This endpoint will work only on local and remote repositories.
Usage: GET /api/puppet/{repoKey}/v3/releases/{user}-{module}-{version}
Security: Requires a privileged user (can be anonymous)
Produces: application/json

{
"uri": "uri",
"version": "",
"module": {
"uri": "",
"name": ""
},
"metadata": "object",
"tags": [
""
],
"supported": false,
"file_size": 0,
"file_md5": "",
"downloads": 0,
"readme": "",
"changelog": "",
"license": "",
"created_at": "date-time",
"updated_at": "date-time",
"deleted_at": "date-time"
}

SEARCHES
All searches return limited results for internal and anonymous users (same limits as in the user interface).
To modify the default limit results, edit the artifactory.system.properties file with artifactory.search.limitAnonymousUsersOnl
y=false (default is true) and add a new limit with artifactory.search.userQueryLimit (default is 1000).
Applicable to the following REST API calls:
Artifact Search, Archive Entries Search, GAVC Search, Property Search, Checksum Search (limited by UI max results), Artifacts Not
Downloaded Since, Artifacts With Date in Date Range, Artifacts Created in Date Range.

Artifactory Query Language (AQL)
Description: Flexible and high performance search using Artifactory Query Language (AQL).
Since: 3.5.0
Security: Requires an authenticated user. Certain domains/queries may require Admin access.
Usage: POST /api/search/aql
Consumes: text/plain
Sample Usage:

POST /api/search/aql
items.find(
{
"repo":{"$eq":"libs-release-local"}
}
)

Produces: application/json
Sample Output:

{
"results" : [
{
"repo" : "libs-release-local",
"path" : "org/jfrog/artifactory",
"name" : "artifactory.war",
"type" : "item type",
"size" : "75500000",
"created" : "2015-01-01T10:10;10",
"created_by" : "Jfrog",
"modified" : "2015-01-01T10:10;10",
"modified_by" : "Jfrog",
"updated" : "2015-01-01T10:10;10"
}
],
"range" : {
"start_pos" : 0,
"end_pos" : 1,
"total" : 1
}
}

Artifact Search (Quick Search)
Description: Artifact search by part of file name.
Searches return file info URIs. Can limit search to specific repositories (local or caches).
Since: 2.2.0
Security: Requires a privileged user (can be anonymous)
Usage: GET /api/search/artifact?name=name[&repos=x[,y]]
Headers (Optionally): X-Result-Detail: info (To add all extra information of the found artifact), X-Result-Detail: properties (to get the properties of
the found artifact), X-Result-Detail: info, properties (for both).
Produces: application/vnd.org.jfrog.artifactory.search.ArtifactSearchResult+json
Sample Output:

GET /api/search/artifact?name=lib&repos=libs-release-local
{
"results": [
{
"uri":
"http://localhost:8081/artifactory/api/storage/libs-release-local/org/acme
/lib/ver/lib-ver.pom"
},{
"uri":
"http://localhost:8081/artifactory/api/storage/libs-release-local/org/acme
/lib/ver2/lib-ver2.pom"
}
]
}

Archive Entries Search (Class Search)

Description: Search archive for classes or any other resources within an archive.
Can limit search to specific repositories (local or caches).
Since: 2.2.0
Security: Requires a privileged user (can be anonymous)
Usage: GET /api/search/archive?name=[archiveEntryName][&repos=x[,y]]
Produces: application/vnd.org.jfrog.artifactory.search.ArchiveEntrySearchResult+json
Sample Output:

GET
/api/search/archive?name=*Logger.class&repos=third-party-releases-local,re
po1-cache
{
"results" :[
{
"entry":
"org/apache/jackrabbit/core/query/lucene/AbstractIndex.LoggingPrintStream.
class",
"archiveUris": [
"http://localhost:8081/artifactory/api/storage/third-party-releases-local/
org/apache/jackrabbit/
jackrabbit-core/1.2.3/jackrabbit-core-1.2.3.jar",
"http://localhost:8081/artifactory/api/storage/third-party-releases-local/
org/apache/jackrabbit/
jackrabbit-core/1.3.1/jackrabbit-core-1.3.1.jar"
]
},{
"entry": "org/codehaus/plexus/logging/AbstractLogger.class",
"archiveUris": [
"http://localhost:8081/artifactory/api/storage/repo1-cache/org/codehaus/pl
exus/plexus-container-default/
1.0-alpha-9-stable-1/plexus-container-default-1.0-alpha-9-stable-1.jar"
]
}
]
}

GAVC Search
Description: Search by Maven coordinates: GroupId, ArtifactId, Version & Classifier.
Search must contain at least one argument. Can limit search to specific repositories (local and remote-cache).
Since: 2.2.0
Security: Requires a privileged user (can be anonymous)
Usage: GET /api/search/gavc?[g=groupId][&a=artifactId][&v=version][&c=classifier][&repos=x[,y]]
Headers (Optionally): X-Result-Detail: info (To add all extra information of the found artifact), X-Result-Detail: properties (to get the properties of
the found artifact), X-Result-Detail: info, properties (for both).
Produces: application/vnd.org.jfrog.artifactory.search.GavcSearchResult+json
Sample Output:

GET
/api/search/gavc?g=org.acme&a=artifact&v=1.0&c=sources&repos=libs-releaselocal
{
"results": [
{
"uri":
"http://localhost:8081/artifactory/api/storage/libs-release-local/org/acme
/artifact/1.0/artifact-1.0-sources.jar"
},{
"uri":
"http://localhost:8081/artifactory/api/storage/libs-release-local/org/acme
/artifactB/1.0/artifactB-1.0-sources.jar"
}
]
}

Property Search
Description: Search by properties.
If no value is specified for a property - assume '*'. Can limit search to specific repositories (local, remote-cache or virtual).
Since: 2.2.0
Security: Requires a privileged user (can be anonymous)
Usage: GET /api/search/prop?[p1=v1,v2][&p2=v3][&repos=x[,y]]
Headers (Optionally): X-Result-Detail: info (To add all extra information of the found artifact), X-Result-Detail: properties (to get the properties of
the found artifact), X-Result-Detail: info, properties (for both).
Produces: application/vnd.org.jfrog.artifactory.search.MetadataSearchResult+json
Sample Output:

GET /api/search/prop?p1=v1,v2&p2=v3&repos=libs-release-local
{
"results" : [
{
"uri":
"http://localhost:8081/artifactory/api/storage/libs-release-local/org/acme
/lib/ver/lib-ver.pom"
},{
"uri":
"http://localhost:8081/artifactory/api/storage/libs-release-local/org/acme
/lib/ver2/lib-ver2.pom"
}
]
}

Checksum Search
Description: Artifact search by checksum (md5, sha1, or sha256)
Searches return file info URIs. Can limit search to specific repositories (local, remote-cache or virtual).
Notes: Requires Artifactory Pro
Since: 2.3.0
Security: Requires a privileged user (can be anonymous)
Usage: GET /api/search/checksum?md5=md5sum?sha1=sha1sum?sha256=sha256sum[&repos=x[,y]]
Headers (Optionally): X-Result-Detail: info (To add all extra information of the found artifact), X-Result-Detail: properties (to get the properties of

the found artifact), X-Result-Detail: info, properties (for both).
Produces: application/vnd.org.jfrog.artifactory.search.ChecksumSearchResult+json
Sample Output:

GET
/api/search/checksum?sha256=9a7fb65f15e00aa2a22c1917d0dafd4374fee8daf0966a
4d94cd37a0b9acafb9&repos=libs-release-local
{
"results": [
{
"uri":
"http://localhost:8081/artifactory/api/storage/libs-release-local/org/jfro
g/build-info-api/1.3.1/build-info-api-1.3.1.jar"
}
]
}

Bad Checksum Search
Description: Find all artifacts that have a bad or missing client checksum values (md5 or sha1)
Searches return file info uris. Can limit search to specific repositories (local, remote-cache or virtual).
Notes: Requires Artifactory Pro
Since: 2.3.4
Security: Requires a privileged user (can be anonymous)
Usage: GET /api/search/badChecksum?type=md5|sha1[&repos=x[,y]]
Produces: application/vnd.org.jfrog.artifactory.search.BadChecksumSearchResult+json
Sample Output:

GET /api/search/badChecksum?type=md5&repos=libs-release-local
{
"results": [
{
"uri":
"http://localhost:8081/artifactory/api/storage/libs-release-local/org/jfro
g/build-info-api/1.3.1/build-info-api-1.3.1.jar"
"serverMd5": "4040c7c184620af0a0a8a3682a75eb7"
"clientMd5": "4040c7c184620af0a0a8a3682a75e44" //On missing
checksum this element will be an empty string
}
]
}

Artifacts Not Downloaded Since
Description: Retrieve all artifacts not downloaded since the specified Java epoch in milliseconds.
Optionally include only artifacts created before the specified createdBefore date, otherwise only artifacts created before notUsedSince are
returned.
Can limit search to specific repositories (local or caches).
Since: 2.2.4
Security: Requires a privileged non-anonymous user.
Usage: GET /api/search/usage?notUsedSince=javaEpochMillis[&createdBefore=javaEpochMillis][&repos=x[,y]]
Produces: application/vnd.org.jfrog.artifactory.search.ArtifactUsageResult+json
Sample Output:

GET
/api/search/usage?notUsedSince=long&createdBefore=long&repos=libs-releaselocal
{
"results" : [
{
"uri":
"http://localhost:8081/artifactory/api/storage/libs-release-local/org/acme
/lib/ver/lib-ver.jar",
"lastDownloaded": ISO8601
},{
"uri":
"http://localhost:8081/artifactory/api/storage/libs-release-local/org/acme
/lib/ver2/lib-ver2.jar",
lastDownloaded: ISO8601
}
]
}

Artifacts With Date in Date Range
Description: Get all artifacts with specified dates within the given range. Search

can be limited to specific repositories (local or
caches).
Since: 3.2.1
Security: Requires a privileged non-anonymous user.
Usage: GET /api/search/dates?[from=fromVal][&to=toVal][&repos=x[,y]][&dateFields=c[,d]]
Parameters: The from and to parameters can be either a long value for the java epoch (milliseconds since
the epoch), or an ISO8601 string value. from is mandatory. If to is not provided, now() will be used instead,
and if either are omitted, 400 bad request is returned.
The dateFields parameter is a comma separated list of date fields that specify which fields the from and to
values should be applied to. The date fields supported are: created, lastModified, lastDownloaded.
It is a mandatory field and it also dictates which fields will be added to the JSON returned.
If ANY of the specified date fields of an artifact is within the specified range, the artifact will be returned.
Produces: application/vnd.org.jfrog.artifactory.search.ArtifactResult+json
Sample Output:

GET
/api/search/dates?dateFields=created,lastModified,lastDownloaded&from=long
&to=long&repos=libs-release-local
{
"results" : [
{
"uri":
"http://localhost:8081/artifactory/api/storage/libs-release-local/org/acme
/lib/ver/lib-ver.jar",
"created": ISO8601,
"lastModified": ISO8601,
"lastDownloaded": ISO8601
},{
"uri":
"http://localhost:8081/artifactory/api/storage/libs-release-local/org/acme
/lib/ver2/lib-ver2.jar",
"created": ISO8601.
"lastModified": ISO8601,
"lastDownloaded": ISO8601
}
]
}

Artifacts Created in Date Range
Description: Get All Artifacts Created in Date Range
If 'to' is not specified use now(). Can limit search to specific repositories (local or remote-cache).
Since: 2.2.0
Security: Requires a privileged non-anonymous user.
Usage: GET /api/search/creation?from=javaEpochMillis[&to=javaEpochMillis][&repos=x[,y]]
Produces: application/vnd.org.jfrog.artifactory.search.ArtifactCreationResult+json
Sample Output:

GET /api/search/creation?from=long&to=long&repos=libs-release-local
{
"results" : [
{
"uri":
"http://localhost:8081/artifactory/api/storage/libs-release-local/org/acme
/lib/ver/lib-ver.jar",
"created": ISO8601
},{
"uri":
"http://localhost:8081/artifactory/api/storage/libs-release-local/org/acme
/lib/ver2/lib-ver2.jar",
"created": ISO8601
}
]
}

Pattern Search
Description: Get all artifacts matching the given Ant path pattern
Since: 2.2.4
Notes: Requires Artifactory Pro. Pattern "**" is not supported to avoid overloading search results.
Security: Requires a privileged non-anonymous user.
Usage: GET /api/search/pattern?pattern=repo-key:this/is/a/*pattern*.war
Produces: application/vnd.org.jfrog.artifactory.search.PatternResultFileSet+json
Sample Output:

GET /api/search/pattern?pattern=libs-release-local:killer/*/ninja/*/*.jar
{
"repositoryUri" :
"http://localhost:8081/artifactory/libs-release-local",
"sourcePattern" : "libs-release-local:killer/*/ninja/*/*.jar",
files : [
"killer/coding/ninja/1.0/monkey-1.0.jar",
"killer/salty/ninja/1.5-SNAPSHOT/pickle-1.5-SNAPSHOT.jar"
]
}

Builds for Dependency
Description: Find all the builds an artifact is a dependency of (where the artifact is included in the build-info dependencies)
Notes: Requires Artifactory Pro
Since: 2.3.4
Security: Requires a privileged user (can be anonymous)
Usage: GET /api/search/dependency?sha1=sha1Checksum
Produces: application/vnd.org.jfrog.artifactory.search.DependencyBuilds+json
Sample Output:

GET /api/search/dependency?sha1=451a3c5f8cfa44c5d805379e760b5c512c7d250b
{
"results" : [
{
"uri": "http://localhost:8081/artifactory/api/build/my-build/50"
},{
"uri": "http://localhost:8081/artifactory/api/build/my-build/51"
}
]
}

License Search
Description: Search for artifacts that were already tagged with license information and their respective licenses.
To search by specific license values use Property Search with the 'artifactory.licenses' property.
When the autofind parameter is specified Artifactory will try to automatically find new license information and return it as part of the result in
the found field.
Please note that this can affect the speed of the search quite dramatically, and will still search only on already-tagged artifacts.
Default parameter values when unspecified: unapproved=1, unknown=1, notfound=0, neutral=0, approved=0, autofind=0.
Can limit search to specific repositories (local, remote-cache or virtual).
Since: 2.3.0
Notes: Requires Artifactory Pro
Security: Requires an admin user
Usage: GET /api/search/license[?unapproved=1][&unknown=1][¬found=0][&neutral=0][&approved=0][&autofind=0][&repos=x[,y]]

Produces: application/vnd.org.jfrog.artifactory.search.LicenseResult+json
Sample Output:

GET
/api/search/license?approved=1&unknown=1&autofind=1&repos=libs-release-loc
al,staging
{
"results" : [
{
"uri":
"http://localhost:8081/artifactory/api/storage/libs-release-local/org/acme
/lib/ver/lib-ver.jar",
"license": "lgplv2",
"found": "lgplv2",
"status": "approved"
},{
"uri":
"http://localhost:8081/artifactory/api/storage/libs-release-local/org/acme
/lib/ver/lib-ver.jar",
"license": "cddlv1",
"found": "gplv3",
"status": "neutral"
},{
"uri":
"http://localhost:8081/artifactory/api/storage/staging/org/acme/lib/ver2/l
ib-ver2.jar",
"license": "gplv3",
"found": "gplv3",
"status": "unapproved"
}
]
}

Artifact Version Search
Description: Search for all available artifact versions by GroupId and ArtifactId in local, remote or virtual repositories.
Search can be limited to specific repositories (local, remote and virtual) by settings the repos parameter.
Release/integration versions: Unless the version parameter is specified, both release and integration versions are returned. When version is s
pecified, e.g. 1.0-SNAPSHOT, result includes only integration versions.
Integration versions are determined by the repository layout of the repositories searched. For integration search to work the repository layout
requires an 'Artifact Path Pattern' that contains the baseRev token and then the fileItegRev token with only literals between them.
Remote searches: By default only local and cache repositories are used. When specifying remote=1, Artifactory searches for versions on remote
repositories. NOTE! that this can dramatically slow down the search.
For Maven repositories the remote maven-metadata.xml is consulted. For non-maven layouts, remote file listing runs for all remote repositories
that have the 'List Remote Folder Items' checkbox enabled.
Filtering results (Artifactory 3.0.2+): The version parameter can accept the * and/or ? wildcards which will then filter the final result to match only
those who match the given version pattern.
Since: 2.6.0
Notes: Requires Artifactory Pro
Security: Requires a privileged user (can be anonymous)
Usage: GET /api/search/versions?[g=groupId][&a=artifactId][&v=version][&remote=0/1][&repos=x[,y]]
Produces: application/vnd.org.jfrog.artifactory.search.ArtifactVersionsResult+json
Sample Output:

GET /api/search/versions?g=org.acme&a=artifact&repos=libs-release-local
{
"results": [
{
"version": "1.2",
"integration": false
},{
"version": "1.0-SNAPSHOT",
"integration": true
},{
"version": "1.0",
"integration": false
}
]
}

Artifact Latest Version Search Based on Layout
Description: Search for the latest artifact version by groupId and artifactId, based on the layout defined in the repository
Search can be limited to specific repositories (local, remote-cache or virtual) by settings the repos parameter. When searching in a virtual
repository, each child-repository layout will be consulted accordingly.
Latest release vs. latest integration: Unless the version parameter is specified, the search returns the latest artifact release version. When vers
ion is specified, e.g. 1.0-SNAPSHOT, the result is the latest integration version. Integration versions are determined by the repository layout of
the repositories searched. For integration search to work the repository layout requires an "Artifact Path Pattern" that contains the baseRev token
and then the fileItegRev token with only literals between them.
Remote searches: By default only local and cache repositories will be used. When specifying remote=1, Artifactory searches for versions on
remote repositories. NOTE! that this can dramatically slow down the search.
For Maven repositories the remote maven-metadata.xml will be consulted. For non-Maven layouts, remote file listing runs for all
remote repositories that have the 'List Remote Folder Items' checkbox enabled.
Filtering results (Artifactory 3.0.2+): The version parameter can accept the * and/or ? wildcards which will then filter the final result to match only
those who match the given version pattern.
Artifact path pattern: The [org] and [module] fields must be specified in the artifact path pattern of the repository layout for this call to work.
Since: 2.6.0
Notes: Requires Artifactory Pro
Security: Requires a privileged user (can be anonymous)
Usage: GET /api/search/latestVersion?[g=groupId][&a=artifactId][&v=version][&remote=1][&repos=x[,y]]
Produces: text/plain
Sample Output:

GET
/api/search/latestVersion?g=org.acme&a=artifact&v=1.0-SNAPSHOT&repos=libssnapshot-local
1.0-201203131455-2

Artifact Latest Version Search Based on Properties
Description: Search for artifacts with the latest value in the "version" property. Only artifacts with a "version" property expressly defined in
lower case will be returned. Results can be filtered by specifying additional properties.
{repo}: Specify a repository to search through or replace with "_any" to search through all repositories
{path}: Specify a path to search through or replace with "_any" to search through all paths
listFiles=0 (default): Artifactory will only retrieve the latest version
listFiles=1: Artifactory will retrieve the latest version and the corresponding files
You may specify filters to restrict the set of artifacts that are searched by adding any properties to your search URL
Notes: Requires Artifactory Pro

Since: 3.1.1
Security: Requires an authenticated user (not anonymous) to use the api and read permission to the repository of each artifact.
Usage: GET /api/versions/{repo}/{path}?[listFiles=0/1]&[=]&[=]
Consumes: json
Examples:

Return the latest version and corresponding artifacts by searching for
through all repositories whose path starts with a/b and are annotated with
the properties os=win and license=GPL.
GET /api/versions/_any/a/b?os=win&license=GPL&listFiles=1
{
"version" : "1.1.2",
"artifacts" : [ {
"uri" : "http://...."
}]
}
Return the latest version (without the corresponding artifacts) by
searching through all repositories whose path starts with a/b and are
annotated with the properties os=win and license=GPL.
Return only the version.
GET /api/versions/_any/a/b?os=win&license=GPL
{
"version" : "1.1.2",
"artifacts" : []
}

Build Artifacts Search
Description: Find all the artifacts related to a specific build.
Notes: Requires Artifactory Pro
Since: 2.6.5
Security: Requires a privileged user (can be anonymous)
Usage: POST /api/search/buildArtifacts
Consumes: application/vnd.org.jfrog.artifactory.search.BuildArtifactsRequest+json
Sample Usage:

POST /api/search/buildArtifacts
{
+"buildName": "build-name" // The build name for search by
+"buildNumber": "15" // The build number to search by, can be LATEST to
search for the latest build number
-"buildStatus": "Released" // Optionally search by latest build status
(e.g: "Released")
-"repos": ["libs-release-local,ext-release-local"] // Optionally refine
search for specific repos, omit to search within all repositories
-"mappings": [ // Optionally refine the search by providing a list of
regexp patterns to search by
{
"input": "(.+)-sources.jar"
},
{
"input": "(.+)-javadoc.jar"
}
]
}

Produces: application/vnd.org.jfrog.artifactory.search.BuildArtifactsSearchResult+json
Sample Output:

POST /api/search/buildArtifacts
{
"results" : [
{
"downloadUri":
"http://localhost:8081/artifactory/libs-release-local/org/acme/lib/ver/lib
-sources.jar"
},{
"downloadUri":
"http://localhost:8081/artifactory/ext-release-local/org/acme/lib/ver/libver-javadoc.jar"
}
]
}

List Docker Repositories
Description: Lists all Docker repositories (the registry's _catalog) hosted in an Artifactory Docker repository.
Since: 4.4.3. The n and last pagination parameters are supported from version 5.4.6.
Notes: Requires Artifactory Pro
Security: Requires a privileged user
Usage: GET /api/docker/{repo-key}/v2/_catalog?n=&last=
Produces: application/json

{
"repositories": [
,
...
]
}

Sample Usage:

GET /api/docker/docker-local/v2/_catalog
{
"repositories": [
"busybox",
"centos",
"hello-world"
]
}

List Docker Tags
Description: Lists all tags of the specified Artifactory Docker repository.
Since: 4.4.3. The n and last pagination parameters are supported from version 5.4.6.
Notes: Requires Artifactory Pro
Security: Requires a privileged user
Usage: GET /api/docker/{repo-key}/v2/{image name}/tags/list?n=&last=
Produces: application/json

{
"name": "",
"tags" : [""]
}

Sample Usage:

GET api/docker/v2/postgres/tags/list
{
"name" : "postgres",
"tags" : [ "9.5.2" ]
}

SECURITY
Get Users
Description: Get the users list
Since: 2.4.0
Notes: Requires Artifactory Pro

Security: Requires an admin user
Usage: GET /api/security/users
Produces: application/vnd.org.jfrog.artifactory.security.Users+json
Sample Output:

GET /api/security/users
[
{
"name": "davids"
"uri" : "http://localhost:8081/artifactory/api/security/users/davids"
"realm" : "internal"
}, {
"name": "danl"
"uri" : "http://localhost:8081/artifactory/api/security/users/danl"
"realm" : "ldap"
}
]

Get User Details
Description: Get the details of an Artifactory user
Since: 2.4.0
Notes: Requires Artifactory Pro
Security: Requires an admin user
Usage: GET /api/security/users/{userName}
Produces: application/vnd.org.jfrog.artifactory.security.User+json
Sample Output:

GET /api/security/users/davids
{
user.json
}

Get User Encrypted Password
Description: Get the encrypted password of the authenticated requestor
Since: 3.3.0
Security: Requires a privileged user
Usage: GET /api/security/encryptedPassword
Produces: plain/text
Sample Output:

GET /api/security/encryptedPassword
AP5v2zs9ga7CJNZb74u3arAKE5B

Create or Replace User
Description: Creates a new user in Artifactory or replaces an existing user
Since: 2.4.0
Notes: Requires Artifactory Pro
Missing values will be set to the default values as defined by the consumed type.
Security: Requires an admin user

Usage: PUT /api/security/users/{userName}
Consumes: application/vnd.org.jfrog.artifactory.security.User+json
Sample Usage:

PUT /api/security/users/davids
{
user.json
}

Update User
Description: Updates an exiting user in Artifactory with the provided user details.
Since: 2.4.0
Notes: Requires Artifactory Pro
Missing values will be set to the default values as defined by the consumed type
Security: Requires an admin user
Usage: POST /api/security/users/{userName}
Consumes: application/vnd.org.jfrog.artifactory.security.User+json
Sample Usage:

POST /api/security/users/davids
{
user.json
}

Delete User
Description: Removes an Artifactory user.
Since: 2.4.0
Notes: Requires Artifactory Pro
Security: Requires an admin user
Usage: DELETE /api/security/users/{userName}
Produces: application/text
Sample Usage:

DELETE /api/security/users/davids
User 'davids' has been removed successfully.

Expire Password for a Single User
Description: Expires a user's password
Since: 4.4.2
Notes: Requires Artifactory Pro
Security: Requires an admin user
Usage: POST /api/security/users/authorization/expirePassword/{userName}
Sample Usage:

POST /api/security/users/authorization/expirePassword/davids

Expire Password for Multiple Users

Description: Expires password for a list of users
Since: 4.4.2
Notes: Requires Artifactory Pro
Security: Requires an admin user
Usage: POST /api/security/users/authorization/expirePassword -H "Content-type: application/json" -d '[{userA}, {userB}]'
Sample Usage:

POST /api/security/users/authorization/expirePassword -H "Content-type:
application/json" -d '[{davids}, {johnb}]'

Expire Password for All Users
Description: Expires password for all users
Since: 4.4.2
Notes: Requires Artifactory Pro
Security: Requires an admin user
Usage: POST /api/security/users/authorization/expirePasswordForAllUsers
Sample Usage:

POST /api/security/users/authorization/expirePasswordForAllUsers

Unexpire Password for a Single User
Description: Unexpires a user's password
Since: 4.4.2
Notes: Requires Artifactory Pro
Security: Requires an admin user
Usage: POST /api/security/users/authorization/unexpirePassword/{userName}
Produces: application/text
Sample Usage:

POST /api/security/users/authorization/unexpirePassword/davids

Change Password
Description: Changes a user's password
Since: 4.4.2
Notes: Requires Artifactory Pro
Security: Admin can apply this method to all users, and each (non-anonymous) user can use this method to change his own password.
Usage: POST /api/security/users/authorization/changePassword -H "Content-type: application/json" -d ' { "userName" : "{user}", "oldPassword" :
"{old password}", "newPassword1" : "{new password}", "newPassword2" : "{verify new password}" }
Produces: application/text
Sample Usage:

POST /api/security/users/authorization/changePassword -H "Content-type:
application/json" -d ' { "userName" : "davids", "oldPassword" : "op",
"newPassword1" : "np", "newPassword2" : "np" }

Get Password Expiration Policy
Description: Retrieves the password expiration policy
Since: 4.4.2

Notes: Requires Artifactory Pro
Security: Requires an admin user
Usage: GET /api/security/configuration/passwordExpirationPolicy
Produces: application/json
Sample Usage:

GET /api/security/configuration/passwordExpirationPolicy
{
"enabled":"true"
"passwordMaxAge":"60"
"notifyByEmail":"true"
}

Set Password Expiration Policy
Description: Sets the password expiration policy
Since: 4.4.2
Notes: Requires Artifactory Pro
Security: Requires an admin user
Usage: PUT /api/security/configuration/passwordExpirationPolicy -H "Content-type: application/json" -d ' { "enabled" : "true|false",
"passwordMaxAge" : "1-999", "notifyByEmail": "true|false" }
Produces: application/json
Sample Usage:

POST /api/security/configuration/passwordExpirationPolicy -H "Content-type:
application/json" -d ' { "enabled" : "true", "passwordMaxAge" : "60",
"notifyByEmail": "true" }

Configure User Lock Policy
Description: Configures the user lock policy that locks users out of their account if the number of repeated incorrect login attempts exceeds the
configured maximum allowed.
Security: Requires a valid admin user
Usage: PUT /api/security/userLockPolicy
Produces: application/text
Since: 4.4
Sample usage:

PUT http://{host}:{port}/artifactory/api/security/userLockPolicy -H
'Content-Type: application/json'-d '
{
"enabled" : true|false,
"loginAttempts" : {value}
}'

Retrieve User Lock Policy
Description: Retrieves the currently configured user lock policy.
Security: Requires a valid admin user
Usage: GET /api/security/userLockPolicy
Produces: application/json
Since: 4.4
Sample usage:

GET http://{host}:{port}/artifactory/api/security/userLockPolicy
'{
"enabled" : true|false,
"loginAttempts" : {value}
}'

Get Locked Out Users
Description: If locking out users is enabled, lists all users that were locked out due to recurrent incorrect login attempts.
Security: Requires a valid admin user
Usage: GET /api/security/lockedUsers
Produces: application/json
Since: 4.4
Sample Usage:

GET /api/security/lockedUsers
[ "usera", "userb",

... ]

Unlock Locked Out User
Description: Unlocks a single user that was locked out due to recurrent incorrect login attempts.
Security: Requires a valid admin user
Usage: POST /api/security/unlockUsers/{userName}
Produces: application/text
Since: 4.4
Sample Usage:

POST /api/security/unlockUsers/{userName}

Unlock Locked Out Users
Description: Unlocks a list of users that were locked out due to recurrent incorrect login attempts.
Security: Requires a valid admin user
Usage: POST /api/security/unlockUsers
Produces: application/text
Since: 4.4
Sample Usage:

POST /api/security/unlockUsers -H 'Content-Type: application/json' -d '[
{userA}, {userB} ]'

Unlock All Locked Out Users
Description: Unlocks all users that were locked out due to recurrent incorrect login attempts.
Security: Requires a valid admin user
Usage: POST /api/security/unlockAllUsers
Produces: application/text

Since: 4.4
Sample Usage:

POST /api/security/unlockAllUsers

Create API Key
Description:Create an API key for the current user. Returns an error if API key already exists - use regenerate API key instead.
Since: 4.3.0
Usage: POST /api/security/apiKey
Produces: application/json
Sample input:

POST /api/security/apiKey

Sample output:

{
"apiKey": "3OloposOtVFyCMrT+cXmCAScmVMPrSYXkWIjiyDCXsY="
}

Regenerate API Key
Description:Regenerate an API key for the current user
Since: 4.3.0
Usage: PUT /api/security/apiKey
Produces: application/json
Sample input:

PUT /api/security/apiKey

Sample output:

{
"apiKey": "3OloposOtVFyCMrT+cXmCAScmVMPrSYXkWIjiyDCXsY="
}

Get API Key
Description:Get the current user's own API key
Since: 4.3.0
Usage: GET /api/security/apiKey
Produces: application/json
Sample usage:

GET /api/security/apiKey

Sample output:

{
"apiKey": "3OloposOtVFyCMrT+cXmCAScmVMPrSYXkWIjiyDCXsY="
}

Revoke API Key
Description: Revokes the current user's API key
Since: 4.3.0
Usage: DELETE /api/security/apiKey
Produces: application/json

Revoke User API Key
Description: Revokes the API key of another user
Since: 4.3.0
Security: Requires a privileged user (Admin only)
Usage: DELETE /api/security/apiKey/{username}
Produces: application/json

Revoke All API Keys
Description: Revokes all API keys currently defined in the system
Since: 4.3.0
Security: Requires a privileged user (Admin only)
Usage: DELETE /api/security/apiKey?deleteAll={0/1}
Produces: application/json

Get Groups
Description: Get the groups list
Since: 2.4.0
Notes: Requires Artifactory Pro
Security: Requires an admin user
Usage: GET /api/security/groups
Produces: application/vnd.org.jfrog.artifactory.security.Users+json, application/vnd.org.jfrog.artifactory.security.Groups+json, application/vnd.org.j
frog.artifactory.security.PermissionTargets+json
Sample Output:

GET /api/security/groups
[
{
"name": "readers"
"uri" : "http://localhost:8081/artifactory/api/security/groups/readers"
}, {
"name": "tech-leads"
"uri" :
"http://localhost:8081/artifactory/api/security/groups/tech-leads"
}
]

Get Group Details
Description: Get the details of an Artifactory Group
Since: 2.4.0

Notes: Requires Artifactory Pro
Security: Requires an admin user
Usage: GET /api/security/groups/{groupName}
Produces: application/vnd.org.jfrog.artifactory.security.Group+json
Sample Output:

GET /api/security/groups/dev-leads
{
group.json
}

Create or Replace Group
Description: Creates a new group in Artifactory or replaces an existing group
Since: 2.4.0
Notes: Requires Artifactory Pro
Missing values will be set to the default values as defined by the consumed type.
Security: Requires an admin user
Usage: PUT /api/security/groups/{groupName}
Consumes: application/vnd.org.jfrog.artifactory.security.Group+json
Sample Usage:

PUT /api/security/groups/dev-leads
{
group.json
}

Update Group
Description: Updates an exiting group in Artifactory with the provided group details.
Since: 2.4.0
Notes: Requires Artifactory Pro
Security: Requires an admin user
Usage: POST /api/security/groups/{groupName}
Consumes: application/vnd.org.jfrog.artifactory.security.Group+json
Sample Usage:

POST /api/security/groups/dev-leads
{
group.json
}

Delete Group
Description: Removes an Artifactory group.
Since: 2.4.0
Notes: Requires Artifactory Pro
Security: Requires an admin user
Usage: DELETE /api/security/groups/{groupName}
Produces: application/text
Sample Usage:

DELETE /api/security/groups/dev-leads
Group 'dev-leads' has been removed successfully.

Get Permission Targets
Description: Get the permission targets list
Since: 2.4.0
Notes: Requires Artifactory Pro
Security: Requires an admin user
Usage: GET /api/security/permissions
Produces: application/vnd.org.jfrog.artifactory.security.Users+json, application/vnd.org.jfrog.artifactory.security.Groups+json, application/vnd.org.j
frog.artifactory.security.PermissionTargets+json
Sample Output:

GET /api/security/permissions
[
{
"name": "readSourceArtifacts"
"uri" :
"http://localhost:8081/artifactory/api/security/permissions/readSourceArti
facts"
}, {
"name": "populateCaches"
"uri" :
"http://localhost:8081/artifactory/api/security/permissions/populateCaches"
}
]

Get Permission Target Details
Description: Get the details of an Artifactory Permission Target
Since: 2.4.0
Notes: Requires Artifactory Pro
Security: Requires an admin user
Usage: GET /api/security/permissions/{permissionTargetName}
Produces: application/vnd.org.jfrog.artifactory.security.PermissionTarget+json
Sample Output:

GET /api/security/permissions/populateCaches
{
permission-target.json
}

Create or Replace Permission Target
Description: Creates a new permission target in Artifactory or replaces an existing permission target
Since: 2.4.0
Notes: Requires Artifactory Pro
Missing values will be set to the default values as defined by the consumed type.
Security: Requires an admin user
Usage: PUT /api/security/permissions/{permissionTargetName}

Consumes: application/vnd.org.jfrog.artifactory.security.PermissionTarget+json
Sample Usage:

PUT /api/security/permissions/populateCaches
{
permission-target.json
}

Delete Permission Target
Description: Deletes an Artifactory permission target.
Since: 2.4.0
Notes: Requires Artifactory Pro
Security: Requires an admin user
Usage: DELETE /api/security/permissions/{permissionTargetName}
Produces: application/text
Sample usage:

DELETE /api/security/permissions/populateCaches
Permission Target 'remoteCachePopulation' has been removed successfully.

Effective Item Permissions
Description: Returns a list of effective permissions for the specified item (file or folder).
Only users and groups with some permissions on the item are returned. Supported by local and local-cached repositories.
Permissions are returned according to the following conventions:
m=admin; d=delete; w=deploy; n=annotate; r=read
Notes: Requires Artifactory Pro
Since: 2.3.4
Security: Requires a valid admin or local admin user.
Usage: GET /api/storage/{repoKey}/{itemPath}?permissions
Produces: application/vnd.org.jfrog.artifactory.storage.ItemPermissions+json
Sample Output:

GET /api/storage/libs-release-local/org/acme?permissions
{
"uri":
"http://localhost:8081/artifactory/api/storage/libs-release-local/org/acme"
"principals": {
"users" : {
"bob": ["r","w","m"],
"alice" : ["d","w","n", "r"]
},
"groups" : {
"dev-leads" : ["m","r","n"],
"readers" : ["r"]
}
}
}

Security Configuration

Description: Retrieve the security configuration (security.xml).
Since: 2.2.0
Notes: This is an advanced feature - make sure the new configuration is really what you wanted before saving.
Security: Requires a valid admin user
Usage: GET /api/system/security
Produces: application/xml
Sample Output:

GET /api/system/security

Save Security Configuration (Deprecated)
Description: Save the security configuration (security.xml). Requires the security.xml file from the same version.
Since: 2.2.0
Notes: This API is deprecated.
Security: Requires a valid admin user
Usage: POST /api/system/security
Consumes: application/xml
Sample Usage:

POST /api/system/security

Activate Master Key Encryption
Description: Creates a new master key and activates master key encryption.
Since: 3.2.2
Notes: This is an advanced feature intended for administrators
Security: Requires a valid admin user
Usage: POST /api/system/encrypt
Produces: text/plain
Sample Usage:

POST /api/system/encrypt
DONE

Deactivate Master Key Encryption
Description: Removes the current master key and deactivates master key encryption.
Since: 3.2.2
Notes: This is an advanced feature intended for administrators
Security: Requires a valid admin user
Usage: POST /api/system/decrypt
Produces: text/plain
Sample Usage:

POST /api/system/decrypt
DONE

Set GPG Public Key
Description: Sets the public key that Artifactory provides to Debian and Opkg clients to verify packages
Security: Requires a valid admin user
Usage: PUT /api/gpg/key/public
Produces: text/plain
Since: 3.3
Sample Usage:

PUT /api/gpg/key/public

Get GPG Public Key
Description: Gets the public key that Artifactory provides to Debian and Opkg clients to verify packages
Security: Requires an authenticated user, or anonymous (if "Anonymous Access" is globally enabled)
Usage: GET /api/gpg/key/public
Produces: text/plain
Since: 3.3
Sample Usage:

GET /api/gpg/key/public

Set GPG Private Key
Description: Sets the private key that Artifactory will use to sign Debian and ipk packages
Security: Requires a valid admin user
Usage: PUT /api/gpg/key/private
Produces: text/plain
Since: 3.3
Sample Usage:

PUT /api/gpg/key/private

Set GPG Pass Phrase
Description: Sets the pass phrase required signing Debian and ipk packages using the private key
Security: Requires a valid admin user
Usage: PUT /api/gpg/key/passphrase
Headers: -H X-GPG-PASSPHRASE:passphrase
Produces: text/plain
Since: 3.3
Sample Usage:

PUT /api/gpg/key/passphrase

Create Token
Description: Creates an access token
Since: 5.0.0
Security: Requires a valid user
Usage: POST /api/security/token
Content-Type: application/x-www-form-urlencoded
Produces: application/json

{
"access_token":
"expires_in":
"scope":
"token_type":
"refresh_token":

"",
,
"",
"Bearer",
""

}

Sample Usage:

curl -uadmin:password -XPOST
"http://localhost:8081/artifactory/api/security/token" -d "username=johnq"
-d "scope=member-of-groups:readers"
200
{
"access_token":
"expires_in":
"scope":
"token_type":
"refresh_token":

"adsdgbtybbeeyh...",
3600,
"api:* member-of-groups:readers",
"Bearer",
"fgsfgsdugh8dgu9s8gy9hsg..."

}

This endpoint takes the following parameters:
[Optional, default: "client_credentials"]
grant_type

username

The grant type used to authenticate the request. In this case, the only value supported is "client_credentials" which is also the
default value if this parameter is not specified.
The user name for which this token is created. If the user does not exist, a transient user is created. Non-admin users can only
create tokens for themselves so they must specify their own username.
If the user does not exist, the member-of-groups scope token must be provided (e.g. member-of-groups: g1, g2,
g3...)
[Optional if the user specified in username exists]

scope

The scope to assign to the token provided as a space-separated list of scope tokens. Currently there are three possible scope
tokens:
"api:*" - indicates that the token grants access to REST API calls. This is always granted by default whether specified in the
call or not.
member-of-groups:[] - indicates the groups that the token is associated with (e.g. member-of-groups:
g1, g2, g3...). The token grants access according to the permission targets specified for the groups listed.
Specify "*" for group-name to indicate that the token should provide the same access privileges that are given to the group
of which the logged in user is a member.
A non-admin user can only provide a scope that is a subset of the groups to which he belongs
"jfrt@:admin" - provides admin privileges on the specified Artifactory instance. This is only available for
administrators.
If omitted and the username specified exists, the token is granted the scope of that user.
[Optional, default: 3600]

expires_in

The time in seconds for which the token will be valid. To specify a token that never expires, set to zero. Non-admin can only set
a value that is equal to or less than the default 3600.

[Optional, default: false]
refreshable

If true, this token is refreshable and the refresh token can be used to replace it with a new token once it expires.
[Optional, default: Only the service ID of the Artifactory instance that created the token]

audience

A space-separate list of the other Artifactory instances or services that should accept this token identified by their Artifactory
Service IDs as obtained from the Get Service ID endpoint.
In case you want the token to be accepted by all Artifactory instances you may use the following audience parameter
"audience=jfrt@*".

Refresh Token
Description: Refresh an access token to extend its validity. If only the access token and the refresh token are provided (and no other
parameters), this pair is used for authentication. If username or any other parameter is provided, then the request must be authenticated by a
token that grants admin permissions.
Since: 5.0.0
Security: Requires a valid user (unless both access token and refresh token are provided)
Usage: POST /api/security/token
Content-Type: application/x-www-form-urlencoded
Produces: application/json (Please refer to Create Token)
Sample Usage:

curl -XPOST "http://localhost:8081/artifactory/api/security/token" -d
"grant_type=refresh_token" -d "refresh_token=fgsg53t3g…" -d
"access_token=gsfdgw35gt..."
200 (Success) As in Create Token
400 (Error) If the token was created by a different Artifactory instance
(and hence cannot be refreshed)

This endpoint takes the following parameters:
Should be set to refresh_token.
grant_type

The refresh token of the access token that needs to be refreshed.
refresh_token

The access token to refresh.
access_token

Please refer to Create Token.
username

Note: access_token and username are mutually exclusive, so only one of these parameters should be specified.
If access_token is provided, the new token is created with the same settings as that token.

scope

expires_in

refreshable

audience

Revoke Token
Description: Revoke an access token
Since: 5.0.0
Security: Requires a valid user
Usage: POST /api/security/token/revoke
Content-Type: application/x-www-form-urlencoded
Produces: application/json
Sample Usage:

curl -uadmin:password -XPOST
"http://localhost:8081/artifactory/api/security/token/revoke" -d
"token=fasdt3..."
200 OK (Also returned if the token was already revoked or non-existent)
400 (Error) If the token was created by a different Artifactory instance
(and hence cannot be revoked)

This endpoint takes the following parameters:
The token to be revoked
token

Get Service ID
Description: Provides the service ID of an Artifactory instance or cluster. Up to version 5.5.1, the Artiafctory service ID is formatted jf-artifac
tory@. From version 5.5.2 the service ID is formatted jfrt@.
Since: 5.0.0
Security: Requires an admin user
Usage: GET /api/system/service_id
Produces: text/plain
Sample Usage:

curl -uadmin:password -XGET
"http://localhost:8081/artifactory/api/system/service_id"
200
jfrt@ee27b1d1-534d-4723-80b5-5bd893d19c43

Get Certificates
Description: Returns a list of installed SSL certificates.
Since:5.4.0
Security: Requires an admin user
Usage: GET /api/system/security/certificates
Produces: application/json

[
{
"certificateAlias" : "",
"issuedTo" : "",
"issuedBy" : "",
"issuedOn" : "",
"validUntil" : "",
"fingerPrint" : ""
}
]

Sample Usage:

GET /api/system/security/certificates
[
{
"certificateAlias" : "example1",
"issuedTo" : "JFrog",
"issuedBy" : "Some_CA",
"issuedOn" : "Sun May 01 2017 10:00:00 GMT +02:00 (UTC)",
"validUntil" : "Sun May 01 2019 10:00:00 GMT +02:00 (UTC)",
"fingerPrint" : "ab:cd:ef:gh"
},
{
"certificateAlias" : "example2",
"issuedTo" : "Cool-Company",
"issuedBy" : "Some_Other_CA",
"issuedOn" : "Sun May 01 2017 10:00:00 GMT +02:00 (UTC)",
"validUntil" : "Sun May 01 2019 10:00:00 GMT +02:00 (UTC)",
"fingerPrint" : "ab:cd:ef:gh"
}
]

Add Certificate
Description: Adds an SSL certificate.
Since:5.4.0
Security: Requires an admin user
Usage: POST /api/system/security/certificates/{Certificate_alias} -T {Certificate PEM file}
Consumes: application/text
Produces: application/json

{
}

"status" : 200,
"message" : ["The certificates were successfully installed"]

Delete Certificate
Description: Deletes an SSL certificate.
Since:5.4.0
Security: Requires an admin user
Usage: DELETE /api/system/security/certificates/{Certificate_alias}
Produces: application/json
Sample Usage:

DELETE /api/security/certificates/cert1
Response:
{
"status" : 200,
"message" : "The certificates were successfully deleted"
}

REPOSITORIES
Get Repositories
Description: Returns a list of minimal repository details for all repositories of the specified type.
Since: 2.2.0
Security: Requires a privileged user (can be anonymous)
Usage: GET /api/repositories[?type=repositoryType (local|remote|virtual|distribution)]
Produces: application/vnd.org.jfrog.artifactory.repositories.RepositoryDetailsList+json
Sample Output:

GET /api/repositories
[
{
"key" : "libs-releases-local",
"type" : "LOCAL",
"description" : "Local repository for in-house libraries",
"url" : "http://localhost:8081/artifactory/libs-releases-local"
}, {
"key" : "libs-snapshots-local",
"type" : "LOCAL",
"description" : "Local repository for in-house snapshots",
"url" : "http://localhost:8081/artifactory/libs-snapshots-local"
}
]

Repository Configuration
Description: Retrieves the current configuration of a repository. Supported by local, remote and virtual repositories.
Since: 2.3.0
Notes: Requires Artifactory Pro
Security: Requires an admin user for complete repository configuration. Non-admin users will receive only partial configuration data.
Usage: GET /api/repositories/{repoKey}
Produces: application/vnd.org.jfrog.artifactory.repositories.LocalRepositoryConfiguration+json, application/vnd.org.jfrog.artifactory.repositories.R
emoteRepositoryConfiguration+json,
application/vnd.org.jfrog.artifactory.repositories.VirtualRepositoryConfiguration+json

Sample Output:

GET /api/repositories/libs-release-local
{
repository-config.json
}

Create Repository
Description: Creates a new repository in Artifactory with the provided configuration. Supported by local, remote and virtual repositories.
Since: 2.3.0
Notes: Requires Artifactory Pro
An existing repository with the same key are removed from the configuration and its content is removed!
Missing values are set to the default values as defined by the consumed type spec.
Security: Requires an admin user
Usage: PUT /api/repositories/{repoKey}
Consumes: application/vnd.org.jfrog.artifactory.repositories.LocalRepositoryConfiguration+json, application/vnd.org.jfrog.artifactory.repositories.
RemoteRepositoryConfiguration+json,
application/vnd.org.jfrog.artifactory.repositories.VirtualRepositoryConfiguration+json
Sample Usage:

PUT /api/repositories/libs-release-local
{
repository-config.json
}

Update Repository Configuration
Description: Updates an exiting repository configuration in Artifactory with the provided configuration elements. Supported by local, remote and
virtual repositories.
Since: 2.3.0
Notes: Requires Artifactory Pro
The class of a repository (the rclass attribute cannot be updated.
Security: Requires an admin user
Usage: POST /api/repositories/{repoKey} -H "Content-Type: application/json"
Consumes: application/vnd.org.jfrog.artifactory.repositories.LocalRepositoryConfiguration+json, application/vnd.org.jfrog.artifactory.repositories.
RemoteRepositoryConfiguration+json,
application/vnd.org.jfrog.artifactory.repositories.VirtualRepositoryConfiguration+json
Sample Usage:

POST /api/repositories/libs-release-local -H "Content-Type:
application/json"
{
repository-config.json
}

Delete Repository
Description: Removes a repository configuration together with the whole repository content. Supported by local, remote and virtual repositories.
Since: 2.3.0
Notes: Requires Artifactory Pro
Security: Requires an admin user
Usage: DELETE /api/repositories/{repoKey}
Produces: application/text
Sample Usage:

DELETE /api/repositories/libs-release-local
Repository 'libs-release-local' and all its content have been removed
successfully.

Remote Repository Configuration (Deprecated)
Description: Repository Configuration (Deprecated)
Gets the shared configuration of a remote repository.
Since: 2.2.0
Notes: This API is deprecated. Use the Get Repository Configuration API instead.
Security: Requires a valid user for a shared remote repository and admin user for anything else. Shared remote repository data will be sanitized
for security when non-admin user is used.
Usage: GET /api/repositories/{remoteRepoName}/configuration
Produces: application/vnd.org.jfrog.artifactory.repositories.SharedRemoteRepositoryConfiguration+json
Sample Output:

GET /api/repositories/remote-repo/configuration
{
repository-config.json
}

Calculate YUM Repository Metadata
Description: For Local repositories: calculates/recalculates the YUM metdata for this repository, based on the RPM package currently hosted in
the repository. Supported by local and virtual repositories only.
Calculation can be synchronous (the default) or asynchronous.
For Virtual repositories, calculates the merged metadata from all aggregated repositories on the specified path. The path parameter must be
passed for virtual calculation.
Please see the YUM integration documentation for more details.
Notes: Requires Artifactory Pro. Immediate calculation requests cannot be called on repositories with automatic asynchronous calculations
enabled (applies to local repositories only). The path parameter applies to virtual repositories only.
Security: Up to version 4.8 , requires a valid admin user. From version 4.8 only requires the set of permissions assumed by Manage (Manage +
Delete/Overwrite + Deploy/Cache + Annotate + Read).
Usage: POST /api/yum/{repoKey}[?path={path to repodata dir][&async=0/1]
Headers (Optionally): -H X-GPG-PASSPHRASE:passphrase
Produces: application/text
Since: 2.3.5
Sample Output:

POST /api/yum/yum-local?async=1
POST /api/yum/yum-virtual?path=7/os/x86_64&async=1
YUM metadata calculation for repository 'yum-local' accepted.

Calculate NuGet Repository Metadata
Description: Recalculates all the NuGet packages for this repository (local/cache/virtual), and re-annotate the NuGet properties for each NuGet
package according to it's internal nuspec file.
Please see the NuGet integration documentation for more details.
Supported by local, local-cache, remote and virtual repositories.
Notes: Requires Artifactory Pro.
Security: Up to version 4.8 , requires a valid admin user. From version 4.8 only requires the set of permissions assumed by Manage (Manage +
Delete/Overwrite + Deploy/Cache + Annotate + Read).

Usage: POST /api/nuget/{repoKey}/reindex
Produces: application/text
Since: 3.0.3
Sample Output:

POST /api/nuget/nuget-local/reindex
NuGet reindex calculation for repository 'nuget-local' accepted.

Calculate Npm Repository Metadata
Description: Recalculates the npm search index for this repository (local/virtual). Please see the Npm integration documentation for more
details. Supported by local and virtual repositories.
Notes: Requires Artifactory Pro.
Security: Up to version 4.8 , requires a valid admin user. From version 4.8 only requires the set of permissions assumed by Manage (Manage +
Delete/Overwrite + Deploy/Cache + Annotate + Read).
Usage: POST /api/npm/{repoKey}/reindex
Produces: application/text
Since: 3.2.0
Sample Output:

POST /api/npm/npm-local/reindex
Recalculating index for npm repository npm-local scheduled to run

Calculate Maven Index
Description: Calculates/caches a Maven index for the specified repositories.
For a virtual repository specify all underlying repositories that you want the aggregated index to include.
Calculation can be forced, which for remote repositories will cause downloading of a remote index even if a locally cached index has not yet
expired; and index recalculation based on the cache on any failure to download the remote index, including communication errors (the default
behavior is to only use the cache when a remote index cannot be found and returns a 404). Forcing has no effect on local repositories index
calculation.
Please see the Exposing Maven Indexes documentation for more details.
Notes: Requires Artifactory Pro.
Security: Up to version 4.8 , requires a valid admin user. From version 4.8 only requires the set of permissions assumed by Manage (Manage +
Delete/Overwrite + Deploy/Cache + Annotate + Read).
Usage: POST /api/maven[?repos=x[,y]][&force=0/1]
Produces: application/text
Since: 2.5.0
Sample Output:

POST /api/maven?repos=libs-release-local,ext-release-local&force=1
Maven index refresh for repositories '[libs-release-local,
ext-release-local]' has been accepted.

Calculate Maven Metadata
Description: Calculates Maven metadata on the specified path (local repositories only).
Security: Up to version 4.8 , requires a valid admin user. From version 4.8 only requires the set of permissions assumed by Manage (Manage +
Delete/Overwrite + Deploy/Cache + Annotate + Read).
Usage: POST /api/maven/calculateMetadata/{repoKey}/{folder-path}?{nonRecursive=true | false}
Produces: application/text
Since: 3.0.2
Sample Output:

POST /api/maven/calculateMetadata/libs-release-local/org/acme
OK

Calculate Debian Repository Metadata
Description: Calculates/recalculates the Packages and Release metadata for this repository,based on the Debian packages in it.
Calculation can be synchronous (the default) or asynchronous. Please refer to Debian Repositories for more details. Supported by local
repositories only.
From version 4.4, by default, the recalculation process also writes several entries from the Debian package's metadata as properties on all of the
artifacts (based on the control file's content).
This operation may not always be required (for example, if the Debian files are intact and were not modified, only the index needs to be
recalculated. The operation is resource intensive and can be disabled by passing the ?writeProps=0 query param.
Notes: Requires Artifactory Pro.
Security: Up to version 4.8 , requires a valid admin user. From version 4.8 only requires the set of permissions assumed by Manage (Manage +
Delete/Overwrite + Deploy/Cache + Annotate + Read).
Usage: POST api/deb/reindex/{repoKey} [?async=0/1][?writeProps=0/1]
Headers (Optionally): -H X-GPG-PASSPHRASE:passphrase
Produces: application/text
Since: 3.3
Sample Output:

POST /api/deb/reindex/debian-local
Recalculating index for Debian repository debian-local scheduled to run.

Calculate Opkg Repository Metadata
Description: Calculates/recalculates the Packages and Release metadata for this repository,based on the ipk packages in it (in each feed
location).
Calculation can be synchronous (the default) or asynchronous. Please refer to Opkg Repositories for more details. Supported by local repositories
only.
By default, the recalculation process also writes several entries from the ipk package's metadata as properties on all of the artifacts (based on the
control file's content).
This operation may not always be required (for example, if the ipk files are intact and were not modified, only the index needs to be recalculated.
The operation is resource intensive and can be disabled by passing the ?writeProps=0 query param.
Notes: Requires Artifactory Pro.
Security: Up to version 4.8 , requires a valid admin user. From version 4.8 only requires the set of permissions assumed by Manage (Manage +
Delete/Overwrite + Deploy/Cache + Annotate + Read).
Usage: POST api/opkg/reindex/{repoKey} [?async=0/1][?writeProps=0/1]
Headers (Optionally): -H X-GPG-PASSPHRASE:passphrase
Produces: application/text
Since: 4.4
Sample Output:

POST /api/opkg/reindex/opkg-local
Recalculating index for Opkg repository opkg-local scheduled to run.

Calculate Bower Index
Description: Recalculates the index for a Bower repository.
Notes: Requires Artifactory Pro.
Security: Up to version 4.8 , requires a valid admin user. From version 4.8 only requires the set of permissions assumed by Manage (Manage +
Delete/Overwrite + Deploy/Cache + Annotate + Read).
Usage: POST api/bower/{repoKey}/reindex
Produces: application/text

Since: 3.6.0
Sample Output:

POST /api/bower/bower-local/reindex
Bower index for refresh for bower-local has been accepted

SYSTEM & CONFIGURATION
System Info
Description: System Info
Get general system information.
Since: 2.2.0
Security: Requires a valid admin user
Usage: GET /api/system
Produces: text/plain
Sample Output:

GET /api/system
system info output text

System Health Ping
Description: Get a simple status response about the state of Artifactory
Returns 200 code with an 'OK' text if Artifactory is working properly, if not will return an HTTP error code with a reason.
Since: 2.3.0
Security: Requires a valid user (can be anonymous). If artifactory.ping.allowUnauthenticated=true is set in artifactory.system.properties, then no
authentication is required even if anonymous access is disabled.
Usage: GET /api/system/ping
Produces: text/plain
Sample Output:

GET /api/system/ping
OK

Verify Connection
Description: Verifies a two-way connection between Artifactory and another product
Returns Success (200) if Artifactory receives a similar success code (200) from the provided endpoint. See possible error codes below.
Since: 4.15.0
Security: Requires an admin user.
Usage: POST/api/system/verifyconnection
Consumes: application/json

POST
{
+
}

/api/system/verifyconnection
"endpoint" : "",
"username" : "",
"password" : ""

Produces: application/json

Upon success (200):
200 Successfully connected to endpoint
Upon error, returns 400 along with a JSON object that contains the error
returned from the other system.

Sample Output:

{
"errors" : [ {
"status" : 400,
"message" : "Received error from endpoint url: HTTP 404: Page not
found"
} ]
}

General Configuration
Description: Get the general configuration (artifactory.config.xml).
Since: 2.2.0
Security: Requires a valid admin user
Usage: GET /api/system/configuration
Produces: application/xml (http://www.jfrog.org/xsd/artifactory-v1_7_3.xsd)
Sample Output:

GET /api/system/configuration

Save General Configuration
Description: Save the general configuration (artifactory.config.xml).
Since: 2.2.0
Notes: This is an advanced feature - make sure the new configuration is really what you wanted before saving.
Security: Requires a valid admin user
Usage: POST /api/system/configuration
Consumes: application/xml (http://www.jfrog.org/xsd/artifactory-v1_7_3.xsd)
Sample Usage:

POST /api/system/configuration

Update Custom URL Base
Description: Changes the Custom URL base
Since: 3.9.0
Security: Requires a valid admin user
Usage: PUT /api/system/configuration/baseUrl
Example: curl -X PUT "http://localhost:8081/artifactory/api/system/configuration/baseUrl" -d 'https://mycompany.com:444/artifactory'
-uadmin:password -H "Content-type: text/plain"
Sample Output:

URL base has been successfully updated to
"https://mycompany.com:444/artifactory".

License Information
Description: Retrieve information about the currently installed license.
Since: 3.3.0
Security: Requires a valid admin user
Usage: GET /api/system/license
Produces: application/json
Sample Output:
GET /api/system/license
{
"type" : "Commercial",
"validThrough" : "May 15, 2014",
"licensedTo" : "JFrog inc."
}

Install License
Description: Install new license key or change the current one.
Since: 3.3.0
Security: Requires a valid admin user
Usage: POST /api/system/license
Produces: application/json
Consumes: application/json ( { "licenseKey": "your supplied license key ..." } )
Sample Output:
POST /api/system/license
{
"status" : 200,
"message" : "The license has been successfully installed."
}

HA License Information
Description: Retrieve information about the currently installed licenses in an HA cluster.
Since: 5.0.0
Security: Requires a valid admin user
Usage: GET /api/system/licenses
Produces: application/json

[ {
"type" : "Enterprise",
"validThrough" : "",
"licensedTo" : "",
"licenseHash" : "",
"nodeId" : "",
"nodeUrl" : "",
"expired" :
}]

Sample Output:

GET /api/system/licenses
[ {
"type" : "Enterprise",
"validThrough" : "May 15, 2018",
"licensedTo" : "JFrog",
"licenseHash" : "179b7ea384d0c4655a00dfac7285a21d986a17923",
"nodeId" : "art1",
"nodeUrl" : "http://10.1.16.83:8091/artifactory",
"expired" : false
}, {
"type" : "Enterprise",
"validThrough" : "May 15, 2018",
"licensedTo" : "JFrog",
"licenseHash" : "e10b8aa1d1dc5107439ce43debc6e65dfeb71afd3",
"nodeId" : "Not in use",
"nodeUrl" : "Not in use",
"expired" : false
} ]

Install HA Cluster Licenses
Description: Install a new license key(s) on an HA cluster.
Since: 5.0.0
Security: Requires an admin user
Usage: POST /api/system/licenses
Consumes: application/json

[{
"licenseKey": ""
}]

Produces: application/json

{
"status" : 200,
"messages" : {
["" : ""]
}

Sample Usage:

POST /api/system/licenses
[
{
"licenseKey": "tL9r2Y...lDBiktbbt"
},
{
"licenseKey": DiYgVA...P7nvyNI7q"
}
]
Response:
{
"status" : 200,
"messages" : {
"tL9r2Y...lDBiktbbt" : "OK",
"DiYgVA...P7nvyNI7q" : "OK",
}

Delete HA Cluster License
Description: Deletes a license key from an HA cluster.
Since: 5.0.0
Security: Requires an admin user
Usage: DELETE /api/system/licenses?licenseHash=licenseHash1, licenseHash2...
Produces: application/json

{
"status" : 200,
"messages" : {["" : ""]}
}

Sample Usage:

DELETE /api/system/licenses?licenseHash=tL9r2YlDBiktbbt, DiYgVAP7nvyNI7q
Response:
{
"status" : 200,
"messages" : {
"tL9r2YlDBiktbbt" : "OK",
"DiYgVAP7nvyNI7q" : "OK"
}
}

Version and Add-ons information
Description: Retrieve information about the current Artifactory version, revision, and currently installed Add-ons
Since: 2.2.2
Security: Requires a valid user (can be anonymous)
Usage: GET /api/system/version
Produces: application/vnd.org.jfrog.artifactory.system.Version+json
Sample Output:

GET /api/system/version
{
"version" : "2.2.2",
"revision" : "10427",
"addons" : [ "build", "ldap", "properties", "rest", "search", "sso",
"watch", "webstart" ]
}

Get Reverse Proxy Configuration
Description: Retrieves the reverse proxy configuration
Since: 4.3.1
Security: Requires a valid admin user
Usage: GET /api/system/configuration/webServer
Produces: application/json
Sample Output:

GET /api/system/configuration/webServer
{
"key" : "nginx",
"webServerType" : "NGINX",
"artifactoryAppContext" : "artifactory",
"publicAppContext" : "artifactory",
"serverName" : "jfrog.com",
"serverNameExpression" : "*.jfrog.com",
"artifactoryServerName" : "localhost",
"artifactoryPort" : 8081,
"sslCertificate" : "/etc/ssl/myKey.cert",
"sslKey" : "/etc/ssl/myKey.key",
"dockerReverseProxyMethod" : "SUBDOMAIN",
"useHttps" : true,
"useHttp" : true,
"sslPort" : 443,
"httpPort" : 76
}

Update Reverse Proxy Configuration
Description: Updates the reverse proxy configuration
Since: 4.3.1
Security: Requires an admin user
Usage: POST /api/system/configuration/webServer
Consumes: application/json
Sample Usage:

POST /api/system/configuration/webServer
{
"key" : "nginx",
"webServerType" : "NGINX",
"artifactoryAppContext" : "artifactory",
"publicAppContext" : "artifactory",
"serverName" : "jfrog.com",
"serverNameExpression" : "*.jfrog.com",
"artifactoryServerName" : "localhost",
"artifactoryPort" : 8081,
"sslCertificate" : "/etc/ssl/myKey.cert",
"sslKey" : "/etc/ssl/myKey.key",
"dockerReverseProxyMethod" : "SUBDOMAIN",
"useHttps" : true,
"useHttp" : true,
"sslPort" : 443,
"httpPort" : 76
}

Get Reverse Proxy Snippet
Description: Gets the reverse proxy configuration snippet in text format
Since: 4.3.1

Security: Requires a valid user (not anonymous)
Usage: GET /api/system/configuration/reverseProxy/nginx
Produces: text/plain
Sample Usage:

GET /api/system/configuration/reverseProxy/nginx
## add ssl entries when https has been set in config
ssl_certificate
/etc/ssl/myKey.cert;
ssl_certificate_key /etc/ssl/myKey.key;
ssl_session_cache shared:SSL:1m;
ssl_prefer_server_ciphers
on;
## server configuration
server {
listen 443 ssl;
listen 76 ;
server_name ~(?.+)\.jfrog.com jfrog.com;
if ($http_x_forwarded_proto = '') {
set $http_x_forwarded_proto $scheme;
}
## Application specific logs
## access_log /var/log/nginx/jfrog.com-access.log timing;
## error_log /var/log/nginx/jfrog.com-error.log;
rewrite ^/$ /artifactory/webapp/ redirect;
rewrite ^/artifactory$ /artifactory/webapp/ redirect;
}

Create Bootstrap Bundle
Description: This rest is relevant for High Availability set up. It will create a bootstrap bundle on the primary node of an Artifactory HA installation
that will include all the relevant keys so a new node can access the database and fetch all the relevant configuration files. The same bundle must
be installed on all nodes during an installation of new nodes or if upgrading from a version older than 5.0. For more details, please refer to Installin
g Artifactory HA.
Since: 5.0.0
Security: Requires an admin user
Usage: POST /api/system/bootstrap_bundle
Produces: application/json

{
"file" : ""
}

Sample usage:

POST /api/system/bootstrap_bundle
{
"file" : "/opt/jfrog/artifactory/etc/bootstrap.bundle.tar.gz"
}

PLUGINS
Execute Plugin Code
Description: Executes a named execution closure found in the executions section of a user plugin.
Execution can take parameters and be synchronous (the default) or asynchronous.
When parameters can have multiple values, you can separate the items in one of the following ways:
Use a semicolon - ; (recommended)
Use the encoding for the pipe ("|") character - %7C
Alternatively, you may configure your NGINX to encode URLs so that if an unencoded pipe is used in the URL, NGINX will encode it to
%7C. We recommend that you verify that this configuration does not break any other systems served by NGINX
Since: 2.3.1
Notes: Requires Artifactory Pro
Security: Requires an authenticated user (the plugin can control which users/groups are allowed to trigger it)
Usage: POST /api/plugins/execute/{executionName}?[params=p1=v1[,v2][|p2=v3][&async=1]]
Produces: text/plain
Sample Output:

POST
/api/plugins/execute/cleanup?params=suffix=SNAPSHOT;types=jar,war,zip&asyn
c=1
OK

Retrieve Plugin Code
Description: Retrieves the source code of the specified user plugin.
Since: 5.0.0
Notes: Requires Artifactory Pro
Security: Requires an admin user.
Usage: GET /api/plugins/download/{pluginName}
Produces: text/x-groovy-source
Sample Usage

GET /api/plugins/download/myPlugin
Response:

Retrieve Plugin Info
Description: Retrieves user plugin information for Executions and Staging plugins (subject to the permissions of the provided credentials).
Since: 2.5.2
Notes: Requires Artifactory Pro
Security: Requires an authenticated user.
Usage: GET /api/plugins
Produces: application/json
Sample Output:

GET /api/plugins
{
"executions": [
{
"name": "execution1",
"version": "version",
"description": "description",
"users": ["user1"],
"groups": ["group1", "group2"],
"params": {}
}
],
"staging": [
{
"name": "strategy1",
"version": "1.0",
"description": "desc",
"params": {"key1": "val1"}
}
]
}

Retrieve Plugin Info Of A Certain Type
Description: Retrieves all available user plugin information (subject to the permissions of the provided credentials) of the specified type.
Since: 2.5.2
Notes: Requires Artifactory Pro
Security: Requires an authenticated user.
Usage: GET /api/plugins/{pluginType}
Produces: application/json
Sample Output:

GET /api/plugins/staging
{
"staging": [
{
"name": "strategy1",
"version": "1.0",
"description": "desc",
"params": {"key1": "val1"}
}
]
}

Retrieve Build Staging Strategy
Description: Retrieves a build staging strategy defined by a user plugin.
When passing in parameters that may take multiple values, you can separate the items in one of the following ways:
Use a semicolon - ; (recommended)
Use the encoding for the pipe ("|") character - %7C

Alternatively, you may configure your NGINX to encode URLs so that if an unencoded pipe is used in the URL, NGINX will encode it to
%7C. We recommend that you verify that this configuration does not break any other systems served by NGINX
Since: 2.5.2
Notes: Requires Artifactory Pro
Security: Requires an authenticated user.
Usage: GET /api/plugins/build/staging/{strategyName}?buildName={buildName}&[params=p1=v1[,v2][|p2=v3]]
Produces: application/vnd.org.jfrog.plugins.BuildStagingStrategy
Sample Output:

GET
/api/plugins/build/staging/strategy1?buildName=build1¶ms=types=jar,war
,zip
{
"defaultModuleVersion":
{
"moduleId": "moduleId",
"nextRelease": "nextRelease",
"nextDevelopment": "nextDevelopment"
},
"vcsConfig":
{
"useReleaseBranch": true,
"releaseBranchName": "branchName",
"createTag": true,
"tagUrlOrName": "tagUrl",
"tagComment": "comment",
"nextDevelopmentVersionComment": "comment"
},
"promotionConfig":
{
"targetRepository": "repoKey",
"comment": "comment",
"status": "statusName"
}
}

Execute Build Promotion
Description: Executes a named promotion closure found in the promotions section of a user plugin.
Since: 2.5.2
Notes: Requires Artifactory Pro
Security: Requires an authenticated user.
Usage: POST /api/plugins/build/promote/{promotionName}/{buildName}/{buildNumber}?[params=p1=v1[,v2][|p2=v3]]
Produces: text/plain
Sample Output:

POST
/api/plugins/build/promote/promotion1/build1/3?params=types=jar,war,zip
OK

Reload Plugins
Description: Reloads user plugins if there are modifications since the last user plugins reload. Works regardless of the automatic user plugins

refresh interval.
Since: 2.9.0
Notes: Requires Artifactory Pro
Security: Requires a valid admin user
Usage: POST /api/plugins/reload
Produces: text/plain
Sample Output:

POST /api/plugins/reload
Successfully loaded: myplugin1.groovy, myplugin2.groovy

IMPORT & EXPORT
Import Repository Content
Description: Import one or more repositories.
Since: 2.2.2
Security: Requires a valid admin user
Usage: POST: /api/import/repositories
Requests Params:
path - The file system path to import from. This may point to a specific folder to import data for a single repository, or to the parent "repositories"
folder to import data for all repositories.
repo - Empty/null repo -> all
metadata - Include metadata - default 1
verbose - Verbose - default 0
Produces: text/plain
Sample Output:

POST: /api/import/repositories?path=pathToRepos&verbose=1

Import System Settings Example
Description: Returned default Import Settings JSON.
Since: 2.4.0
Security: Requires a valid admin user
Usage: GET: /api/import/system
Produces: application/vnd.org.jfrog.artifactory.system.ImportSettings+json
Sample Usage:

GET /api/import/system
{
"importPath" : "/import/path",
"includeMetadata" : true,
"verbose" : false,
"failOnError" : true,
"failIfEmpty" : true
}

Full System Import
Description: Import full system from a server local Artifactory export directory.
Since: 2.4.0

Security: Requires a valid admin user
Usage: POST: /api/import/system
Consumes : application/vnd.org.jfrog.artifactory.system.ImportSettings+json
Produces: text/plain
Sample Usage:

POST /api/import/system
{
import-settings.json
}

Export System Settings Example
Description: Returned default Export Settings JSON.
Since: 2.4.0
Security: Requires a valid admin user
Usage: GET: /api/export/system
Produces: application/vnd.org.jfrog.artifactory.system.ExportSettings+json
Sample Usage:

GET /api/export/system
{
"exportPath" : "/export/path",
"includeMetadata" : true,
"createArchive" : false,
"bypassFiltering" : false,
"verbose" : false,
"failOnError" : true,
"failIfEmpty" : true,
"m2" : false,
"incremental" : false,
"excludeContent" : false
}

Export System
Description: Export full system to a server local directory.
Since: 2.4.0
Security: Requires a valid admin user
Usage: POST: /api/export/system
Consumes : application/vnd.org.jfrog.artifactory.system.ExportSettings+json, application/json
Produces: text/plain
Sample Usage:

POST /api/export/system{ export-settings.json }

SUPPORT
Create Bundle
Description: Create a new support bundle.
Since: 4.3.0

Security: Requires an admin user
Notes: All bundle items are optional.
Usage: POST /api/support/bundles/
Sample Usage:

POST /api/support/bundles
{
- "systemLogsConfiguration" : {
"enabled" : true,(default)
"startDate" : {date-in-millis},
"endDate" : {date-in-millis}
},
- "systemInfoConfiguration" : {
"enabled" : true (default)
},
- "securityInfoConfiguration" : {
"enabled" : true, (default)
"hideUserDetails" : true (default)
},
- "configDescriptorConfiguration" : {
"enabled" : true, (default)
"hideUserDetails" : true (default)
},
- "configFilesConfiguration" : {
"enabled" : true (default),
"hideUserDetails" : true (default)
},
- "storageSummaryConfiguration" : {
"enabled" : true (default)
},
- "threadDumpConfiguration" : {
"enabled" : true, (default)
"count" : {amount-of-dumps},
(1 is default)
"interval" : {interval in millis} (0 is default)
}
}
NOTE: systemLogsConfiguration parameter can also be expressed as number of
days as follows:
...
- "systemLogsConfiguration" : {
"enabled" : true,(default)
"daysCount" : {number-of-days}
},
...

{
"bundles" : [
"/api/support/bundles/support-bundle-20151118-1709272-1447859367247.zip"
]
}

List Bundles

Description: Lists previously created bundle currently stored in the system.
Since: 4.3.0
Security: Requires a privileged user (Admin only)
Usage: GET /api/support/bundles/
Produces: application/json
Sample Usage:

GET /api/support/bundles
{
"bundles" : [
"/api/support/bundles/support-bundle-20151118-1709272-1447859367247.zip",
"/api/support/bundles/support-bundle-20151117-1035500-1447749350025.zip",
"/api/support/bundles/support-bundle-20151117-1035147-1447749314704.zip"
]
}

Get Bundle
Description: Downloads a previously created bundle currently stored in the system.
Since: 4.3.0
Security: Requires a privileged user (Admin only)
Usage: GET /api/support/bundles/{bundle-name}
Produces: application/json
Sample Usage:

GET /api/support/bundles/support-bundle-20151122-1705472-1448211947280.zip

Delete Bundle
Description: Deletes a previously created bundle from the system.
Since: 4.3.0
Security: Requires a privileged user (Admin only)
Usage: DELETE /api/support/bundles/{bundle-name}
Produces: application/json
Sample Usage:

DELETE
/api/support/bundles/support-bundle-20151122-1705472-1448211947280.zip

ERROR RESPONSES
In case of an error, Artifactory will return an error response in JSON format. The response contains the HTTP status code and error message.
For example, a badly formatted API call would return the "404, File not found" response below:

{
"errors" : [ {
"status" : 404,
"message" : "File not found."
} ]
}

Sample input:

POST /api/security/apiKey
{
"apiKey": "3OloposOtVFyCMrT+cXmCAScmVMPrSYXkWIjiyDCXsY="
}

PUT /api/storage/libs-release-local/ch/qos/logback/logback-classic/0.9.9?properties=os=win,linux;qa=done&
recursive=1

When parameters can have multiple values, you can separate the items in one of the following ways:
Use a semicolon - ; (recommended)
Use the encoding for the pipe ("|") character - %7C
Alternatively, you may configure your NGINX to encode URLs so that if an unencoded pipe is used in the URL, NGINX will encode it to
%7C. We recommend that you verify that this configuration does not break any other systems served by NGINX

Repository Configuration JSON
Repository Configuration JSON
Legend
+

Mandatory element in create/replace queries
(optional in "update" queries)

Optional element in create/replace queries

(default)

The default value when unspecified in
create/replace queries

Page Contents
Repository
Configuration
JSON
Local
Repository
applic
ation/v
nd.org.
jfrog.ar
tifactor
y.repo
sitorie
s.Loca
lRepos
itoryC
onfigur
ation+j
son
Remote
Repository
applic
ation/v
nd.org.
jfrog.ar
tifactor
y.repo
sitorie
s.Rem
oteRe
positor
yConfi
guratio
n+json
Virtual
Repository
applic
ation/v
nd.org.
jfrog.ar
tifactor
y.repo
sitorie
s.Virtu
alRep
ository
Config
uration
+json

Local Repository
application/vnd.org.jfrog.artifactory.repositories.LocalRepositoryConfiguration+json

{
- "key": "local-repo1",
+ "rclass" : "local",
- "packageType": "maven" | "gradle" | "ivy" | "sbt" | "nuget" | "gems"
| "npm" | "bower" | "debian" | "composer" | "pypi" | "docker" |
"vagrant" | "gitlfs" | "yum" | "conan" | "chef" | "puppet" | "generic"
(default)
- "description": "The local repository public description",
- "notes": "Some internal notes",
- "includesPattern": "**/*" (default),
- "excludesPattern": "" (default),
- "repoLayoutRef" : "maven-2-default",
- "debianTrivialLayout" : false,
- "checksumPolicyType": "client-checksums" (default) |
"server-generated-checksums"
- "handleReleases": true (default),
- "handleSnapshots": true (default),
- "maxUniqueSnapshots": 0 (default),
- "maxUniqueTags": 0 (default)
- "snapshotVersionBehavior": "unique" | "non-unique" (default) |
"deployer",
- "suppressPomConsistencyChecks": false (default),
- "blackedOut": false (default),
- "propertySets": ["ps1", "ps2"],
- "archiveBrowsingEnabled" : false,
- "calculateYumMetadata" : false,
- "yumRootDepth" : 0,
- "dockerApiVersion" : "V2" (default),
- "enableFileListsIndexing " : "false" (default)
}

Remote Repository
application/vnd.org.jfrog.artifactory.repositories.RemoteRepositoryConfiguration+json

{
- "key": "remote-repo1",
+ "rclass" : "remote",
- "packageType": "maven" | "gradle" | "ivy" | "sbt" | "nuget" | "gems"
| "npm" | "bower" | "debian" | "pypi" | "docker" | "yum" | "vcs" |
"composer" | "p2" | "chef" | "puppet" | "generic" (default)
+ "url" : "http://host:port/some-repo",
- "username": "remote-repo-user",
- "password": "pass",
- "proxy": "proxy1",
- "description": "The remote repository public description",
- "notes": "Some internal notes",
- "includesPattern": "**/*" (default),
- "excludesPattern": "" (default),
- "repoLayoutRef" : "maven-2-default",
- "remoteRepoChecksumPolicyType": "generate-if-absent" (default) |
"fail" | "ignore-and-generate" | "pass-thru",
- "handleReleases": true (default),
- "handleSnapshots": true (default),
- "maxUniqueSnapshots": 0 (default),
- "suppressPomConsistencyChecks": false (default),
- "hardFail": false (default),
- "offline": false (default),
- "blackedOut": false (default),
- "storeArtifactsLocally": true (default),
- "socketTimeoutMillis": 15000 (default),
- "localAddress": "212.150.139.167",
- "retrievalCachePeriodSecs": 43200 (default),
- "failedRetrievalCachePeriodSecs": 30 (default),
- "missedRetrievalCachePeriodSecs": 7200 (default),
- "unusedArtifactsCleanupEnabled": false (default),
- "unusedArtifactsCleanupPeriodHours": 0 (default),
- "assumedOfflinePeriodSecs" : 300 (default),
- "fetchJarsEagerly": false (default),
- "fetchSourcesEagerly": false (default),
- "shareConfiguration": false (default),
- "synchronizeProperties": false (default),
- "blockMismatchingMimeTypes" : true (default),
- "propertySets": ["ps1", "ps2"],
- "allowAnyHostAuth": false (default),
- "enableCookieManagement": false (default),
- "bowerRegistryUrl": "https://bower.herokuapp.com" (default),
- "vcsType": "GIT" (default),
- "vcsGitProvider": "GITHUB" (default) | "BITBUCKET" | "OLDSTASH" |
"STASH" | "ARTIFACTORY" | "CUSTOM",
- "vcsGitDownloadUrl": "" (default),
- "bypassHeadRequest" : false (default)
- "clientTlsCertificate": "" (default)
}

Virtual Repository
application/vnd.org.jfrog.artifactory.repositories.VirtualRepositoryConfiguration+json

{
- "key": "virtual-repo1",
+ "rclass" : "virtual",
+ "packageType": "maven" | "gradle" | "ivy" | "sbt" | "nuget" | "gems"
| "npm" | "bower" | "pypi" | "docker" | "p2" | "yum" | "chef" | "puppet"
| "generic"
- "repositories": ["local-rep1", "local-rep2", "remote-rep1",
"virtual-rep2"]
- "description": "The virtual repository public description",
- "notes": "Some internal notes",
- "includesPattern": "**/*" (default),
- "excludesPattern": "" (default),
- "debianTrivialLayout" : false
- "artifactoryRequestsCanRetrieveRemoteArtifacts": false,
- "keyPair": "keypair1",
- "pomRepositoryReferencesCleanupPolicy": "discard_active_reference"
(default) | "discard_any_reference" | "nothing"
- "defaultDeploymentRepo": "local-repo1"
}

Security Configuration JSON
Security Configuration JSON
Legend
+

Mandatory element in create/replace queries, optional in "update" queries

Optional element in create/replace queries

Read-only element

(default)

The default value when unspecified in create/replace queries

application/vnd.org.jfrog.artifactory.security.User+json

{
+
+
!
!
-

"name": "davids",
"email" : "davids@jfrog.com",
"password": "***" (write-only, never returned),
"admin": false (default),
"profileUpdatable": true (default),
"disableUIAccess" : true,
"internalPasswordDisabled": false (default),
"lastLoggedIn": ISO8601 (yyyy-MM-dd'T'HH:mm:ss.SSSZ),
"realm": "Internal",
"groups" : [ "deployers", "users" ]

}

application/vnd.org.jfrog.artifactory.security.Group+json

{
-

"name": "dev-leads",
"description" : "The development leads group",
"autoJoin" : false (default, must be false if adminPrivileges is true),
"adminPrivileges" : false (default),
"realm": "Realm name (e.g. ARTIFACTORY, CROWD)",
"realmAttributes": "Realm attributes for use by LDAP"

}

application/vnd.org.jfrog.artifactory.security.PermissionTarget+json

Permissions are set/returned according to the following conventions:
m=admin; d=delete; w=deploy; n=annotate; r=read
name - limited to 64 characters
includePattern/excludePattern - limited to 1024 characters

{
- "name": "populateCaches",
- "includesPattern": "**" (default),
- "excludesPattern": "" (default),
+ "repositories": ["local-rep1", "local-rep2", "remote-rep1",
"virtual-rep2"],
- "principals": {
"users" : {
"bob": ["r","w","m"],
"alice" : ["d","w","n", "r"]
},
"groups" : {
"dev-leads" : ["m","r","n"],
"readers" : ["r"]
}
}
}

System Settings JSON
System Settings JSON
Legend
+

Mandatory element

Optional element

(default)

The default value when unspecified

application/vnd.org.jfrog.artifactory.system.ImportSettings+json

{
+ "importPath" : "/import/path" (A path to a directory on the local file
system of Artifactory server),
- "includeMetadata" : true (default),
- "verbose" : false (default),
- "failOnError" : true (default),
- "failIfEmpty" : true (default)
}

application/vnd.org.jfrog.artifactory.system.ExportSettings+json

{
+ "exportPath" : "/export/path" (A path to a directory on the local file
system of Artifactory server),
- "includeMetadata" : true (default),
- "createArchive" : false (default),
- "bypassFiltering" : false (default),
- "verbose" : false (default),
- "failOnError" : true (default),
- "failIfEmpty" : true (default),
- "m2" : false (default),
- "incremental" : false (default),
- "excludeContent" : false (default)
}

application/vnd.org.jfrog.artifactory.system.Version+json

{
"version" : "2.2.2",
"revision" : "10427",
"addons" : [ "build", "ldap", "properties", "rest", ... ] (list of active
addons)
}

Configuring Artifactory

Overview
You can access the General Configuration settings of Artifactory in the Admin tab under Configuration |
General.
Saving changes
Any changes you make must be saved in order for them to take effect.

General Settings
The fields under General Settings allow you to set up various global parameters in Artifactory. The ? icon
next to each field provides a detailed description of the field. Fields marked with a red star are mandatory.

Page Contents
Overview
General Settings
Global Replication Blocking
Folder Download Settings
Trash Can Settings
Look and Feel Settings (Branding)
Custom Message

Read More
Configuring the Database
Configuring the Filestore
Checksum-Based Storage
Configuring Repositories
Configuring Security
Configuring a Reverse Proxy
Mail Server Configuration
Configuration Files
Exposing Maven Indexes
Clustering Artifactory

The General Settings fields are as follows:
The name of the server to be displayed on the title of each page.

Server
Name (mandatory)

Custom URL Base

By default, URLs generated in Artifactory use the context URL returned by your servlet container as a base.
A custom URL base is useful when Artifactory is running behind a proxy. In this case the base for URLs generated in
Artifactory for links and redirect responses must be specified manually.
Another reason to change the base URL would be to have non-request-based operations in Artifactory use the correct
address, for example in generated emails.
This may also be modified using the Update Custom URL Base REST API.
Overriding the Custom URL Base
You can override the Custom URL Base by adding an X-Artifactory-Override-Base-Url HTTP
header to your request. This can be useful if you need Artifactory to answer to more than one host name.

Maximum size allowed for files uploaded via the web interface.

File Upload Max
Size
The maximum number of files that can be pushed to Bintray in a single operation.

Bintray Max Files
Upload
The date format for displaying dates in the web interface.

Date Format
(mandatory)

Global Offline
Mode

When checked, Artifactory will behave as if it is not connected to an external network (such as the internet), and
therefore, will not query remote repositories (regardless of the offline status of any specific remote repository).

If set, Artifactory will display context sensitive help topics in the top right corner of the UI.

Enable Help
Component

Global Replication Blocking
By configuring Global Replication Blocking, you can enable or disable replication globally as needed.

Block Replications

When set, push and pull replication will be blocked according to the check boxes below, regardless of the
configuration for specific repositories.
When set, push replication will be blocked regardless of the configuration for specific repositories.

Block Push
Replications
When set, pull replication will be blocked regardless of the configuration for specific repositories.

Block Pull
Replications

Folder Download Settings

Must be set to enable folder download

Enable Folder Download
The maximum size (in MB) of a folder that may be downloaded

Max Size
The maximum number artifacts that may be downloaded under one folder

Max Number of Files
The maximum number of folder download requests that may be run concurrently

Max Parallel Folder Downloads

Trash Can Settings

If set, trash can will be enabled and deleted items will be stored in the trash can for the specified retention period.

Enable Trash Can
The number of days to keep deleted items in the trash can before deleting permanently.

Retention Period
Click to delete all items currently in the trash can permanently.

Empty Trash Can

Look and Feel Settings (Branding)
In the Look and Feel Settings you can configure Artifactory to present your company logo in the top left corner
of the screen and customize the footer text.
You may either upload an image to be used locally, or reference a remote image URL.

If selected, upload your company logo image file.

File
Logo file upload
The uploaded logo file is copied into the ARTIFACTORY_HOME/etc/ui folder.

If selected, specify the URL from which Artifactory should display your company logo

URL

Custom Message
You can display a Custom Message at the top of Artifactory screens.

To configure the custom message, in the Admin module, select Configuration | General.

Toggles the custom message on and off.

Enabled
When set, the custom message will only be displayed on the Artifactory Home Page.

Show Only in Home
Page
The title for the message.

Title
Click on the colored rectangle to select a color, or enter the color in Hex format.

Title Color

Message

The message to display. You can include links in the message using the following format: [, ]

Configuring the Database

Overview
Artifactory comes with a built-in embedded Derby database that can be reliably used to store data
(metadata) for production-level repositories up to hundreds of gigabytes in size.
However, Artifactory supports pluggable database implementations allowing you to change the default
to use other popular databases.
Artifactory currently supports the following databases:
Derby (The default embedded database)
MySQL v5.5 and above with InnoDB
Oracle version 10g and above
Microsoft SQL Server 2008 and above
PostgreSQL v9.2 and above
For each of the supported databases you can find the corresponding properties file inside $ARTIFACT
ORY_HOME/misc/db.

Choosing the Right Database
As the default database, Derby provides good performance since it runs in the same process as
Artifactory, however, under intensive usage or high load, performance may be degraded since
Artifactory and the database compete for shared JVM resources such as caches and memory.
Therefore, for Artifactory servers that need to support heavy load, you may consider using an external
database such as MySQL or PostgreSQL which are very common choices in many Artifactory
installations.
Any of the other supported databases is also a fair choice and may be the practical choice to make if
your organization is already using one of them.
Accessing a Remote Database
When using an external database, you need a reliable, stable and low-latency network
connection to ensure proper functioning of your system.
When using a fullDB configuration, we strongly recommend a high-bandwidth to
accommodate the transfer of large BLOBs over the network.

Modes of Operation
Artifactory supports two modes of operation:
Metadata in the database and binaries stored on the file system (This is the default and
recommended configuration).
Metadata and binaries stored as BLOBs in the database

Checksum-Based Storage
Artifactory uniquely stores artifacts using checksum-based storage. For details, please refer to Check
sum-Based Storage.

Page Contents
Overview
Choosing the Right Database
Modes of Operation
Checksum-Based Storage
Before You Start
Backup Your Current Installation
Setup the New Database
Advanced Settings

Read more
MySQL

Oracle
Microsoft SQL Server
PostgreSQL

Before You Start
Preprocessing
Changing the database does not automatically transfer your data to the new database. Please follow the steps below to backup your
data so that you can restore it after the change.

Backup Your Current Installation
When changing the database for an existing installation you must first perform a Full System Export using the "Exclude Content" option. Once
your new database is set up and configured, you will import this data to re-populate your Artifactory metadata content.
Make sure to backup your current Artifactory system before updating to a new database. You will need your Artifactory instance to be
disconnected from the network to avoid usage during this procedure.

Setup the New Database
To setup your new database you need to perform the following steps:
Create a database instance
Create an Artifactory user for the database
Install the appropriate JDBC driver
Copy the relevant database configuration file
Configure the corresponding db.properties file.
Start Artifactory
Import the metadata using Full System Import
These steps are fully detailed in the specific documentation page for each of the supported databases listed in the Overview.

Advanced Settings
Once you have setup your database, you can configure it to support your expected load with the following two parameters:
The maximum number of pooled database connections (default: 100).
pool.max.active

The maximum number of pooled idle database connections (default: 10).
pool.max.idle

MySQL
Overview
By using MySQL you can benefit from features in the MySQL infrastructure such as backup, restore and high
availability.
For Artifactory to run with MySQL you must create a dedicated MySQL database instance and then configure
Artifactory to use it as described in the following sections.
Before You Continue
Before proceeding with the steps below, please make sure you have read and followed the steps
described in Configuring the Database.

Page Contents
Overview
Creating the
Artifactory
MySQL
Database
Increasing
MySQL Default
Packet Size
Tuning MySQL
for Artifactory
Configuring
Artifactory to use
MySQL

Creating the Artifactory MySQL Database
Supported MySQL Versions
Artifactory supports MySQL v5.5 and above with InnoDB engine which is the default provided.
Artifactory provides a script that will execute the SQL commands you need to create your MySQL database.
The script can be found in $ARTIFACTORY_HOME/misc/db/createdb/createdb_mysql.sql and is displayed below.
You should review the script and modify it as needed to correspond to your specific environment.

createdb.sql Script
CREATE DATABASE artdb CHARACTER SET utf8 COLLATE utf8_bin;
GRANT ALL on artdb.* TO 'artifactory'@'localhost' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;

Selecting a Case-Sensitive Collation
While MySQL Database Server is not case-sensitive by default, it is important to select a case-sensitive collation because Artifactory is
case-sensitive.
For example, in the createdb.sql script above COLLATE is set to "utf8_bin".

Artifactory privileges
We recommend providing Artifactory with full privileges on the database

Increasing MySQL Default Packet Size
Since some data files (builds, configurations etc.) are stored in MySQL, it is extremely important to increase the maximum allowed packet size
used by MySQL to avoid errors related to large packets.
(Please refer to MySQL documentation: Packet Too Large).
It is recommended to change this in the /etc/my.cnf file as follows:

Modifying /etc/my.cnf
# The MySQL server
[mysqld]
.
# The maximum size of the binary payload the server can handle
max_allowed_packet=8M
.

/etc/my.cnf Absolute Path
If /etc/my.cnf does not already exist it should be created under the absolute path and not under $ARTIFACTORY_HOME

Restart required
After modifying the maximum allowed packed size you need to restart MySQL

You can also use the command line
You can also change the max_allowed_packet variable on the MySQL command line as in the following example:
SET GLOBAL max_allowed_packet = 134217728;
Note, however, that upon a restart, the value of the max_allowed_packet variable will be read from the /etc/my.cnf file and revert to
the value in that file as described above.

Tuning MySQL for Artifactory
When using Artifactory with MySQL it is recommended to use the InnoDB engine with the following tuning parameters configured in the /etc/my
.cnf file:

Tuning Parameters for MySQL
# The MySQL server
[mysqld]
.
# By default innodb engine use one file for all databases and tables. We
recommend changing this to one file per table.
# NOTE: This will take effect only if Artifactory tables are not created
yet! Need to be set and MySQL restarted before starting Artifactory for the
first time.
innodb_file_per_table
# Theses are tuning parameters that can be set to control and increase the
memory buffer sizes.
innodb_buffer_pool_size=1536M
tmp_table_size=512M
max_heap_table_size=512M
# Theses control the innodb log files size and can be changed only when
MySQL is down and MySQL will not start if there are some innodb log files
left in the datadir.
# So, changing theses means removing the old innodb log files before start.
innodb_log_file_size=256M
innodb_log_buffer_size=4M
.

Restart required
After tuning, you need to restart MySQL

Configuring Artifactory to use MySQL
1. Copy $ARTIFACTORY_HOME/misc/db/mysql.properties to $ARTIFACTORY_HOME/etc/db.properties
(If you do not have this file you can take it from the standalone zip distribution or directly from the JFrog domain). For a full explanation on
the contents of this file please refer to The Bundled Storage Configurations.
2. Adjust the connection definitions in the $ARTIFACTORY_HOME/etc/db.properties file to match the attributes of the Artifactory
database you created.
You must configure the database URL and username/password to use. The schema and tables are created first time Artifactory is run
using the new database.
3. Download the MySQL JDBC driver (available from the MySQL website) and copy the mysql-connector-java-.jar file
into the server's shared lib directory.
For example $TOMCAT_HOME/lib when installed as a service or $ARTIFACTORY_HOME/tomcat/lib in the standalone version.
Permissions
Make sure your driver has the same permissions as the rest of the files in the shared lib directory.
4. Start Artifactory.

Storing BLOBs inside MySQL
The suggested (and recommended) configuration stores all artifact information in MySQL while the artifact binary data is stored on the

file system (under $ARTIFACTORY_HOME/data/filestore).
While it is not recommended, it is possible to store BLOBs inside MySQL provided that the typical BLOB size is relatively small.
Storing large BLOBs in MySQL can cause memory issuesbecause MySQL buffers BLOBs rather than streaming them (please refer to
MySQL Bug #15089) and may result in OutOfMemory errors with large binaries depending on your JVM heap size.
To store BLOBs in MySQL, in the storage.propreties file set binary.provider.type=fullDb and change max_allowed_p
acket to be higher than the maximum artifact size you intend to store in Artifactory.

Oracle
Overview
By using Oracle you can benefit from features in Oracle infrastructure such as backup, restore and high
availability.
For Artifactory to run with Oracle you must create a dedicated Oracle database instance and then configure
Artifactory to use it as described in the following sections.
Before You Continue
Before proceeding with the steps below, please make sure you have read and followed the steps
described in Configuring the Database.

Upgrading the Database?
To avoid a regression of performance while upgrading the Oracle database (as a result of changes
in the execution plans), make sure to preserve the optimizer's behavior from the previous version.
For more details, please refer to Oracle documentation on Influencing the Optimizer.

Page Contents
Overview
Creating the Artifactory
Oracle Database
Configuring Artifactory
to use Oracle

Creating the Artifactory Oracle Database
Supported Oracle Versions
Artifactory supports Oracle v10g and above.
You can choose between two configurations to set up your Oracle Database
1. DB-Filesystem
This configuration stores metadata in Oracle Database and artifact binary data is stored on the file system (under $ARTIFACTORY_HOME
/data/filestore). This option has the advantage of being very lightweight on the Oracle database.
2. Full DB
This configuration stores both metadata and BLOBs in Oracle Database. This option requires minimal maintenance and allows you to rely
solely on Oracle for failover and backup procedures, since all data is in the database.
When using this option, make sure you have created a table space big enough to accommodate your binaries.
Artifactory privileges
Artifactory creates all tables automatically first time it is run. When performing a software upgrade Artifactory may have to alter tables

and indices, so make sure you grant the configured connection the appropriate user permissions to perform such actions.

Recommendation
With both of the above options (Full DB and DB-Filesystem), it is recommended to create a dedicated table space and use AL32
UTF8 encoding.

Reclaiming BLOB space
For efficiency, Artifactory uses a checksum to ensure that only one copy of any binary data is stored, however, you may want to reclaim
deleted BLOB space from time to time by shrinking the BLOB table space as follows:

Reclaiming Deleted BLOB Space
{schema}.binary_blobs modify lob (data) (shrink space cascade);

Configuring Artifactory to use Oracle
1. Copy $ARTIFACTORY_HOME/misc/db/oracle.properties to $ARTIFACTORY_HOME/etc/db.properties
(If you do not have this file you can take it from the standalone zip distribution or directly from the JFrog domain). For a full explanation on
the contents of this file please refer to The Bundled Storage Configurations.
2. Adjust the connection definitions in the $ARTIFACTORY_HOME/etc/db.properties file to match the attributes of the Artifactory
database you created.
You must configure the database URL and username/password to use. The schema and tables are created first time Artifactory is run
using the new database.
3. Download the JDBC driver corresponding to your Oracle version from the JDBC/UCP Download Page and copy the ojdbc6.jar file into
the server's shared lib directory.
For example $TOMCAT_HOME/lib when installed as a service or $ARTIFACTORY_HOME/tomcat/lib in the standalone version.
Permissions
Make sure your driver has the same permissions as the rest of the files in the shared lib directory.

4. Start Artifactory.

Microsoft SQL Server
Overview
By using MicrosoftSQLyou can benefit from features in the Microsoft SQL Server infrastructure such as
backup,restoreand high availability.
Optimizing Artifactory when running with MS SQL Server
When running Artifactory with Microsoft SQL Server you may create the Artifactory schema on an
existing server used for other applications, however for optimal performance, we recommend
creating a dedicated Microsoft SQL Server database instance and then configure Artifactory to use
it as described in the following sections.

Before You Continue
Before proceeding with the steps below, please make sure you have read and followed the steps
described in Configuring the Database.

Page Contents
Overview
Creating the Artifactory Microsoft SQL Server Database
Configuring Artifactory to use Microsoft SQL Server

Creating the Artifactory Microsoft SQL Server Database
Supported Microsoft SQL Server Versions
Artifactory supports Microsoft SQL Server 2008 and above.

1. Create a new user for Artifactory:
In Microsoft SQL Server Management Studio, open the Object Explorer, right click on Security and select New | Login....
2. Create user "artifactory" and set its password.

3. Create the Artifactory database:
In Microsoft SQL Server Management Studio, open the Object Explorer, right click on Databases and select New database...
4. In the New Database dialog window, select General in the Select a page: navigation pane.
Set Database name to "artifactory" and Owner to "artifactory" (the user name you created in step 2).

5. Select the Options page and set Collation to "Latin1_General_CS_AI".
Then click OK to confirm.

Selecting a Case-sensitive Collation
While Microsoft SQL Database Server is not case-sensitive by default, it is important to select a case-sensitive collation
because Artifactory is case-sensitive.

Configuring Artifactory to use Microsoft SQL Server
1. Copy $ARTIFACTORY_HOME/misc/db/mssql.properties to $ARTIFACTORY_HOME/etc/db.properties
(If you do not have this file you can take it from the standalone zip distribution or directly from the JFrog domain). For a full explanation on
the contents of this file please refer to The Bundled Storage Configurations.
2. Adjust the connection definitions in the $ARTIFACTORY_HOME/etc/db.properties file to match the attributes of the Artifactory
database you created.
You must configure the database URL and username/password to use. The schema and tables are created first time Artifactory is run
using the new database.
For example:

Configuring the Database URL and user/password
url=jdbc:sqlserver://hostname:1433;databaseName=dbname;sendStringPara
metersAsUnicode=false;applicationName=Artifactory Binary Repository

Where hostname is your database address, 1433 is your database port (if not the default 1433), dbname is the name of the database
you created in the previous step.
sendStringParameterAsUnicode
Make sure not to overwrite sendStringParametersAsUnicode=false since this is critical for appropriate and efficient use
of the database indices.

3. Download and extract the Microsoft JDBC Driver and copy the sqljdbc4.jar file into the server's shared lib directory.
For example $TOMCAT_HOME/lib when installed as a service or $ARTIFACTORY_HOME/tomcat/lib in the standalone version.
Permissions
Make sure your driver has the same permissions as the rest of the files in the shared lib directory.

4. Start Artifactory.

PostgreSQL
Overview
By using PostgreSQL you can benefit from features in PostgreSQL infrastructure such as backup, restore
and high availability.
For Artifactory to run with PostgreSQL you must create a dedicated PostgreSQL database instance and then
configure Artifactory to use it as described in the following sections.
Before You Continue
Before proceeding with the steps below, please make sure you have read and followed the steps
described in Configuring the Database.

Page Contents
Overview
Creating the
Artifactory
PostgreSQL Data
base
Configuring
Artifactory to use
PostgreSQL

Creating the Artifactory PostgreSQL Database
Supported PostgreSQL Versions
Artifactory supports PostgreSQL 9.2 and above using driver version 9.2-1002.jdbc4 and above.
The commands below create artifactory user and database with appropriate permissions.
Use the commands below to create an Artifactory user and database with appropriate permissions. Modify the relevant values to match your
specific environment:

Creating an Artifactory User and Database
CREATE USER artifactory WITH PASSWORD 'password';
CREATE DATABASE artifactory WITH OWNER=artifactory ENCODING='UTF8';
GRANT ALL PRIVILEGES ON DATABASE artifactory TO artifactory;

Artifactory privileges
We recommend providing Artifactory with full privileges on the database.

Configuring Artifactory to use PostgreSQL
1. Copy $ARTIFACTORY_HOME/misc/db/postgresql.properties to $ARTIFACTORY_HOME/etc/db.properties
(If you do not have this file you can take it from the standalone zip distribution or directly from the JFrog domain). For a full explanation on
the contents of this file please refer to The Bundled Storage Configurations.
2. Adjust the connection definitions in the $ARTIFACTORY_HOME/etc/db.properties file to match the attributes of the Artifactory
database you created.
You must configure the database URL and username/password to use. The schema and tables are created first time Artifactory is run
using the new database.
3. Download the JDBC driver corresponding to your PostgreSQL version from the PostgreSQL JDBC Driver Download site and copy the po
stgresql-9.x-xxx.jdbc4.jar file into the server's shared lib directory.
For example $TOMCAT_HOME/lib when installed as a service or $ARTIFACTORY_HOME/tomcat/lib in the standalone version.
Permissions
Make sure your driver has the same permissions as the rest of the files in the shared lib directory.

4. Start Artifactory.

Storing BLOBs inside PostgreSQL is not recommended
The above recommended configuration keeps all artifact information in PostgreSQL while storing the artifact binary data on the file
system (under $ARTIFACTORY_HOME/data/filestore).
While it is possible, to store BLOBs inside PostgreSQL we do not recommended it. This is important because the PostgreSQL driver
doesn't support streaming BLOBs with unknown length to the database. Therefore, Artifactory will temporarily save deployed files to the
filesystem and only then save the BLOB to the database.

Configuring the Filestore
Overview
JFrog Artifactory offers flexible filestore management that is configurable to meet a variety of needs
in terms of binary storage providers, storage size, and redundancy. Not only are you now able to
use different storage providers, but you can also chain a series of providers together to build
complex structures of binary providers and support seamless and unlimited growth in storage.
Artifactory offers flexible filestore management through the binarystore.xml configuration file
located in the $ARTIFACTORY_HOME/etc folder. By modifying this file you can implement a
variety of different binary storage configurations.
Take care when modifying binarystore.xml
Making changes to this file may result in losing binaries stored in Artifactory!
If you are not sure of what you are doing, please contact JFrog Support for assistance.

Chains and Binary Providers
The binarystore.xml file specifies a chain with a set of binary providers. A binary provider repr
esents a type of object storage feature such as “cached filesystem”. Binary providers can be
embedded into one another to form chains that represent a coherent filestore. Artifactory comes
with a built-in set of chains that correspond to the binary.provider.type parameter that was used in
previous versions of Artifactory. The built-in set of chains available in Artifactory are:
file-system
cache-fs
full-db
full-db-direct

Page contents
Overview
Chains
and
Binary
Provid
ers
Configuring a
Built-in
Filestore
Basic
Configuration
Elements
Built-in
Templ
ates
Modifying an
Existing
Filestore

s3
google-storage
double-shards
redundant-shards
cluster-file-system
cluster-s3
cluster-google-storage

Configuring a Built-in Filestore
To configure Artifactory to use one of the built-in filestores, you only need some basic configuration
elements.

Built-in Chain
Templates
Filesys
tem
Binary
Provid
er
Cache
d
Filesys
tem
Binary
Provid
er
Full-D
B
Binary
Provid
er
Full-D
B-Dire
ct
Binary
Provid
er
Cloud
Storag
e
Provid
ers

S3 Binary Provider
S3Old Binary Provide
Google Storage Binar
Azure Blob Storage B
Eventual Binary Provi
Retry Binary Provider
Doubl
e
Shard
s,
Redun
dant
Shard
s

Double Shards Binary
Redundant Shards Bi
Sharding Binary Prov
State-Aware Binary P
Config
uring
Shardi
ng for
HA
Cluste
r

File System Cluster B
S3 Cluster Binary Pro
Google Storage Clust
Azure Blob Storage C
Sharding-Cluster Bina
Remote Binary Provid
Configuring a
Custom
Filestore From
Scratch
Configuring the
Filestore for
Older
Artifactory
Versions

Basic Configuration Elements
For basic filestore configuration, the binarystore.xml file is quite simple and contains the basic tags or elements that are described below
along with the attributes that they may include:
config tag
The tag specifies a filestore configuration. It includes a version attribute to allow versioning of configurations.

…

chain element
The config tag contains a chain element that that defines the structure of the filestore. To use one of the built-in filestores, the chain element
needs to include the corresponding template attribute. For example, to use the built-in basic “file system” template, all you need is the
following configuration:

Built-in Templates
The following sections describe the basic chain templates come built-in with Artifactory and are ready for you to use out-of-the-box, as well as
other binary providers that are included in the default chains.
Additional information about every template can be found below, under the Built-in Chain Templates section.
The most basic filestore configuration for Artifactory used for a local or mounted filestore.
file-system

cache-fs

Works the same way as filesystem but also has a binary LRU (Least Recently Used) cache for download
requests. Improves performance of instances with high IOPS (I/O Operations) or slow NFS access.
All the metadata and the binaries are stored as BLOBs in the database with an additional layer of caching.

full-db

All the metadata and the binaries are stored as BLOBs in the database without caching.
full-db-direct

This is the setting used for S3 Object Storage using the JetS3t library.
s3

This is the setting used for S3 Object Storage using JCloud as the underlying framework.
s3Old

This is the setting used for Google Cloud Storage as the remote filestore.
google-storage

This is the setting used for Azure Blob Storage as the remote filestore.
azure-blob-storage

double-shards

A pure sharding configuration that uses 2 physical mounts with 1 copy (which means each artifact is saved
only once).

redundant-shards

A pure sharding configuration that uses 2 physical mounts with 2 copies (which means each shard stores a
copy of each artifact).

cluster-file-system

A filestore configuration where each node has its own local filestore (just like the file-system chain) and is
connected to all other nodes via dynamically allocated Remote Binary Providers using the Sharding-Cluster p
rovider.

cluster-s3

This is the setting used for S3 Object Storage using the JetS3t library. It is based on the sharding and
dynamic provider logic that synchronizes the cluster-file-system.

cluster-google-storage

This is the setting used for Google Cloud Storage using the JetS3t library. It is based on the sharding and
dynamic provider logic that synchronizes the cluster-file-system.

cluster-azure-blob-storage

This is the setting used for Azure Blob Storage. It is based on the sharding and dynamic provider logic that
synchronizes the cluster-file-system.

Modifying an Existing Filestore
To accommodate any specific requirements you may have for your filestore, you may modify one of the existing chain templates either by
extending it with additional binary providers or by overriding one of its attributes. For example, the built-in filesystem chain template stores
binaries under the $ARTIFACTORY_HOME/data/filestore directory. To modify the template so that it stores binaries under $FILESTORE
/binaries you could extend it as follows:

"file-system" binary provider -->
$FILESTORE/binaries
attribute -->

[My Ceph Bucket Name]

false

Example 3

A configuration for CleverSafe.

XXXXXXXXX
XXXXXXXX
[My CleverSafe Server]
[My CleverSafe Bucket]
false

Example 4

A configuration for S3 with a proxy between Artifactory and the S3 bucket.

XXXXXXXXXX
XXXXXXXXXXXXXXXXX
[My S3 server]
[My S3 Bucket Name]
[http proxy host name]
[http proxy port number]
XXXXX
XXXX

Example 5

A configuration for S3 using an IAM role instead of an IAM user.

XXXXXX
s3.amazonaws.com
[mybucketname]
true

Example 6

A configuration for S3 when using server side encryption.

XXXXXXXXX
XXXXXXXX
s3.amazonaws.com
[mybucketname]

Example 7

A configuration for S3 when using EMC Elastic Cloud Storage (ECS).

XXXXXXXXXX
XXXXXXXXXXXXXXXXX

Required only if HTTPS port other than 443 is used -->
[My ECS Bucket Name]

XXXXXXXXX
XXXXXXXX

false

10
180000

Where:
eventual
type

The maximum amount of time a file may be locked while it is being written to or deleted from the filesystem.
timeout

Default: 5000 ms
dispatchInterval

The interval between which the provider scans the “eventual” folder to check for files that should be uploaded to
persistent storage.
Default: 5

numberOfThreads

The number of parallel threads that should be allocated for uploading files to persistent storage.

Retry Binary Provider
This binary provider is not independent and will always be used as part of a more complex template chain of providers. In case of a failure in
a read or write operation, this binary provider notifies its underlying provider in the hierarchy to retry the operation.

retry
type

interval

Default: 5000 ms
The time interval to wait before retries.

maxTrys

Default: 5
The maximum number of attempts to read or write before responding with failure.

Example

The example below shows a configuration that uses S3 for persistent storage , but uses a retry provider to keep retrying (up to a maximum of
10 times) in case upload fails.

XXXXXXXXX
XXXXXXXX

false

Double Shards, Redundant Shards
These binary providers are only available with an Enterprise license.

Double Shards Binary Provider

The double-shards template is used for pure sharding configuration that uses 2 physical mounts with 1 copy (which means each artifact is
saved only once). To learn more about the different sharding capabilities, refer to Filestore Sharding.
double-shards template configuration

If you choose to use the double-shards template, your binarystore.xml configuration file should look like this:

What's in the template?

While you don't need to configure anything else in your binarystore.xml, this is what the double-shards template looks like under the hood.
For details about the cache-fs provider, please refer to Cached Filesystem Binary Provider.
For details about the sharding provider, please refer to Sharding Binary Provider.
For details about the state-aware sub-provider, please refer to State-Aware Binary Provider.

Redundant Shards Binary Provider
The redundant-shards template is used for pure sharding configuration that uses 2 physical mounts with 2 copies (which means each shard
stores a copy of each artifact). To learn more about the different sharding capabilities, refer to Filestore Sharding.
redundant-shards template configuration

If you choose to use the redundant-shards template, your binarystore.xml configuration file should look like this:

What's in the template?

While you don't need to configure anything else in your binarystore.xml, this is what the redundant-shards template looks like under the hood.
Details about the cache-fs provider can be found in the Cached Filesystem Binary Provider section.
Details about the sharding provider can be found in the Sharding Binary Provider section.
Details about the state-aware sub-provider can be found in the State-Aware Binary Provider section.

Sharding Binary Provider
Artifactory offers a Sharding Binary Provider that lets you manage your binaries in a sharded filestore. A sharded filestore is one that is
implemented on a number of physical mounts (M), which store binary objects with redundancy (R), where R <= M.
This binary provider is not independent and will always be used as part of a more complex template chain of providers. To learn about
sharding, refer to Filestore Sharding.
sharding
type

readBehavior

This parameter dictates the strategy for reading binaries from the mounts that make up the sharded
filestore.
Possible values are:
roundRobin (default): Binaries are read from each mount using a round robin strategy.

writeBehavior

This parameter dictates the strategy for writing binaries to the mounts that make up the sharded filestore.
Possible values are:
roundRobin (default): Binaries are written to each mount using a round robin strategy.
freeSpace: Binaries are written to the mount with the greatest absolute volume of free space available.
percentageFreeSpace: Binaries are written to the mount with the percentage of free space available.

redundancy

Default: r = 1
The number of copies that should be stored for each binary in the filestore. Note that redundancy must
be less than or equal to the number of mounts in your system for Artifactory to work with this
configuration.
Default: 30,000 ms

concurrentStreamWaitTimeout

To support the specified redundancy, accumulates the write stream in a buffer, and uses “r” threads
(according to the specified redundancy) to write to each of the redundant copies of the binary being
written. A binary can only be considered written once all redundant threads have completed their write
operation. Since all threads are competing for the write stream buffer, each one will complete the write
operation at a different time. This parameter specifies the amount of time (ms) that any thread will wait
for all the others to complete their write operation.
If a write operation fails, you can try increasing the value of this parameter.

concurrentStreamBufferKb

Default: 32 Kb
The size of the write buffer used to accumulate the write stream before being replicated for writing to the
“r” redundant copies of the binary.
If a write operation fails, you can try increasing the value of this parameter.

maxBalancingRunTime

Default: 3,600,000 ms (1 hour)
Once a failed mount has been restored, this parameter specifies how long each balancing session may
run before it lapses until the next Garbage Collection has completed. For more details about balancing,
please refer to Using Balancing to Recover from Mount Failure.
To restore your system to full redundancy more quickly after a mount failure, you may increase
the value of this parameter. If you find this causes an unacceptable degradation of overall
system performance, you can consider decreasing the value of this parameter, but this means
that the overall time taken for Artifactory to restore full redundancy will be longer.

Default: 3,600,000 ms (1 hour)
freeSpaceSampleInterval

To implement its write behavior, Artifactory needs to periodically query the mounts in the sharded
filestore to check for free space. Since this check may be a resource intensive operation, you may use
this parameter to control the time interval between free space checks.
If you anticipate a period of intensive upload of large volumes of binaries, you can consider
decreasing the value of this parameter in order to reduce the transient imbalance between
mounts in your system.

Default: 2
minSpareUploaderExecutor

Artifactory maintains a pool of threads to execute writes to each redundant unit of storage. Depending on
the intensity of write activity, eventually, some of the threads may become idle and are then candidates
for being killed. However, Artifactory does need to maintain some threads alive for when write activities
begin again. This parameter specifies the minimum number of threads that should be kept alive to supply
redundant storage units.
Default: 120,000 ms (2 min)

uploaderCleanupIdleTime

The maximum period of time threads may remain idle before becoming candidates for being killed.

State-Aware Binary Provider
This binary provider is not independent and will always be used in the sharding or sharding-cluster providers. The provider is aware if its
underlying disk is functioning or not. It is identical to the basic filesystem provider provider, however, it can also recover from errors (the
parent provider is responsible for recovery) with the addition of the checkPeriod field.

state-aware
type

Default: 15000 ms
checkPeriod

The minimum time to wait between trying to re-activate the provider if it had fatal errors at any point.
The name of the sharding zone the provider is part of (only applicable under a sharding provider)

zone

Configuring Sharding for HA Cluster
These binary providers are only available with an Enterprise license.

For a High Availability cluster, Artifactory offers templates that support sharding-cluster for File-System, S3 and Google Storage. To learn
more about the different sharding capabilities, refer to Filestore Sharding.
When configuring your filestore on an HA cluster, you need to place the binarystore.xml under $ARTIFACTORY_HOME/etc in the primary
node and it will be synced to the other members in the cluster.

File System Cluster Binary Provider

When using the cluster-file-system template, each node has its own local filestore (just like in the file-system binary provider) and is
connected to all other cluster nodes via dynamically allocated Remote Binary Providers using the Sharding-Cluster Binary Provider.
cluster-file-system template configuration

If you choose to use the cluster-file-system template, your binarystore.xml configuration file should look like this:

What's in the template?

While you don't need to configure anything else in your binarystore.xml, this is what the cluster-file-system template looks like under the
hood.
Details about the cache-fs provider can be found in the Cached Filesystem Binary Provider section.
Details about the sharding-cluster can be found in the Sharding-Cluster Binary Provider section.
Details about the state-aware sub-provider can be found in the State-Aware Binary Provider section.

local

remote

crossNetworkStrategy
crossNetworkStrategy
2

S3 Cluster Binary Provider
This is the setting used for S3 Object Storage using the JetS3t library when configuring filestore sharding for an HA cluster. It is based on the
sharding and dynamic provider logic that synchronizes the cluster-file-system.
When using the cluster-s3 template, data is temporarily stored on the file system of each node using the Eventual Binary Provider, and is then
passed on to your S3 object storage for persistent storage.
Each node has its own local filestore (just like in the file-system binary provider) and is connected to all other cluster nodes via dynamically
allocated Remote Binary Providers using the Sharding-Cluster Binary Provider.

cluster-s3 template configuration

Because you must configure the s3 provider with parameters specific to your account (but can leave all other parameters with the
recommended values), if you choose to use the cluster-s3 template, your binarystore.xml configuration file should look like this:

http://s3.amazonaws.com
[ENTER IDENTITY HERE]
[ENTER CREDENTIALS HERE]
[ENTER PATH HERE]
[ENTER BUCKET NAME HERE]

What's in the template?

While you don't need to configure anything else in your binarystore.xml, this is what the cluster-s3 template looks like under the hood.

crossNetworkStrategy
crossNetworkStrategy
2

remote

local

http://s3.amazonaws.com
[ENTER IDENTITY HERE]
[ENTER CREDENTIALS HERE]
[ENTER PATH HERE]
[ENTER BUCKET NAME HERE]

Details about the cache-fs provider can be found in the Cached Filesystem Binary Provider section.
Details about the sharding-cluster can be found in the Sharding-Cluster Binary Provider section.
Details about the eventual-cluster sub-provider can be found in the Eventual Binary Provider section.
Details about the retry provider can be found in the Retry Binary Provider section.
Details about the remote dnyamic provider can be found in the Remote Binary Provider section.

Google Storage Cluster Binary Provider
This is the setting used for Google Cloud Storage using the JetS3t library when configuring filestore sharding for an HA cluster. It is based on
the sharding and dynamic provider logic that synchronizes the cluster-file-system.
When using the cluster-google-storage template, data is temporarily stored on the file system of each node using the Eventual Binary
Provider, and is then passed on to your Google storage for persistent storage.
Each node has its own local filestore (just like in the file-system binary provider) and is connected to all other cluster nodes via dynamically
allocated Remote Binary Providers using the Sharding-Cluster Binary Provider.
cluster-google-storage template configuration

Because you must configure the google-storage provider with parameters specific to your account (but can leave all other parameters with
the recommended values), if you choose to use the cluster-google-storage template, your binarystore.xml configuration file should look
like this:

commondatastorage.googleapis.com

XXXXXX
XXXXXXX

What's in the template?

While you don't need to configure anything else in your binarystore.xml, this is what the cluster-google-storage template looks like under the
hood.

crossNetworkStrategy
crossNetworkStrategy
2

remote

local

commondatastorage.googleapis.com

XXXXXX
XXXXXXX

Azure Blob Storage Cluster Binary Provider
This is the setting used for Azure Blob Storage. It is based on the sharding and dynamic provider logic that synchronizes the
cluster-file-system.
When using the cluster-azure-blob-storage template, data is temporarily stored on the file system of each node using the Eventual Binary
Provider, and is then passed on to your Azure Blob Storage for persistent storage.

Each node has its own local filestore (just like in the file-system binary provider) and is connected to all other cluster nodes via dynamically
allocated Remote Binary Providers using the Sharding-Cluster Binary Provider.
cluster-azure-blob-storage template configuration

Because you must configure the azure-blob-storage provider with parameters specific to your account (but can leave all other parameters
with the recommended values), if you choose to use the cluster-azure-blob-storage template, your binarystore.xml configuration file
should look like this:

XXXXXX
XXXXXX
https://.blob.core.windows.net/

What's in the template?

While you don't need to configure anything else in your binarystore.xml, this is what the cluster-azure-blob-storage template looks like under
the hood:

crossNetworkStrategy
crossNetworkStrategy
2
1

remote

local

XXXXXX
XXXXXX
https://.blob.core.windows.net/

Sharding-Cluster Binary Provider
The sharding-cluster binary provider can be used together with other binary providers for both local or cloud-native storage. It adds a crossN
etworkStrategy parameter to be used as read and write behaviors for validation of the redundancy values and the balance mechanism. It
must include a Remote Binary Provider in its dynamic-provider setting to allow synchronizing providers across the cluster.
The Sharding-Cluster provider listens to cluster topology events and creates or removes dynamic providers based on the current state of
nodes in the cluster.
sharding-cluster
type

The zones defined in the sharding mechanism. Read/write strategies take providers based on zones.
zones

lenientLimit

Default: 1 (From version 5.4. Note that for filestores configured with a custom chain and not using the built-in
templates, the default value of the lenientLimit parameter is 0 to maintain consistency with previous versions.)
The minimum number of filestores that must be active for writes to continue. For example, if lenientLimit is set to
2, my setup includes 4 filestores, and 2 of them go down, writing will continue. If a 3rd filestore goes down, writing will
stop.
Typically this is used to address transient failures of an individual binary store, with the assumption that the balance
mechanism will make up for it over time.

dynamic-provider

Example

The type of provider that can be added and removed dynamically based on cluster topology changes. Currently only
the Remote Binary Provider is supported as a dynamic provider.

crossNetworkStrategy
crossNetworkStrategy
2
1

filestore1

15000
5000
15000
200
2
remote

Remote Binary Provider
This binary provider is not independent and will always be used as part of a more complex template chain of providers. In case of a failure in
a read or write operation, this binary provider notifies its parent provider in the hierarchy.
The remote Binary Provider links a node to all other nodes in the cluster, meaning it enables each node to 'see' the filestore of every other
node.
remote
type

connectionTimeout

Default: 5000 ms
Time before timing out an outgoing connection.

socketTimeout

Default: 15000 ms
Time before timing out an established connection (i.e. no data is sent over the wire).
Default: 200

maxConnections

Maximum outgoing connections from the provider.

Default: 2
connectionRetry

How many times to retry connecting to the remote endpoint.
The name of the sharding zone the provider is part of (only applicable under a sharding provider).

zone

Default: 15000 ms
checkPeriod

The minimum time to wait between trying to re-activate the provider if it had fatal errors at any point.

Example

The following is an example how a remote binary provider may be configured. To see how this can be integrated with a complete binarysto
re.xml configuration, please refer to the example under Sharding-Cluster Binary Provider.

15000
5000
15000
200
2
remote

Configuring a Custom Filestore From Scratch
In addition to the built-in filestore chain templates below, you may construct custom chain template to accommodate any filestore structure
you need.
Since the different Binary providers in the filestore must be compatible with each other, misconfiguration might lead to data loss. For
configuring a custom filestore, please contact JFrog Support.

Configuring the Filestore for Older Artifactory Versions
For versions of Artifactory below 4.6, the filestore used is configured in the $ARTIFACTORY_HOME/etc/storage.properties file as
follows

binary.provider.type

filesystem (default)
This means that metadata is stored in the database, but binaries are stored in the file system. The
default location is under $ARTIFACTORY_HOME/data/filestore however this can be modified.
fullDb
All the metadata and the binaries are stored as BLOBs in the database.
cachedFS
Works the same way as filesystem but also has a binary LRU (Least Recently Used) cache for
upload/download requests. Improves performance of instances with high IOPS (I/O Operations) or slow
NFS access.
S3
This is the setting used for S3 Object Storage.
This value specifies the maximum cache size (in bytes) to allocate on the system for caching BLOBs.

binary.provider.cache.maxSize

binary.provider.filesystem.dir

If binary.provider.type is set to filesystem this value specifies the location of the binaries (default:
$ARTIFACTORY_HOME/data/filestore).

binary.provider.cache.dir

The location of the cache. This should be set to your $ARTIFACTORY_HOME directory directly (not on
the NFS).

maxCacheSiz

Checksum-Based Storage
Overview
Artifactory uniquely stores artifacts using checksum-based storage.
A file that is uploaded to Artifactory, first has its SHA1 checksum calculated, and is then renamed
to its checksum. It is then hosted in the configured filestore in a directory structure made up of the
first two characters of the checksum. For example, a file whose checksum is "ac3f5e56..." would be
stored in directory "ac"; a file whose checksum is "dfe12a4b..." would be stored in directory "df" and
so forth. The example below shows the "d4" directory that contains two files whose checksum
begins with "d4".

Page Contents
Overview
SHA-256
Support
Migrati
ng the
Datab
ase to
Includ
e
SHA-2
56

Configuring the Migra
Monitoring the Migrati

In parallel, Artifactory's creates a database entry mapping the file's checksum to the path it was
uploaded to in a repository. This way of storing binaries optimizes many operations in Artifactory
since they are implemented through simple database transactions rather than actually manipulating
files.
Deduplication

Artifactory stores any binary file only once. This is what we call "once and once only storage". First time a file is uploaded, Artifactory runs the
required checksum calculations when storing the file, however, if the file is uploaded again (to a different location, for example), the upload is
implemented as a simple database transaction that creates another record mapping the file's checksum to its new location. There is no need
to actually store the file again in storage. No matter how many times a file is uploaded, the filestore only hosts a single copy of the file.
Copying and Moving Files

Copying and moving a file is implemented by simply adding and removing database references and, correspondingly, performance of these
actions is that of a database transaction.
Deleting Files

Deleting a file is also a simple database transaction in which the corresponding database record is deleted. The file itself is not directly
deleted, even if the last database entry pointing to it is removed. So-called "orphaned" files are removed in the background by Artifactory's
garbage collection processes.
Upload, download and replication

Before moving files from one location to another, Artifactory sends checksum headers. If the files already exist in the destination, they are not
transferred even if they exist under a different path.
Filesystem Performance

Filesystem performance is greatly improved because actions on the filestore are implemented as database transactions, so there is never any
need to do a write-lock on the filesystem.

Checksum Search

Searching for a file by its checksum is extremely fast since Artifactory is actually searching through the database for the specified checksum.
Flexible Layout

Since the database is a layer of indirection between the filestore and the displayed layout, any layout can be supported, whether for one of
the standard packaging formats such as Maven1, Maven2, npm, NuGet etc. or for any custom layout.

SHA-256 Support
From version 5.5, Artifactory natively supports SHA-256. An artifact's SHA-256 checksum is calculated when it is deployed to Artifactory, and
is maintained in persistent storage as part of the database. The Set Item SHA256 Checksum REST API endpoint (which sets an artifact's
SHA-256 checksum as one of its properties) is still supported for backward compatibility, however, this endpoint will eventually be
deprecated.
Artifactory's support for SHA-256 checksums is fully-featured and is evident in several ways:
They can be used in AQL queries, and are returned in corresponding responses
They are included as download header information
They can be used in the Deploy Artifact and Deploy Artifact by Checksum REST API endpoints.
They are included when downloading a folder
They are displayed in the General Information tab of the Artifact Repository Browser
The can be used in a variety of REST API endpoints used for search
After upgrading to version 5.5 (or above), Artifactory will be fully capable of utilizing an artifact's SHA-256 checksum for any of the features
mentioned above.
Making full use of Artifactory's native support for SHA256
New artifacts that are uploaded will automatically have their SHA-256 checksum calculated, however, artifacts that were already
hosted in Artifactory prior to the upgrade will not have their SHA-256 checksum in the database yet.
To make full use of Artifactory's SHA-256 capabilities, you need to run a process that migrates Artifactory's database mak
ing sure that the record for each artifact includes its SHA-256 checksum.

Migrating the Database to Include SHA-256
Migrating the database may be a resource intensive operation
Depending on the size of your database, this process may be resource intensive. To mitigate the possible load on your system, you
may configure the process using several system properties listed below. We strongly recommend reading through the entire
process migration process to ensure the optimal configuration for your system.
The migration is configured through a set of properties in Artifactory's system.properties file as described below, and essentially, does
the following:
Search for all database records that don't have a SHA-256 value.
For each such record, find all others in the database with the same SHA1 checksum value
If any of them have the SHA-256 calculated already, use that to update all the others
If none of them have the SHA-256 calculated already, calculate it and then use that to update all others
If there are no other records with the same SHA1 value, calculate the SHA-256

First run garbage collection to optimize the migration process
The migration process is complete once all database entries have been populated with SHA-256 values. Since your database may
contain entries for artifacts that have been deleted, but have not yet been physically removed by garbage collection, we strongly
recommend manually invoking garbage collection before invoking the database migration. Removing deleted artifacts can greatly
improve performance and total run time of the migration by reducing the number of downloads it generates.

Configuring the Migration Process
The migration process may be configured through the following system properties.
By default, the migration will run on the primary node, however, using the forceRunOnNodeId property described below, you may configure
it to run on a secondary node.

Property Name

Function

artifactory.sha2.migration.job.enabled

[ Default: false ]
When true, the process that migrates the database to include SHA-256
checksum for all artifacts will be invoked when the node is restarted.

artifactory.sha2.migration.job.forceRunOnNodeId

[ Default: null ]
Only valid for an HA installation.
By default, the migration process runs on the primary node. To run the
process on any other node, set this value to the corresponding node's ID
(as specified in the node.id property in the nodes $ARTIFACTORY_HO
ME/etc/ha-node.properties file).
Running the migration on a dedicated node
This gives you the option of dedicating a specific node to run
the migration and allocating extra resources allowing it to finish
the process faster.

Set the property on both the primary and the
corresponding secondary node
To run the migration process on a secondary node, you need
to set this property on BOTH the master node and the
corresponding secondary node. Artifactory will still only run
the process on the corresponding secondary node.

artifactory.migration.job.dbQueryLimit

[ Default: 100 ]
Specifies the number of rows that should be retrieved each time the
migration job queries the database for entries that are missing SHA-256
values.

artifactory.migration.job.batchSize

[ Default: 10 ]
Artifacts are updated concurrently in batches with new SHA-256 values
and then a sleep cycle is initiated. This property specifies the number of
artifacts in each batch.

artifactory.sha2.migration.job.queue.workers

[ Default: 2 ]
Specifies the number of concurrent threads that should execute actual
artifact updates.
Each concurrent artifact update may incur a download in order to
calculate its SHA-256 checksum. However, the artifact will only be
downloaded once, first time a database entry is found for it with no
SHA-256 value. Subsequent database entries for the same artifact
(which therefore have the same SHA1 value) will reuse the SHA-256
value that was already calculated.

artifactory.migration.job.sleepIntervalMillis

[ Default: 5000 milliseconds ]
Specifies the duration of the sleep cycle which is initiated after each
batch of updates.

A sample snippet you can paste into your artifactory.system.properties is below, adjust the number of workers as appropriate based on I/O
and CPU utilization:

Example artifactory.system.properties snippet
##SHA2 Migration block
artifactory.sha2.migration.job.enabled=true
artifactory.sha2.migration.job.queue.workers=5

Restart required
For changes to the migration configuration to take effect, you need to restart the instance (or node in the case of an HA installation)
that will run it. The default values specified above are set to keep your system performing optimally during the migration process.
To speed up the migration process, you may tweak these values (keeping hardware limits in mind), however that may come at a
cost of system performance.

Monitoring the Migration Process
Depending on the size of your storage, and the migration parameters you have configured, the migration process may take a long time. To
enable easy monitoring of the process, status and error messages are printed into a dedicated log file, ARTIFACTORY_HOME/logs/sha256
_migration.log. In addition, some messages (process initiation, startup errors) are also logged in the ARTIFACTORY_HOME/logs/arti
factory.log file.

Configuring Repositories
Overview
Artifactory hosts three types of repository:
Local
Remote
Virtual
Local and remote repositories are true physical repositories, while a virtual repository is actually an
aggregation of them used to create controlled domains for search and resolution of artifacts.
To configure repositories, in the Admin module, select Repositories.
Repositories can be created, deleted, edited, ordered and aggregated.

Single Package Type
When creating any repository, you must specify its package type; this is a fundamental characteristic of the
repository and can not be changed later. Once the repository type is set, Artifactory will index artifacts and
calculate the corresponding metadata for every package uploaded which optimizes performance when
resolving artifacts. Note that virtual repositories can only include repositories of the same type.
Wrong Package Type
While Artifactory will not prevent you from uploading a package of the wrong type to a repository,
we strongly recommend maintaining consistency between the repository type and packages you
upload.
if you do upload packages of the wrong type to a repository, Artifactory will not index the package
or update the metadata for the repository.

Page Contents
Overview
Single Package Type
Generic Repositories
Local Repositories
Remote Repositories
Virtual Repositories
The Default Virtual Repository (Deprecated)
Virtual Resolution Order
General Resolution Order

Read More
Common Settings
Local Repositories
Remote Repositories
Smart Remote Repositories
Virtual Repositories

Generic Repositories
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
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:
http://:/artifactory//
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.

Remote 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:
http://:/artifactory//
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:
http://:/artifactory/-cache/
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.
Proxy vs. Mirror
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.
Therefore, a remote repository should not contain any artifacts in its cache immediately after creation. Artifacts will only be fetched to
the cache once clients start working with the remote repository and issuing requests.
For full details on configuring remote repositories please refer to Remote Repositories.

Virtual Repositories
A virtual repository (or "repository group") aggregates several repositories with the same package type under a common URL. The repository is
virtual in that you can resolve and retrieve artifacts from it but you cannot deploy artifacts to it.
Generic Virtual Repositories
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

The Default Virtual Repository (Deprecated)
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:
http://:/artifactory/repo

Virtual Resolution Order
When an artifact is requested from a virtual repository, the order in which repositories are searched or resolved is local repositories first, then rem
ote 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.

General Resolution Order
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.

Common Settings
Overview
Several of the settings are common for local, remote and virtual repositories. These are found in the Basic
Settings tab of the corresponding New/Edit screen under the General section. Additional settings may be
found in the type-specific section according to the package types specified for the repository.

Common Basic Settings

Package
Type

Repository
Key

Repository
Layout

The Package Type must be specified when the repository is created, and once set, cannot
be changed.

The Repository Key is a mandatory identifier for the repository and must be unique within
an Artifactory instance. It cannot begin with a number or contain spaces or special
characters. For local repositories we recommend using a "-local" suffix (e.g.
"libs-release-local").
Sets the layout that the repository should use for storing and identifying modules. Artifactory
will suggest a layout that corresponds to the package type defined, and index packages
uploaded and calculate metadata accordingly.
A free text field that describes the content and purpose of the repository.

Public
Description

Internal
Description

A free text field to add additional notes about the repository. These are only visible to the
Artifactory administrator.

Include
and
Exclude
Patterns

The Include Patterns and the Exclude Patterns fields provide a way to filter out specific
repositories when trying to resolve the location of different artifacts.
In each field you can specify a list of Ant-like patterns to filter in and filter out artifact
queries. Filtering works by subtracting the excluded patterns (default is none) from the
included patterns (default is all).
Example:
Consider that the Include Patterns and Exclude Patterns for a repository are as follows:

Include Patterns: org/apache/**,com/acme/**
Exclude Patterns: com/acme/exp-project/**

In this case, Artifactory will search the repository for org/apache/maven/parent/1/1.p
om and com/acme/project-x/core/1.0/nit-1.0.jar but not for com/acme/exp-p
roject/core/1.1/san-1.1.jar because com/acme/exp-project/** is
specified as an Exclude pattern.

JFrog Xray
Integration

If Artifactory is connected to an instance of Xray, indicates if the repository is indexed for
analysis.

Page Contents
Overview
Common Basic Settings
Avoiding Security Risks with an Exclude Pattern
Avoiding Performance Issues with an Include Pattern
Local and Remote Repositories

Avoiding Security Risks with an Exclude Pattern
Any proprietary artifacts you deploy to Artifactory are stored within local repositories so that they are available for secured and authorized internal
use.
Anyone searching for one of your internal artifacts by name will extract it through Artifactory from the local repository.
However, consider what happens if a request for an internal artifact is inadvertently directed outside of the organization.
Two examples of how this could happen are:
there is a simple typo in the requested artifact name
the developer has requested a snapshot with a version number that does not exist.
In this case, since Artifactory does not find the requested artifact in a local repository, it continues to search through the remote repositories
defined in the system. Artifactory will, in fact, search through all the remote repositories defined in your system before returning "Not found".
This presents a security risk since any request made on a remote repository may be logged exposing all details of the query including the full
artifact name which may include sensitive business information.
Best practices using an excludes pattern for remote repositories to avoid security risks
To avoid exposing sensitive business information as described above, we strongly recommend the following best practices:
The list of remote repositories used in an organization should be managed under a single virtual repository to which all
requests are directed
All internal artifacts should be specified in the Exclude Pattern field of the virtual repository (or alternatively, of each remote
repository) using wildcard characters to encapsulate the widest possible specification of internal artifacts.

Avoiding Performance Issues with an Include Pattern
In a typical scenario, Artifactory will reference large all-purpose repositories such as JCenter or Maven Central for resolving artifacts.
In addition, Artifactory may reference any number of additional repositories which may host a more specialized and specific set of of artifacts.

If Artifactory receives a request for a deterministic set of artifacts (e.g. a specific version of an artifact), then it searches through the different
repositories according to its resolution order until the artifact is found.
However, if Artifactory receives a request for a non-deterministic set of artifacts ( e.g. all versions of maven-metadata.xml) then it must search
through all of the repositories it references until it can provide a complete response.
In most cases, the majority of artifacts downloaded by an organization will come from one of the large all-purpose repositories, but in
non-deterministic requests performance is downgraded because Artifactory continues to search through all the specialized repositories b
efore it can return a response.
Best practices using an includes pattern for remote repositories to avoid needless and wasteful search
To avoid performing needless and wasteful search when responding to non-deterministic requests we strongly recommend that all
specialized repositories be configured with an appropriate Include Pattern specifying only the set of artifacts that the organization
might need.
In this case, non-deterministic requests for artifacts that are typically found in general purpose repositories will skip over the specialized
repositories thereby improving performance.

Local and Remote Repositories
In addition to the settings above, Local and Remote repositories share the following settings in the type-specific section for relevant package
types.

Max Unique
Snapshots

Specifies the maximum number of unique snapshots of the same artifact that should be stored. Once this number is reached
and a new snapshot is uploaded, the oldest stored snapshot is removed automatically.
Blank (default) indicates that there is no limit on the number of unique snapshots.
If set, Artifactory allows you to deploy release artifacts into this repository.

Handle
Releases

If set, Artifactory allows you to deploy snapshot artifacts into this repository.
Handle
Snapshots

Local Repositories
Overview
To configure a local repository, in the Admin module, go to Repositories | Local and click it to display the E
dit Repository screen.

Common Basic Settings
The following are fully described in the Common Settings page.

Package Type
Repository Key
Repository Layout
Public Description
Internal Description
Includes and Excludes Pattern
Page Contents
Overview
Common Basic Settings
Additional Basic Settings
Maven, Gradle, Ivy and SBT Repositories
Other Repository Types
Advanced Settings
Replications
Pre-defined Local Repositories

Additional Basic Settings
Repositories may have additional Basic settings depending on the Package Type.

Maven, Gradle, Ivy and SBT Repositories
Maven, Gradle, Ivy and SBT repositories share the same additional Basic settings.

Checksum
Policy

Checking the Checksum effectively verifies the integrity of a deployed resource. The Checksum Policy determines how
Artifactory behaves when a client checksum for a deployed resource is missing or conflicts with the locally calculated
checksum.
There are two options:
1. Verify against client checksums (default) - If a client has not sent a valid checksum for a deployed artifact then
Artifactory will return a 404 (not found) error to a client trying to access that checksum. If the client has sent a checksum,
but it conflicts with the one calculated on the server then Artifactory will return a 409 (conflict) error until a valid checksum
is deployed.
2. Trust server generated checksums - Artifactory will not verify checksums sent by clients and will trust the server's locally
calculated checksums. An uploaded artifact is immediately available for use, but integrity might be compromised.

Maven
Snapshot
Version
Behavior

Artifactory supports centralized control of how snapshots are deployed into a repository, regardless of end user-specific
settings. This can be used to guarantee a standardized format for deployed snapshots within your organization. There are three
options:
1. Unique: Uses a unique, time-based version number
2. Nonunique: Uses the default self-overriding naming pattern: artifactID-version-SNAPSHOT.type
3. Deployer: Uses the format sent by the deployer as is.
Maven 3 Only Supports Unique Snapshots
Maven 3 has dropped support for resolving and deploying non-unique snapshots. Therefore, if you have a snapshot
repository using non-unique snapshots, we recommend that you change your Maven snapshot policy to 'Unique' and
remove any previously deployed snapshots from this repository.
The unique snapshot name generated by the Maven client on deployment cannot help in identifying the source
control changes from which the snapshot was built and has no relation to the time sources were checked out.
Therefore,we recommend that the artifact itself should embed the revision/tag (as part of its name or internally) for
clear and visible revision tracking. Artifactory allows you to tag artifacts with the revision number as part of its Build
Integration support.

Max Unique
Snapshots

Specifies the maximum number of unique snapshots of the same artifact that should be stored. Once this number is reached
and a new snapshot is uploaded, the oldest stored snapshot is removed automatically.
A value of 0 (default) indicates that there is no limit on the number of unique snapshots.
If set, Artifactory allows you to deploy release artifacts into this repository.

Handle
Releases

If set, Artifactory allows you to deploy snapshot artifacts into this repository.
Handle
Snapshots

Suppress
POM
Consistency

When deploying an artifact to a repository, Artifactory verifies that the value set for groupId:artifactId:version in the
POM is consistent with the deployed path.
If there is a conflict between these then Artifcatory will reject the deployment. You can disable this behavior by setting this
checkbox.

Other Repository Types
For other type-specific repository configuration, please refer to the corresponding repository page under Artifactory Pro.

Advanced Settings

Defines the property sets that will be available for artifacts stored in this repository.
Select
Property Sets

Blacked Out

If set, Artifactory ignores this repository when trying to resolve artifacts. The repository is also not available for download or
deployment of artifacts.
If set, allows you to view file contents (e.g., Javadoc browsing, HTML files) directly from Artifactory.

Allow Content
Browsing

Security
When content browsing is allowed we recommend strict content moderation to ensure that any uploaded content
does not compromise security (for example, cross-site scripting attacks)

Replications
The Replications tab lets you define and edit replication settings for the repository. For details, please refer to Repository Replication.

Pre-defined Local Repositories
Artifactory comes with a set of pre-defined local repositories, which reflect best practices in binary repository management as follows:
Your code releases
libs-release-local

Your code snapshots
libs-snapshot-local

Manually deployed 3rd party libs (releases)
ext-release-local

Manually deployed 3rd party libs (shapshots)
ext-snapshot-local

Your and 3rd party plugins (releases)
plugins-release-local

Your and 3rd party plugins (snapshots)
plugins-snapshot-local

Remote Repositories
Overview
To configure a remote repository, in the Admin module, go to Repositories | Remote and click it to display
the Edit Repository screen.

Common Basic Settings
The following are fully described in the Common Settings page.
Package Type
Repository Key
Public Description
Internal Notes
Includes and Excludes Pattern

Additional Basic Settings
The URL for the remote repository. Currently only HTTP and HTTPS URLs are supported.
URL

Offline

If set, this repository will be considered offline and no attempts will be made to fetch artifacts
from it.
For more details, please refer to Single Repository Offline below.

Page Contents
Overview
Common Basic Settings
Additional Basic Settings
Type-Specific Basic Settings
Maven, Gradle, Ivy and SBT Repositories
Other Repository Types
Handling Offline Scenarios
Single Repository Offline
Global Offline Mode

Read More
Managing Proxies
Advanced Settings

Type-Specific Basic Settings
Repositories may have additional Basic settings depending on the Package Type.

Maven, Gradle, Ivy and SBT Repositories

Checksum
Policy

Checking the Checksum effectively verifies the integrity of a deployed resource. The Checksum Policy determines how
Artifactory behaves when a client checksum for a remote resource is missing or conflicts with the locally calculated checksum.
There are four options:
1. Generate if absent (default): Artifactory attempts to retrieve the remote checksum, If it is not found, Artifactory will
automatically generate one and fetch the artifact.
If the remote checksum does not match the locally calculated checksum, the artifact will not be cached and the download
will fail.
2. Fail: If the remote checksum does not mach the locally calculated checksum, or is not found, the artifact will not be cached
and the download will fail.
3. Ignore and generate: Artifactory ignores the remote checksum and only uses the locally generated one. As a result,
remote artifact retrieval never fails, however integrity of the retrieved artifact may be compromised.
4. Ignore and Pass-thru: Artifactory stores and passes through all remote checksums (even if they do not match the locally
generated one). If a remote checksum is not found, Artifactory generates one locally. As a result, remote resource retrieval
never fails, however integrity of the retrieved artifact may be compromised, and client side checksum validation (as
performed by Maven, for example) will fail.
Please refer to Max Unique Snapshots under Local Repositories.

Max Unique
Snapshots

Eagerly
Fetch Jars

Suppress
POM
Consistency

When set, if a POM is requested, Artifactory attempts to fetch the corresponding jar in the background. This will accelerate first
access time to the jar when it is subsequently requested.

By default, Artifactory keeps your repositories healthy by refusing POMs with incorrect coordinates (path). If the groupId:art
ifactId:version information inside the POM does not match the deployed path, Artifactory rejects the deployment with a
"409 Conflict" error.
You can disable this behavior by setting the Suppress POM Consistency checkbox.

Eagerly
Fetch
Sources

When set, if a binaries jar is requested, Artifactory attempts to fetch the corresponding source jar in the background. This will
accelerate first access time to the source jar when it is subsequently requested.

Please refer to Handle Releases under Local Repositories.
Handle
Releases

Please refer to Handle Snapshots under Local Repositories.
Handle
Snapshots

Other Repository Types
For other type-specific repository configuration, please refer to the specific repository page under Artifactory Pro.

Handling Offline Scenarios
Artifactory supports offline repository management at two levels:
Single Repository: One or more specific remote repositories need to be offline.
Global: The whole organization is disconnected from remote repositories

Single Repository Offline
If a remote repository goes offline for any reason, Artifactory can be configured to ignore it by setting the Offline checkbox. In this case, only
artifacts from this repository that are already present in the cache are used. No further attempt will be made to fetch remote artifacts.

Global Offline Mode
This is common in organizations that require a separate, secured network and are disconnected from the rest of the world (for example, military or
financial institutions) .
In this case, remote repositories serve as caches only and do not proxy remote artifacts.
You can enable Global Offline Mode by setting the corresponding checkbox in the Admin tab under Configuration | General.

Managing Proxies
Overview
In corporate environments it is often required to go through a proxy server to access remote resources.
Artifactory supports several types of network proxy including NTLMv2 (if running on Linux you may use
NTLMv2 only with CNTLM).
Page Contents
Overview
Defining Proxies

Defining Proxies
To create a new proxy definition, in the Admin module go to Configuration | Proxies and click the "New" button.
Fields that are not required by the proxy may be left blank (for example, if you are not using authentication credentials or with an NTLM proxy you
may leave the Username and Password fields blank).

Proxy Key

The unique ID of the proxy.

System Default

When set, this proxy will be the default proxy for new remote repositories and for internal HTTP requests issued by
Artifactory.
When you set this checkbox, Artifactory displays a confirmation message and offers to apply the proxy setting also to
existing remote repository configurations.

Host

The name of the proxy host.

Port

The proxy port number.

Username

The proxy username when authentication credentials are required.

Password

The proxy password when authentication credentials are required.

NT Host

The computer name of the machine (the machine connecting to the NTLM proxy).

NT Domain

The proxy domain/realm name.

Redirecting Proxy
target Hosts

An optional list of newline or comma separated host names to which this proxy may redirect requests.
The credentials defined for the proxy are reused by requests redirected to all of these hosts.

Using proxies
Artifactory only accesses a remote repository through a proxy if one is selected in the Network section of the Advanced settings for a
remote repository.
Whether this has been set manually, or by setting a System Default proxy as described above, you can override this by removing the
Proxy setting for any specific repository.
In this case, Artifactory will access the specific repository without going through a proxy.

Advanced Settings
Overview
The advanced settings for a remote repository configure network access behavior, cache management and
several other parameters related to remote repository access.
To access the advanced settings, in the Edit Remote Repository screen select the Advanced tab.

Remote Credentials

Username

The username that should be used for HTTP authentication when accessing this remote
proxy.

Password

The password that should be used for HTTP authentication when accessing this remote
proxy.

SSL/TLS
Certificate

The SSL/TLS certificate this repository should use for authentication to the remote
resource for which it is a proxy.

Page Contents
Overview
Remote Credentials
Network Settings
Cache Settings
Zapping Caches
Select Property Sets
Other Settings

Network Settings

Proxy

If your organization requires you to go through a proxy to access a remote repository, this parameter lets you select the
corresponding Proxy Key.
For more details on setting up proxies in Artifactory please refer to Managing Proxies.

Local Address

When working on multi-homed systems, this parameter lets you specify which specific interface (IP address) should be
used to access the remote repository.
This can be used to ensure that access to the remote repository is not blocked by firewalls or other organizational
security systems.

Socket Timeout

The time that Artifactory waits (for both a socket and a connection) before giving up on an attempt to retrieve an artifact
from a remote repository.
Upon reaching the specified Socket Timeout Artifactory registers the repository as "assumed offline" for the period of
time specified in Assumed Offline Limit.

Query Params

A custom set of parameters that should automatically be included in all HTTP requests to this remote repository.
For example, param1=value1¶m2=value2¶m3=value3

Lenient Host
Authentication

When set, allows using the repository credentials on any host to which the original request is redirected.

Cookie
Management

When set, the repository will allow cookie management to work with servers that require them.

Using Oracle Maven Repository
To use Oracle Maven Repository:
Set your Oracle credentials in Username and Password of the Remote Credentials
Set Lenient Host Authentication

Set Enable Cookie Management.

Cache Settings
Artifactory stores artifacts retrieved from a remote repository in a local cache. The Cache Settings specify how to manage cached artifacts.
Caching Maven artifacts
Caching for Maven artifacts is only applicable to snapshots since it is assumed that releases never change.

Unused
Artifacts
Cleanup
Period

Many cached artifacts in Artifactory remote repository storage are actually unused by any current projects in the organization. This
parameter specifies how long an unused artifact will be stored before it is removed. Once reaching this period Artifacts will be
removed in the next invocation of cleanup. For more details please refer Cleanup Unused Cached Artifacts in Regular
Maintenance Operations.
Leaving the field empty (default) means that the artifact is stored indefinitely.

Metadata
Retrieval
Cache
Period

Defines how long before Artifactory checks for a newer version of a requested artifact in a remote repository.
A value of 0 means that Artifactory will always check for a newer version.
On which file types does this parameter work?
This setting refers to artifacts that expire after a period of time (e.g. metadata files such as maven-metadata.xml, np
m package.json or Docker manifest.json etc.).
Note that most artifacts that are downloaded do not change (e.g. release versions), therefore this setting has no effect
on them.

Assumed
Offline
Period

In case of a connection error, this parameter specifies how long Artifactory should wait before attempting an online check in order
to reset the offline status.
A value of 0 means that the repository is never assumed offline and Artifactory will always attempt to make the connection when
demanded.

Missed
Retrieval
Cache
Period

If a remote repository is missing a requested artifact, Artifactory will return a "404 Not found" error. This response is cached for the
period of time specified by this parameter. During that time, Artifactory will not issue new requests for the same artifact.
A value of 0 means that the response is not cached and Artifactory will always issue a new request when demanded.

Zapping Caches

"Zapping" a cache means forcing the Retrieval Cache Period and Missed Retrieval Cache Period to time out. To "zap" a cache, in the Artifacts m
odule Tree browser,
Select the repository cache you wish to "zap" and click Zap caches in the right-click menu or Actions drop-down menu.

Select Property Sets
Defines the property sets that will be available for artifacts stored in this repository.

Other Settings

Blacked out

If set, Artifactory ignores this repository when trying to resolve artifacts. The repository is also not available for download or
deployment of artifacts.

Allow
content
browsing

When set, allows Artifactory users to browse the internal contents of archives (for example, browsing specific Javadoc files from
within a Javadoc archive).
Care
When archive browsing is allowed, strict content moderation should be employed to ensure malicious users do not
upload content that may compromise security (e.g. cross-site scripting attacks)

Store
artifacts
locally

When set, Artifactory artifacts from this repository will be cached locally. If not set, direct repository-to-client streaming is used.

When might you use direct repository-to-client streaming?
If your organization has multiple servers connected over a high speed LAN, you may have one instance of Artifactory
caching data on a central storage facility with additional instances of Artifactory running on other servers. In this case,
it makes sense for the additional instances of Artifactory to act as satellite pass-through servers rather than have
them duplicate the cached data within their own environments.

Synchronize
properties

When set, synchronizes properties of artifacts retrieved from a remote instance of Artifactory.

Bypass
HEAD
Requests

When set, Artifactory will not send a HEAD request to the remote resource before downloading an artifact for caching

Block
Mismatching
Mime Types

When set, artifacts will fail to download if a mismatch is detected between the requested and received mime type, according to
a list specified in the system.properties file under blockedMismatchingMimeTypes. You can override this setting by
adding mime types to the override list below.

Override
Default
Blocked
Mime Types

The set of mime types that should override the Block Mismatching Mime Types setting.

Propagate
Query
Params

When set, if query params are included in the request to Artifactory, they will be passed on to the remote repository.
Generic Repositories Only
This setting is only available for Generic type repositories.

Smart Remote Repositories
Overview
A smart remote repository is a remote repository that proxies a repository from another instance of
Artifactory. In addition to the usual benefits of remote repositories, smart remote repositories offer several
additional benefits:
Reported download statistics
Artifactory maintains download statistics for repositories so you are able to evaluate if artifacts are still being
used and manage your cleanup policies. When you proxy a repository in another instance of Artifactory, and
cache an artifact downloaded from the other instance, the distant Artifactory is not aware if users on your end
continue to use the artifact (downloading it from your local cache), and may end up cleaning up the original
artifact. An Artifactory Smart Remote Repository lets you notify the distant instance whenever a cached
artifact is downloaded, so it can update an internal counter for remote downloads.
Page Contents
Overview
Configuration
Remote List Browsing

Download statistics may vary between Artifactory instances
Downloads are only reported through the proxy chain from the time this option is set, so the actual download statistics reported for an
artifact may be different in the local Artifactory instance compared the numbers reported in the remote Artifactory instance.
Synchronized properties
When you proxy a repository in another instance of Artifactory and cache an artifact downloaded from it, you may not be aware of changes that
may have been made to the original artifact’s properties if they are done after you cache it. By synchronizing properties, any changes to artifact
properties in the remote instance are propagated to your cached instance of the artifact.
Remote repository browsing
You can browse the contents of the repository in the remote Artifactory instance for all package types, even if none have been cached in your
instance of Artifactory.
Source absence detection
When viewing a cached artifact, Artifactory will indicate if the original artifact in the remote instance has been deleted. This gives you an
opportunity to copy the artifact over from your remote repository cache to a local repository in case you need to maintain access to it.
update an internal counter for remote downloads.

Configuration
To create a Smart Remote Repository, set the repository URL to point to a repository in another instance of Artifactory.
Repository URL must be prefixed with api/
To accommodate different packaging format clients, for several repository types, when accessing the repository through Artifactory, the
repository URL must be prefixed with api/ in the path.
For example,
http://ARTIFACTORY_URL/api//
Or, if you are using Artifactory SaaS the URL would be:
https://.jfrog.io//api//
The prefix is required for the following repository types:
Type

Prefix

Bower

api/bower

CocoaPods

api/pods

Docker

api/docker

NuGet

api/nuget

Npm

api/npm

PyPI

api/pypi

RubyGems

api/gems

Vagrant

api/vagrant

PHP Composer

api/composer

Chef

api/chef

Puppet

api/puppet

Once you have finished entering the URL and move to another field, Artifactory automatically detects that the remote URL is on another instance
of Artifactory and displays a dialog where you can configure the behavior of your smart remote repository.
Note also that the package type icon is overlaid with an Artifactory logo to indicate a smart remote repository.

Report Statistics

If set, Artifactory will notify the remote instance whenever an artifact in the Smart Remote Repository is downloaded locally
so the it can update its download counter.
Note that if this option is not set, there may be a discrepancy between the number of artifacts reported to have been
downloaded in the different Artifactory instances of the proxy chain.

Sync Properties

If set, properties for artifacts that have been cached in this repository will be updated if they are modified in the artifact
hosted at the remote Artifactory instance.
The trigger to synchronize the properties is download of the artifact from the remote repository cache of the local Artifactory
instance.
If set, enables Remote List Browsing.

List Remote
Folder Items

Source Absence
Detection

If set, Artifactory displays an indication on cached items if they have been deleted from the corresponding repository in the
remote Artifactory instance.

You can modify these settings at any time from the Edit Repository screen.

Remote List Browsing
When List Remote Folder Items is checked for a repository, Artifactory lets you navigate the contents of the repository at the remote Artifactory
instance, for all package types, even if the artifacts have not been cached in the repository defined in your instance of Artifactory.

Virtual Repositories
Overview
To simplify access to different repositories, Artifactory allows you to define a virtual repository which is a
collection of local, remote and other virtual repositories accessed through a single logical URL.
A virtual repository hides the access details of the underlying repositories letting users work with a single,
well-known URL. The underlying participating repositories and their access rules may be changed without
requiring any client-side changes.

Page Contents
Overview
Basic Settings
Nesting
Using Includes and Excludes Patterns
Deploying to a Virtual Repository
Advanced Settings
Maven, Gradle, Ivy and SBT Repositories
Pre-defined Repositories

Basic Settings
The following are fully described in the Common Settings page.
Package Type
Repository Key
Repository Layout
Public Description
Internal Description
Includes and Excludes Pattern

In addition, in the Repositories section of the Basic settings screen you select the Available Repositories you want to include in the new virtual
repository and move them to the Selected Repositories list.
This list can be re-ordered by dragging and dropping within the Selected Repositories list.

The Included Repositories section displays the effective list of actual repositories included in this virtual repository. If any of the available
repositories you have selected are themselves virtual repositories, then the Included Repositories section will display the local and remote
repositories included within them. The Included Repository list is automatically updated in case any of the nested virtual repositories change.
The search/resolution order when requesting artifacts from a virtual repository is always:
1. Local repositories
2. Remote repository caches
3. Remote repositories themselves.
The order within these categories is controlled by the order they are presented in the Selected Repositories list.

Nesting
Nesting is a unique feature in Artifactory and facilitates more flexibility in using virtual repositories.
You should take care not to create an "infinite loop" of nested repositories. Artifactory analyzes the internal composition of virtual
repositories and will issue a warning if the virtual repository can not be resolved due to invalid nesting.

Using Includes and Excludes Patterns
The ability to define and Includes Pattern and an Excludes Pattern for virtual repositories (especially when nesting is used) provides a powerful
tool you can use to manage artifact requests in your organization.
For example, your organization may have its own artifacts which are hosted both internally in a local repository, but also in a remote repository.
For optimal performance, you would want these artifacts to be accessed from the local repository rather than from the remote one. To enforce this
policy, you can define a virtual repository called "remote-repos" which includes the full set of remote repositories accessed by your organization,
and then specify an Excludes Pattern with your organization's groupID. in this way, any attempt to access your internal artifact from a remote
repository would be rejected.
Consider another example in which you wish to define a virtual repository for your developers, however you wish to keep certain artifacts hidden
from them. This could be achieved by defining an Excludes Pattern based on groupId, source or version.

Deploying to a Virtual Repository
From version 4.2, Artifactory supports deploying artifacts to a virtual repository. For example you can now use docker push, npm publish,

NuGet push, gem push Artifactory's REST API and more to deploy packages to a virtual repository.
For more details, please refer to Deploying Artifacts.

Advanced Settings

Artifactory
Requests
Can
Retrieve
Remote
Artifacts

An Artifactory instance may request artifacts from a virtual repository in another Artifactory instance. This checkbox specifies
whether the virtual repository should search through remote repositories when trying to resolve an artifact requested by another
Artifactory instance. For example, you can use this feature when Artifactory is deployed in a mesh (grid) architecture, and you
do not want all remote instances of Artifactory to act as proxies for other Artifactory instances.

Maven, Gradle, Ivy and SBT Repositories
In addition to the above checkbox, these repository types offer the following Advanced settings:

Cleanup Repository
References in POMs

Public POMs may include direct references to external repositories. If either of the below code samples are present in
the POM, Maven dynamically adds an external repository URL to the build which circumvents Artifactory.

A client side solution for this is to use mirrorOf. For details please refer to Additional "Mirror-any" Setup.
This setting gives you the ability to ensure Artifactory is the sole provider of Artifacts in your system by automatically
cleaning up the POM file. The three values available for this setting are:

Discard Active
References

Discard Any
References

Removes repository elements that are declared directly under project or under a profile in the
same POM that is activeByDefault

Removes all repository elements regardless of whether they are included in an active profile or
not

Does not remove any repository elements declared in the POM
Nothing

A named key-pair to use for automatically signing artifacts.
Key Pair

Please refer to WebStart and Jar Signing.

Pre-defined Repositories
Artifactory comes with a set of pre-defined virtual repositories, which reflect binary management best practices as follows.
Aggregation of all remote repositories
remote-repos

libs-releases-local, ext-releases and remote-repos
lib-releases

plugins-releases-local, ext-releases and remote-repos
plugins-releases

libs-snapshots-local, ext-snapshots-local, remote-repos
libs-snapshots

plugins-snapshots-local, ext-snapshots-local, remote-repos
plugins-snapshots

Configuring Security
Overview
Artifactory's security model offers protection at several levels. It allows you to do the following:
Assign role-based or user-based permissions to areas in your repositories (called Permission
Targets)
Allow sub-administrators for Permission Targets
Configure LDAP out-of-the-box
Prevent clear text in Maven's settings.xml file
Inspect security definitions for a single artifact or folder and more.

Artifactory's security is based on Spring Security and can be extended and customized.
This section explains the strong security aspects and controls offered by Artifactory.

General Configuration
Artifactory provides several system-wide settings to control access to different resources. These are
found under Security | General in the Administration tab.

Page Contents
Overview
General Configuration
Allow
Anonymous
Access
Prevent
Anonymous
Access to
Build Related
Info
Hide
Existence of
Unauthorized
Resources
Password
Encryption
Policy
User Lock and
Login
Suspension
Temp
orary
Login
Susp
ensio
n
User
Accou
nt
Locki
ng
Unloc
king
User
Accou
nts
Password
Expiration
Policy
Managing API
Keys

Passwords
Encryption

Read More
Managing Users
Managing Permissions
Centrally Secure
Passwords
Master Key Encryption
Managing Security
with LDAP
Managing Security
with Active Directory
Managing Certificates
Using a Self-Signed
Certificate
Access Tokens
Access Log

Allow Anonymous Access
Artifactory provides a detailed and flexible permission-based system to control users' access to different features and artifacts.
However, Artifactory also supports the concept of "Anonymous Access" which controls the features and artifacts available to a user who has not
logged in.
This is done through an "Anonymous User" which comes built-in to Artifactory with a default set of permissions.
Anonymous access may be switched on (default) or off using the Allow Anonymous Access setting under Security General Settings in the Ad
ministration module.
You can modify the set of permissions assigned to the "Anonymous User" just like you would for any other user, and this requires that Allow
Anonymous Access is enabled.

Prevent Anonymous Access to Build Related Info
This setting gives you more control over anonymous access, and allows you to prevent anonymous users from accessing the Build module
where all information related to builds is found, even when anonymous access is enabled.

Hide Existence of Unauthorized Resources
When a user tries to access a resource for which he is not authorized, Artifactory's default behavior is to indicate that the resource exists but is
protected.
For example, an anonymous request will result in a request for authentication (401), and a request by an unauthorized authenticated user will
simply be denied (403).
You can configure Artifactory to return a 404 (instead of 403) - Not Found response in these cases by setting Hide Existence of Unauthorized
Resources under Security | General in the Administration module.

Password Encryption Policy
Artifactory provides a unique solution to support encrypted passwords through the Password Encryption Policy setting as follows:

Supported

Artifactory can receive requests with an encrypted password but will also accept requests with a non-encrypted password
(default)
Artifactory requires an encrypted password for every authenticated request

Required

Artifactory will reject requests with encrypted password
Unsupported

For more details on why Artifactory allows you to enforce password encryption please refer to Centrally Secure Passwords.

User Lock and Login Suspension

User account locking and temporary login suspension are two mechanisms employed by Artifactory to prevent identity theft via brute force attack.

Temporary Login Suspension
Temporary login suspension means that when a login attempt fails due to incorrect authentication credentials being used, Artifactory will
temporarily suspend that user's account for a brief period of time during which Artifactory ignores additional login attempts. If login attempts fail
repeatedly, Artifactory will increase the suspension period each time until it reaches a maximum of 5 seconds.

User Account Locking
In addition to temporary login suspension, you can configure Artifactory to lock a user's account after a specified number of failed login attempts.
This is enabled by checking "Lock User After Exceeding Max Failed Login Attempts", and specifying the Max Failed Login Attempts field. Users
who get locked out of their account because they have exceeded the maximum number of failed login attempts allowed (as specified in Max
Failed Login Attempts) must have an administrator access to unlock their account.

Unlocking User Accounts
An Artifactory administrator can unlock all locked-out users using the "Unlock All Users" button under Security General Configuration screen
where user locking is configured. An administrator can also unlock a specific user or a group of users in the Security Module under User
Management.

Through the REST API, an administrator can unlock a single user, a group of users or all locked-out users at once.

Password Expiration Policy
Artifactory lets an admin user enforce a password expiration policy that forces all users to change their passwords at regular intervals. When the
password expiration policy is enforced, users who do not within the specified time interval will be locked out of their accounts until they change
their password.

When checked, password expiration policy is enabled.
Enable Password Expiration Policy

Specifies how frequently all users must change their password.
Password Expires Every (Days)

Send Mail Notification Before Password
Expiration

When checked, users receive an email notification a few days before their password
expires.

Forces all passwords to expire. All users will have to change their password at next login.
Force Password Expiration For All Users

Managing API Keys
As an admin user, you can revoke all the API keys currently defined in the system under Security | General in the Administration module.

To revoke all API keys in the system, click "Remove API Keys for All Users".
To revoke a specific user's API key, navigate to Administration module >> Security | Users and select the relevant user to edit . Once in the
edit screen one of the available actions is "Revoke API key"
Once you revoke an API key, any REST API calls using that API key will no longer work. The user will have to create new API key and
update any scripts that use it.

Passwords Encryption
Different configuration files in Artifactory may include password information stored in plain text.
If you click "Encrypt", Artifactory will generate a master encryption key and encrypt all passwords.

Managing Users
Overview
You can manage access to repositories by defining users, assigning them to groups and setting up roles and
permissions which can be applied to both users and groups.

Creating and Editing Users
To manage users who can access repositories in your system, in the Admin module, select Security | Users
.

Page Contents
Overview
Creating and Editing Users
Administrator Users
The Anonymous User
Creating and Editing Groups
Default Groups
Admin Privileges for a Group
User Management
Setting Groups for a User
Setting Users for a Group
Recreating the Default Admin User
Obtaining a Security Configuration File
Resetting the Admin Password
Replacing the Security Configuration File
User
Password
Disabling Remember Me at Login

Create a new user by clicking New at the top of the users table.
Only administrators can create users
To create users you must be an administrator (unless you are using external authentication such as LDAP)

In the New User (or Edit User) dialog you can set the User Name, Email Address and Password for the user as well as the following
parameters:
When set, this user is an administrator with all the ensuing privileges. For more details please refer to Administrator Users.
Admin

When set, this user can only access Artifactory through the REST API.
Disable UI
Access

When set, this user can update his profile details (except for the password. Only an administrator can update the password).
Can Update
Profile

There may be cases in which you want to leave this unset to prevent users from updating their profile. For example, a
departmental user with a single password shared between all department members.
When set, disables the fallback of using an internal password when external authentication (such as LDAP) is enabled.

Disable
Internal
Password

Artifactory stores passwords as hashes or encrypted hashes.

If the user has generated an API key, you can revoke it from the Actions menu.

Administrator Users
An administrator user is to Artifactory as a "root" is to UNIX systems. Administrators are not subject to any security restrictions, and we therefore
recommend to create a minimum number of administrators in your system.
You can control which permission-targets administrators have access to thereby assigning responsibility for a specific repository path. For details
please refer to Managing Permissions.
The Default Admin Account
The default user name and password for the built-in administrator user are: admin/password.
You should change the password after first log in. If you forget the admin account password, you can recover it. Please refer to Recreati
ng the Default Admin User.

The Anonymous User
Artifactory supports the concept of anonymous users and installs with a pre-defined anonymous user to which you can assign permissions just
like for any other user.
Anonymous access can be controlled under Security General Configuration. Set Allow Anonymous Access to activate the anonymous user.
The anonymous user must be activated before you can fine tune its permissions.
When anonymous access is activated, anonymous requests can download cached artifacts and populate caches, regardless of other permissions
defined.

Creating and Editing Groups
A group represents a role in Artifactory and is used with RBAC (Role-Based Access Control) rules.
To manage groups, in the Admin module select Security | Groups.

Create a new group by clicking New at the top of the groups table.

You must assign a unique name to each group and can add an optional description

Default Groups
When creating (or editing) a group you can set Automatically Join New Users to this Group.
When this parameter is set, any new users defined in the system are automatically assigned to this group.
This is particularly useful if users are defined automatically and you want them to be assigned to certain groups. For example, when using
external authentication such as LDAP, users are automatically created on successful login and you can use this parameter to assign these users
to particular groups by default.

Admin Privileges for a Group
If Admin Privileges is set, any users added to this group will automatically be assigned with admin privileges in the system.
For reasons of security when Admin Privileges is set, Automatically Join New Users to this Group is disabled so that new users are not
automatically provided with admin privileges.

User Management
There are two ways to manage users' assignment to groups:
1. Setting the groups for a user
2. Setting the users for a group
Setting permissions
In both cases, you can assign corresponding permissions to the user or group respectively on the same screen. For more details please
refer to Managing Permissions.

Setting Groups for a User
You can assign and remove a user from groups when the user is created or by editing user's details later.
In the Admin module, under Security | Users, from the list of users, select the user you wish to assign to or remove from groups.
In the Related Groups section of the form, you can set which groups the user should be assigned to.

Setting Users for a Group
You can assign and remove a users from a group by editing the group's details.
In the Admin module, under Security | Groups, from the list of groups, select the group you wish modify.
In the Users section of the form, you can set which users should be assigned to the group.

Recreating the Default Admin User
If you are unable to obtain administrator access, you will need to recreate the default administrator user in order to be able to manage users of
your system using the following steps::
1. Obtain a security configuration file
2. Reset the admin password
3. Correctly place the security configuration file

Obtaining a Security Configuration File
The security configuration file is called security.xml.
If your instance of Artifactory is configured to perform backups automatically, you can find it in the root backup folder.
If Artifactory is not configured to perform backups automatically you need to force creation of a new security.xml file as follows:
Remove the file $ARTIFACTORY_HOME/data/.deleteForSecurityMarker and restart Artifactory.
Make sure that Artifactory completes the startup sequence without interruption
The security configuration file with the current time stamp can be found in $ARTIFACTORY_HOME/etc/security..xml

Resetting the Admin Password
Reset the admin password as follows:
Make a copy of the security.xml file you obtained in the previous section
In the copy, edit the admin's password field and enter the password hash code (according to your version of Artifactory) as follows:

Admin password hash code
For version 3.x and above:
1f70548d73baca61aab8660733c7de81
For version 2.x: 5f4dcc3b5aa765d61d8327deb882cf99

Replacing the Security Configuration File
Place the modified security configuration file under $ARTIFACTORY_HOME/etc
Rename the file to security.import.xml
Restart Artifactory
Once Artifactory has completed its startup sequence you will be able to login using the default admin user credentials:
admin
User

password
Password

Disabling Remember Me at Login
The Artifactory login screen includes a Remember Me checkbox. If the user sets this checkbox when logging in, Artifactory will store a cookie in
the browser for a period of 7 days allowing the user to be logged in automatically when starting up Artifactory.
Once the cookie expires, the user will have to log in again.

An Artifactory administrator can disable this feature and force all users to enter their credentials at every login. To do so simply add the following
property to $ARTIFACTORY_HOME/etc/artifactory.system.properties and restart Artifactory:

artifactory.security.disableRememberMe=true

Managing Permissions
Overview
Artifactory allows you to control access to repositories via Permission Targets.

A permission target is comprised of a set of physical repositories (i.e. local or remote repositories - but not
virtual ones), and a set of users or groups with a corresponding set of permissions defining how they can
access the specified repositories. Include and Exclude patterns give you finer control over access to a
specific set of artifacts within the repositories of the permission target.
For example, you can create a permission target that allows user "Builder" and group "Deployers" to read
from and deploy artifacts to the libs-releases repository. Using the Include Pattern and Exclude Pattern
settings you could implement finer control over specific artifacts within that repository if so desired.
To manage permissions, in the Admin module go to Security | Permissions.

Page Contents
Overview
Creating a Permission
Target
Permission
Target
Managers
Preventing
Overwriting
Deployments
Examining
Permissions
By Repository
By User or
Group

Creating a Permission Target
To create a Permission Target, in the Permissions Management page click "New" to display the New Permission screen.

Name

You must provide a unique name for each Permission Target (limited to 64 characters).
Repositories

Select the repositories to which this Permission Target applies. You can use the Any Local Repository or Any Remote Repository check
boxes as a convenience.
Include and Exclude Patterns

Using an "Ant-like" expressions, you can specify any number of Include or Exclude Patterns as a comma-separated list in the corresponding entry
field (limited to 1024 characters in total).
In the example above, source files have been excluded from the Permission Target named "Not sources" using the appropriate Exclude Pattern
.
User and Group Permissions

Using the corresponding tabs, you can set the permissions granted to a user or a group. Double-click the user or group you want to modify to add
it to the list of Principals, and then check the permissions you wish to grant.
You cannot add a user or group with admin privileges to a Permission Target
Since an admin is privileged with all permissions, you cannot add a user or group with admin privileges to a Permission Target.

The available permissions are as follows:
Allows changing the permission settings for other users on this permission target
Manage

Allows deletion or overwriting of artifacts
Delete/Overwrite

Allows deploying artifacts and deploying to caches (i.e. populating caches with remote artifacts)
Deploy/Cache

Allows annotating artifacts and folders with metadata and properties
Annotate

Allows reading and downloading of artifacts
Read

Multiple Permissions
Permissions are additive and must be explicitly granted. If a checkbox is not set for a user, then that user does not have the
corresponding permission.

Permission Target Managers
By assigning the Manage permission to a user, you may designate them as the "Permission Target Manager". These users may assign and
modify permissions granted to other users and groups for this Permission Target. In the Artifactory UI these users have access to the specific
users they are allowed to manage. This can be useful on a multi-team site since you can delegate the responsibility of managing specific
repositories to different team members.

Preventing Overwriting Deployments
You can prevent a user or group from overwriting a deployed release or unique snapshot by not granting the Delete permission. Non-unique
snapshots can always be overwritten (provided the Deploy permission is granted).

Examining Permissions
You can examine permissions in the context of repositories, users or groups.

By Repository
In the Artifacts module, select repository you want to view in the Artifact Repository Browser and then select the Effective Permissions tab to
see the permissions granted to users or groups for this repository.

By User or Group
For any user or Group, you can view the list of Permission Targets that it is associated with (whether directly or through membership in a group).
For users, In the Admin module, under Security | Users, select the user you wish to examine. The User Permissions are displayed at the
bottom of the user's page.

You can similarly view Group permissions in the Admin module under Security | Groups.

Centrally Secure Passwords
Overview
Some tools use cleartext passwords, which can pose a security risk. The security risk is even greater if you
use LDAP or other external authentication, since you expose your SSO password in cleartext and that
password is likely to be used for other services, not just Artifactory.
For example, Maven uses cleartext passwords in the settings.xml file by default.
Using Maven's built-in support for encrypted passwords and generating passwords on the client side does
not overcome the security risks for the following reasons:

1. The login password is decrypted on the client side and ends up as cleartext in memory, and then
transmitted over the wire (unless forcing SSL too).
2. The master password used for decryption is stored in clear text on the file system.
3. Password encryption is left to the good will of the end-user and there is no way to centrally mandate
it.
Artifactory provides a unique solution to this problem by generating encrypted passwords for users based on
secret keys stored in Artifactory. You can ensure users' shared passwords are never stored or transmitted as
clear text.
Page Contents
Overview
Using Your Secure
Password

You can set a central policy for using or accepting encrypted passwords in the Admin module under Security | General by setting the Password
Encryption Policy field.

The behavior according to the Password Encryption Policy setting is as follows:
Artifactory can receive requests with encrypted password (default).
Supported

Artifactory requires an encrypted password for every authenticated request.
Required

Artifactory will reject requests with encrypted password.
Unsupported

Using Your Secure Password
To secure your password:
1. Open your profile page (click on your login name on the upper-right corner), type-in your password in the Current Password field and
click Unlock.

2. Once your profile is unlocked, click the corresponding icons next to your encrypted password to view it openly or copy it to the clipboard.

Different encryption mechanisms
The encryption mechanisms of the Oracle and IBM JDKs are not identical. Switching from one to another will make your encrypted
password obsolete

IBM JDK Encryption Restrictions
Some of the IBM JRE/JDK are shipped with a restriction on the encryption key size (mostly for countries outside the US); This
restriction can be officially removed by downloading unrestricted policy files from IBM and overriding the existing ones:
1. Register and download the unrestricted JCE policy files from the IBM website.
2. Select the correct zip that matches your JAVA version.
3. The downloaded zip file contains 2 jar files - local_policy.jar and US_export_policy.jar. Backup the existing files in
$IBM_JDK_HOME/jre/lib/security and extract the jars from the zip file to this location
4. Restart Artifactory

Master Key Encryption
Overview
The global Artifactory configuration file stores the various passwords that are needed in order to interface
with your organizations systems and external repositories. For example, Artifactory may need your LDAP
server password.
In order to keep these passwords secure, you can choose to store them in an encrypted format. In this case,
Artifactory will generate a Master Encryption Key which will be used to encrypt these passwords for storage
and display, and to decrypt them when you need to access the corresponding resources.
IBM JDK Encryption Restrictions
Users of the IBM JDK should read about IBM JDK encryption restrictions described in Using Your
Secure Password.

Page Contents
Overview
Encrypting Passwords

Decrypting Passwords
Exporting and Importing the Master Key
Master Key File Location

Encrypting Passwords
When Master Key Encryption is activated all current passwords in the global configuration file are encrypted, and any new passwords, or updates
will also be encrypted automatically.
By default Artifactory is configured to encrypt passwords. An Artifactory administrator can activate and deactivate encryption by either using the R
EST API, or through the Artifactory UI in the Admin module under Security | General.

Once Master Key Encryption is activated, subsequent activation using the REST API are ignored.

Decrypting Passwords
An Artifactory administrator can deactivate encryption, and decrypt any currently encrypted passwords by either using the REST API, or through
the Artifactory UI in the Admin module under Security | General.
When you select Decrypt, all passwords in the global configuration file are decrypted, the configuration is reloaded and the current Master Key is
removed.
Any new passwords entered, or passwords updated will not be encrypted.

Exporting and Importing the Master Key
If the Master Key is in its default location under the $ARTIFACTORY_HOME/etc folder, it will be exported during a system backup or full system
export.
Correspondingly, if a Master Key was exported, and you now perform a full system import, the key will be copied to the default location and the
Master Key Encryption feature will be activated. i.e. the Master Key will be used to encrypt and decrypt the imported configuration.

Master Key File Location
By default, the Master Key file is located under $ARTIFACTORY_HOME/etc/security/artifactory.key.
You may wish to exercise more stringent security so that the master key file is in a more secure location.

In this case you can change the file location by modifying the artifactory.security.master.key property in the artifactory.system
.properties file.
For example,

Modifying the default master key file location
artifactory.security.master.key=/artifactory.key

If you use a partial path, then it will be interpreted as relative to the $ARTIFACTORY_HOME/etc folder.
If you change the Master Key file location, it will not be exported automatically. It is up to the administrator to back it up along with the export, and
restore it manually on an import.

Managing Security with LDAP
Introduction
Artifactory supports authenticating users against an LDAP server out-of-the-box.
When LDAP authentication is active, Artifactory first attempts to authenticate the user against the LDAP
server. If LDAP authentication fails, Artifactory tries to authenticate via its internal database.
For every LDAP authenticated user Artifactory creates a new user in the internal database (provided the user
does not already exist), and automatically assigns that user to the default groups.
Managing Permissions for LDAP Groups
Artifactory can synchronize your LDAP groups and leverage your existing organizational structure
when managing group-based permissions. LDAP groups in Artifactory use super-fast caching and
support Static, Dynamic and Hierarchical mapping strategies.
Powerful management is accomplished with multiple, switchable LDAP settings and visual
feedback about the up-to-date status of groups and users coming from LDAP.
The LDAP Groups feature is bundled as one of the Add-ons included in Artifactory Pro.
For full details on how to synchronize your LDAP Groups with Artifactory, please refer to LDAP
Groups.

Using Active Directory?
If you are using Active Directory to authenticate users, please refer to Managing Security with
Active Directory.

Page Contents
Introduction
Configuration
Non-UI Authentication Cache
Avoiding Clear Text Passwords
Preventing Authentication Fallback to the Local Artifactory Realm
Using LDAPS (Secure LDAP)
Watch the Screencast

Configuration

To configure LDAP authentication, in the Admin module go to Security | LDAP and click New.

The configuration parameters for LDAP connection settings are as follows:
The unique ID of the LDAP setting.
Settings Name

When set, these settings are enabled.
Enabled

Location of the LDAP server in the following format: ldap://myserver:myport/dc=sampledomain,dc=com.
LDAP URL

Auto Create Artifactory
Users

The URL should include the base DN used to search for and/or authenticate users.
When set, Artifactory will automatically create new users for those who have logged in using LDAP, and assign
them to the default groups.

When set, users created after logging in using LDAP will be able to access their profile page in Artifactory.
Allow Created Users
Access To Profile Page

User DN Pattern

A DN pattern used to log users directly in to the LDAP database. This pattern is used to create a DN string for
"direct" user authentication, and is relative to the base DN in the LDAP URL.
The pattern argument {0} is replaced with the username at runtime. This only works if anonymous binding is
allowed and a direct user DN can be used (which is not the default case for Active Directory).
For example:
uid={0},ou=People
An attribute that can be used to map a user's email to a user created automatically by Artifactory.

Email Attribute

Search Filter

A filter expression used to search for the user DN that is used in LDAP authentication.
This is an LDAP search filter (as defined in 'RFC 2254') with optional arguments. In this case, the username is the
only argument, denoted by '{0}'.
Possible examples are:
uid={0}) - this would search for a username match on the uid attribute.
Authentication using LDAP is performed from the DN found if successful.

Search Base

The Context name in which to search relative to the base DN in the LDAP URL. Multiple search bases may be
specified separated by a pipe ( | ). This is parameter is optional.

Manager DN

The full DN of a user with permissions that allow querying the LDAP server. When working with LDAP Groups, the
user should have permissions for any extra group attributes such as memberOf.
The password of the user binding to the LDAP server when using "search" authentication.

Manager Password

When set, enables deep search through the sub-tree of the LDAP URL + Search Base. True by default.
Search Sub Tree

Non-UI Authentication Cache
You can configure Artifactory to cache data about authentication against external systems such as LDAP for REST API requests. This means that
the first time a user needs to be authenticated, Artifactory will query the external system for the user's permissions, group settings etc.
The information received from the external system is cached for a period of time which you can configure in the $ARTIFACTORY_HOME/etc/art
ifactory.system.properties file by setting the artifactory.security.authentication.cache.idleTimeSecs property.
This means that once a user is authenticated, while the authentication data is cached, Artifactory will use the cached data rather than querying the
external system, so authentication is much faster
By default this is set to 300sec.
REST API Only
The cache is only relevant for REST API requests, and is not relevant when using the Artifactory UI.

Avoiding Clear Text Passwords
Storing your LDAP password in clear text in settings.xml on your disk is a big security threat, since this password is very sensitive and is used

in SSO to other resources in the domain.
When using LDAP, we strongly recommend, using Artifactory's Encrypted Passwords in your local settings.

Preventing Authentication Fallback to the Local Artifactory Realm
In some cases, as an administrator you may want to require users to authenticate themselves through LDAP with their LDAP password.
However, if a user already has an internal account with a password in Artifactory, Artifactory can fallback to use his internal password if LDAP
authentication fails.

You can prevent this fallback authentication by ensuring that the Disable Internal Password checkbox in the Edit
User dialog is set.

Using LDAPS (Secure LDAP)
To use LDAPS with a valid certificate from a CA trusted by Java, all you need to do us use a secure LDAP URL in your settings, e.g. ldaps://s
ecure_ldap_host:636/dc=sampledomain,dc=com.
If you want to use LDAPS with a non-trusted (self-signed) certificate, please follow the steps described in Using a Self-Signed Certificate.

Watch the Screencast

Managing Security with Active Directory
Introduction
Artifactory supports integration with an Active Directory server to authenticate users and synchronize groups.
When authentication using Active Directory is configured and active, Artifactory first attempts to authenticate
the user against the Active Directory server. If the authentication fails, Artifactory tries to authenticate via its
internal database.
For every externally authenticated user configured in your Active Directory server, Artifactory creates a new
user in the internal database (provided the user does not already exist), and automatically assigns that user
to the default groups.
Page Contents
Introduction
Working With Active
Directory
Importing Active
Directory Groups
Support for
Nested
Groups
Using Secure Active
Directory

Working With Active Directory
We will describe how to configure Artifactory to work with Active Directory using an example.
Consider an Active Directory server that must support the following conditions:
Users are located in two geographically separated sites. Some are in the US (designated as "us"), while others are in Israel (designated
as "il").
Each site defines users and groups in different places in the Active Directory tree as displayed below.

To configure Active Directory authentication, in the Admin module, go to Security | LDAP and click New.

The configuration parameters are as follows:
The unique ID of the Active Directory setting.
Settings
Name

When set, these settings are enabled.
Enabled

Active
Directory
URL

Location of the Active Directory server LDAP access point in the following format: ldap://myserver:myport/dc=sampledo
main,dc=com.
The URL may include the base DN used to search for and/or authenticate users. If not specified, the Search Base field is
required.
A DN pattern used to log users directlyin tothe LDAP database.

User DN
Pattern

For Active Directory, we recommend leaving this field blank since this only works if anonymous binding is allowed and a direct
user DN can be used, which is not the default case in Active Directory.

Auto
Create
Artifactory
Users

When set, Artifactory will automatically create new users for those who have logged in using Active Directory. Any newly created
users will be associated to the default groups.

An attribute that can be used to map a user's email to a user created automatically by Artifactory.
Email
Attribute

This corresponds to the mail field in Active Directory.

Search
Filter

A filter expression used to search for the user DN that is used in Active Directory authentication.
This is an LDAP search filter (as defined in 'RFC 2254') with optional arguments. In this case, the username is the only
argument, denoted by '{0}'.
For Active Directorythe corresponding field should be sAMAccountName={0}.

Search
Base

The Context name in which to search relative to the base DN in the Active Directory URL. This parameter is optional, but if
possible, we highly recommend that you set it to prevent long searches on the Active Directory tree. Leaving this field blank will
significantly slow down the Active Directory integration.
The configuration in the example below indicates that search should only be performed under "frogs/il" or "frogs/us". This
improves search performance since Artifactory will not search outside the scope of the "frogs" entry.

Manager
DN

The full DN of a user with permissions that allow querying the Active Directory server. When working with LDAP Groups, the user
should have permissions for any extra group attributes such as memberOf.

The password of the user binding to the Active Directory server when using "search" authentication.
Manager
Password

When set, enables deep search through the sub-tree of the Active Directory URL + Search Base. True by default.
Search
Sub Tree

Importing Active Directory Groups
Active Directory groups can be imported using either a Static mapping strategy or a Dynamic one (Active Directory works for both).
The only difference is in the attribute defined on the corresponding Active Directory entry:
The Static mapping strategy defines a "member" multi-value attribute on the group entry containing user DNs of the group members
The "Dynamic" configuration defines a "memberOf" multi-value attribute on the user entry containing group DNs of the groups the user is
a member of.
Active Directory supports both configurations, so you can choose the one which fits your organization's structure.

Support for Nested Groups
Artifactory supports synchronization with Active Directory "Nested Groups".
Microsoft provides a unique OID for rule chain matching as part of the search filter syntax, so when executing an LDAP Query to Active Directory
using this OID, Active Directory returns a list of all the groups that a user's main group membership inherits from.
The screenshot below shows the following example:
Mapping Strategy: Static
Group Membership Attribute: member:1.2.840.113556.1.4.1941:
Group Name Attribute: cn
Filter: (objectClass=group)

Using Secure Active Directory
To use Secure Active Directory with a valid certificate from a CA trusted by Java, all you need to do us use a secure Active Directory URL in your
settings, e.g. ldaps://secure_ldap_host:636/dc=sampledomain,dc=com.
If you want to use Secure Active Directory with a non-trusted (self-signed) certificate, please follow the steps described in Using a Self-Signed
Certificate.

Manager DN

To construct the Manager DN string according to your
Active Directory server, navigate to a user with
administrator privileges (e.g. Administrator (1)), and
then construct the Manager DN in reverse order (2,3)
from the User, up the folder hierarchy.
For example, in this simple configuration, the Manager
DN here should be
cn=Administrator,cn=Users,dc=alljfrog,dc=org
Notice that the domain (3) is split in reverse order to
dc=alljfrog,dc=org

Managing Certificates
Overview
Some remote repositories (e.g. Red Hat Networks) block access from clients that are not
authenticated with an SSL/TLS certificate. Therefore, to use a remote repository to proxy such
resources, Artifactory must be equipped with the corresponding SSL/TLS certificate.
To support this requirement when needed, from version 5.4, Artifactory lets you manage certificates
and configure them for use by remote repositories.

Page Contents
Overview
Adding
Certificates
Using a
Certificate with
a Remote
Repository
Proxying a
Resource that
Uses a
Self-Signed
Certificates
REST API
Get
Certific
ates
Add
Certific
ate
Delete
Certific
ate

Adding Certificates
Certificates are managed in the Admin module under Security | Certificates.
A certificate entered into this module should be a PEM file that includes both a private key and its corresponding certificate.

To add a new certificate, click New.

Provide the Certificate Alias and copy the certificate contents into the designated area. Alternatively, you can drag and drop the
corresponding PEM file into the designated area.
To avoid text errors, we recommend dragging and dropping the PEM file into the designated area

Password-protected PEM files are not supported
Make sure the PEM file you upload is not password-protected.

Using a Certificate with a Remote Repository
When a remote repository proxy's a resource that requires authentication with a certificate, you need to obtain the certificate from the
resource's owner and add it to the list of certificates as described above.
Under the remote repository's Other Settings, select the certificate you want to use from the list provided in the SSL/TLS Certificate field.

Proxying a Resource that Uses a Self-Signed Certificates
If the remote resource that your Artifactory remote repository is proxying (e.g. Red Hat Network's server) uses an untrusted server certificate
(i.e. it is self-signed and not signed by any known Certificate Authority), you need to import the server's certificate into Artifactory's JVM
truststore. To learn more about configuring a Self-Signed Certificate in Artifactory, please refer to Using a Self-Signed Certificate.

You cannot configure a self-signed certificate in Artifactory SaaS
If you are using Artifactory SaaS (as opposed to an on-prem installation), you will not be able to proxy resources that use untrusted
(i.e. self-signed) certificates since you do not have access to the Artifactory SaaS JVM truststore.

REST API
Artifactory supports automated management of certificates using the REST API endpoints described below

Get Certificates
Gets a list of installed SSL certificates.
For details, refer to the REST API documentation for Get Certificates.

Add Certificate
Installs a new SSL certificate.
For details, refer to the REST API documentation for Add Certificate.

Delete Certificate
Deletes the specified certificate.
For details, refer to the REST API documentation for Delete Certificate.

Using a Self-Signed Certificate
Overview
For several security features that you want to use over a secure connection (such as LDAPS, Secure Active
Directory, or Secure OAuth), you may configure Artifactory to allow a non-trusted self-signed certificate
Page Contents
Overview
Configuring a Self-Signed Certificate

Configuring a Self-Signed Certificate
For outbound Artifactory connections (remote repositories, external authentication servers...) intended for SSL self-signed/internal CA signed
certificates URL endpoints, you may use use one of the following ways to establish trusts based on your certificates:
Use the instructions described on Oracle's documentation to import a single/chain of certificates to your JVM's keystore.
Point Artifactory to use a custom certificate store. Follow the steps below (thanks to Marc Schoechlin for providing this information):
1. Download/acquire the certificate(s) of the SSL secured server openssl s_client -connect -showcerts < /dev/null > server.ca
Examples
LDAP or Active Directory:
openssl s_client -connect the.ldap.server.net:636 -showcerts < /dev/null > server.ca
OAuth (Use the Authorization URL). For example, with GitHub:
openssl s_client -connect github.com:443/login/oauth/authorize -showcerts < /dev/null > server.ca
2. Identify the CA certificate and keep only the ascii-text between BEGIN/END CERTIFICATE maker
3.

3. Identify the standard cacerts file of your Java installation
4. Create a custom cacerts file by copying the cacerts file to the Artifactory configuration dir, e.g.
cp /usr/lib64/jvm/java-1_6_0-ibm-1.6.0/jre/lib/security/cacerts /etc/opt/jfrog/artifactory/
5. Import the CA certificate into the customized cacerts file
keytool -import -alias myca -keystore /etc/opt/jfrog/artifactory/cacerts -trustcacerts -file
server.ca
=> Password: changeit
=> Agree to add the certificate
6. Change permissions for the artifactory user
chmod 755 /etc/opt/jfrog/artifactory/cacerts
chown artifactory:users /etc/opt/jfrog/artifactory/cacerts
7. Modify the defaults of the Artifactory JVM to use the custom cacerts file
echo "export JAVA_OPTIONS=\"\$JAVA_OPTIONS
-Djavax.net.ssl.trustStore=/etc/opt/jfrog/artifactory/cacerts\"" >>
/etc/opt/jfrog/artifactory/default
8. Restart Artifactory

Access Tokens
Overview
From version 5.0, Artifactory offers access tokens as a new and flexible means of authentication
with a range of capabilities previously unavailable:
Cross-instance authentication
Access tokens can be used for authentication, not only by the Artifactory instance or
cluster where they were created, but also for other instances and clusters that are all part
of the same "circle of trust" (described below).
User and non-user authentication
The case for authenticating Artifactory users is clear, however access tokens can also be
assigned to non-user entities such as CI server jobs.
Time-based access control
Access tokens have an expiry period so you can control the period of time for which you
grant access. However, you may also delegate that control to the receiving user by making
them refreshable
Flexible scope
By assigning Groups to tokens, you can control the level of access they provide.

To support these capabilities, an access token has the following properties:

Subject

Issuer

Scope

The user to which this access token is
associated. If the user specified does not exist,
Artifactory will create a corresponding transient
user. Artifactory administrators can assign a
token to any subject (user); non-admin users
who create tokens can only assign tokens to
themselves.
An identifier of the cluster on which the access
token was created
The scope of access that the token provides.
Access to the REST API is always provided by
default; in addition, you may specify the group
memberships that the token
provides. Artifactory administrators can set any
scope; non-admin users can only set the
scope to a subset of the groups to which they
belong.

Page Contents
Overview
Access Service
Access Service
Logs
Configu
ring
Loggin
g
Cross-Instance
Authentication
Setting the
Private Key and
Root Certificate
New
Instanc
es
Existing
Instanc
es
Using Tokens
Basic
Authentication
Authorization
Headers
Support Authentication
for Non-Existing Users
Generating Expirable
Tokens
Generating Refreshable
Tokens
Generating Admin
Tokens
Revoking Tokens
REST API
Create Token
Refresh Token
Revoke Token
Get Service ID
UI
Troubleshooting

The period of time from creation after which
the token will expire. Artifactory administrators
can set any expiry period; non-admin users
can not change the expiry period so tokens
they create expire after the default period of 60
minutes.

Expiry

Whether the token may be refreshed for
continued use or not

Refreshable

The set of Artifactory instances or clusters on
which the token may be used identified by their
Service IDs. The Service ID is a unique,
internally generated identifier of an Artifactory
instance or cluster and is obtained through Get
Service ID REST API endpoint.

Audience

Access tokens are fully managed through REST API as described below.

Access Service
From Artifactory version 5.4, access tokens are managed under a new service called Access which is implemented in a separate WAR file, a
ccess.war. This change has no impact on how access tokens are used, however, the Artifactory installation file structure now also includes
the added WAR file under the $ARTIFACTORY_HOME/webapps folder. Artifactory communicates with the Access service over HTTP and
assumes it is running in the same Tomcat using the context path of "access".
The new implementation is backwards compatible to old tokens, so you can still use tokens generated by an older version to authenticate in
the new version, however, you cannot use tokens generated by the new version to authenticate in an older version.
Breaking Change: Note that the change is not forwards compatible, so tokens created from version 5.4 and above cannot be used for
authentication with versions previous to 5.4. This may impact a circle of trust in which some instances are running versions below 5.4 while
others are running version 5.4 and above.

Access Service Logs
The Artifactory Access Service uses the Logback Framework to manage logging. Activity is logged according to type in three different log files
which can be found under the ARTIFACTORY_HOME/access/logs folder.
The following log files are available:
This is the main Access service log file containing data on the Access server activity
access.log

The HTTP traffic information for requests coming in. Most of these are from Artifactory
request.log

audit.log

Auditing of the actions performed by the service. Currently only successful actions are recorded (e.g. token was created,
token was refreshed or revoked)

Since the Access service runs under the same Tomcat as Artifactory, its logs (catalina.out. localhost etc.) contains entries for both Artifactory
and Access.
Configuring Logging

Logging for the Access service is configured in the $ARTIFACTORY_HOME/access/etc/logback.xml file.

Cross-Instance Authentication
Access tokens support cross-instance authentication through a "circle of trust" established by sharing a private and public key pair among all
participating instances. It is up to the Artifactory administrator to make sure that all participating instances are equipped with the same key
pair. This means that any instance can generate a token to be used with any other instance within the circle of trust. When an Artifactory
instance receives a REST API call authenticated by a signed token, it will use the root certificate that includes the public key to verify that its
issuer is in the circle of trust.
Limitations
Only a token that is expirable and refreshable can be used for authentication on a different instance from the one that created it.

Only the issuing instance can refresh a token.

Setting the Private Key and Root Certificate
As mentioned above, it is up to the Artifactory administrator to make sure that all participating instances are equipped with the same key pair.
The process to ensure this varies depending on whether you are bootstrapping new instances or setting up cross-instance authentication for
existing instances.
New Instances
Artifactory Pro or OSS

1. Start up the first Artifactory instance (or cluster node for an HA installation) that will be in your circle of trust. A private key and root
certificate are generated and stored under $ARTIFACTORY_HOME/access/etc/keys.
2. Copy the private key and root certificate files to a location on your file system that is accessible by all other instances/nodes that are
in your circle of trust.
3. Before bootstrapping, for each of the other instances/nodes, create the $ARTIFACTORY_HOME/access/etc folder and create a
properties file in it called access.bootstrap.config with the following contents:

key=/path/to/private.key
crt=/path/to/root.crt

4. When each instance/node starts up, if the $ARTIFACTORY_HOME/access/etc/access.bootstrap.config file exists, then the
private key and root certificate are copied from the specified location into the server's home directory under $ARTIFACTORY_HOME
/access/etc/keys.
Artifactory HA

In the case of an Artifactory HA installation, the private key and root certificate are included in the bootstrap bundle.
Existing Instances

Key rotation will invalidate any issued access tokens
The procedure below will create new key pairs which in turn will invalidate any existing Access Tokens issued by the current
instance.
1. Copy the private key and root certificate files from the Artifactory instance whose circle of trust you want the current instance to join,
to a location on your file system that is accessible by the current instance.
2. Before bootstrapping the instance:
a. Delete the existing private key and root certificate files (private.key and root.crt) from the $ARTIFACTORY_HOME/ac
cess/etc folder.
b. Create the $ARTIFACTORY_HOME/access/etc/access.bootstrap.config with the following contents:

key=/path/to/private.key
crt=/path/to/root.crt

c. Add the following JVM property (under the JAVA_OPTIONS enviroment variable) to $ARTIFACTORY_HOME/bin/artifac
tory.default:

-Djfrog.access.force.replace.existing.root.keys=true

d. Start up the instance ready to be added to your circle of trust and verify that the
artifactory.log file shows the following entry:

**************************************************************
*****
*** Forcing replacement of the root private key and
certificate ***
**************************************************************
*****

e. Delete the JVM property you added to $ARTIFACTORY_HOME/bin/artifactory.default in step c.

Using Tokens
There are several ways you can use access tokens for authentication.

Basic Authentication
An access token can be used instead of a password for basic authentication. This may be useful when you need a client (such as certain
dependency managers) that only supports basic authentication to access Artifactory. In this case, it is important to access Artifactory using
the same user name provided when creating the token (with -d "username=").
For example, to use an access token as a password to ping Artifactory you could use:

curl -u: http://ARTIFACTORY_URL/api/system/ping

Authorization Headers
An access token can be used as a bearer token in authorization headers. This is especially useful for authenticating CI servers with
Artifactory instead of using credentials, since you don't need to have a user defined in Artifactory if the group provided in -d
"member-of-groups:" is configured in that Artifactory instance. As a result, there is no need to manage fictitious users for your
different automation tools that need access to Artifactory.
For example, to use an access token as a bearer token to ping Artifactory you could use:

curl -H"Authorization: Bearer "
http://ARTIFACTORY_URL/api/system/ping

Support Authentication for Non-Existing Users
One of the big advantages of access tokens is the fact that you don't have to create a user in Artifactory to use them. When creating a token,

you can specify a user name that does not exist, and Artifactory will create a transient user that will only exist as long as the token is valid.
This can be useful to in giving access to different tools such as a CI server coordinating a build without having to manage fake user accounts.
This method is also more secure since you can assign a new token for each "job" that the external tool runs.
Artifactory Administrator Only
Note that this feature is only available for Artifactory administrator since non-admin users can only create tokens with themselves
as the Subject.

Generating Expirable Tokens
You can limit the validity period of a token by setting the expiry time when generating a token. If set, the token will be valid until the expiration
time will pass.
You can all set a token to be non-expirable by setting the expiry to zero, in which case it will valid indefinitely until actively revoked.
This value is set by using the "&expires_in=" param when generating the token (see example in REST API section
below). If not used the default value will be 3600 meaning your token will be valid for one hour.
Artifactory Administrator Only
Note that only an Artifactory administrator can change the validity period of a token to any value. Non-admin users, can only set
the token validity period to a value that is equal or less than the default 3600 seconds.

Generating Refreshable Tokens
As mentioned above, you can limit the validity period of an token by setting its expiry time. To allow extending access privileges of a token
once it has expired, you can provide a refresh token which will generate a new token with the same privileges as the original one. This takes
token management out of the hands of its issuer and delegates it to the user who received the token.
Who can refresh?
Only the instance (or HA cluster) that issued a refreshable token can actually refresh it.

Limitation
An external user who has created a token will still be able to refresh it even if he has been removed from the external
authentication server.

Generating Admin Tokens
In general, the scope for a token is defined by specifying the groups into which the token is included, however, an Artifactory administrator
can also create a token with admin privileges. This can be useful for JFrog Mission Control and JFrog Xray since both of these
complementary applications require admin permissions to work seamlessly with Artifactory. With this capability, when Mission Control or Xray
connect to an instance of Artifactory, they can create an admin tokens and use that for authentication instead of using basic authentication
with a username and password.

Revoking Tokens
Any refreshable or non-expirable token can be revoked but only by the instance (or cluster) that issued it. A token with an expiry specified will
lapse automatically upon reaching its expiry period (but can also be actively revoked earlier). A token that is not expirable ( expires_in para
meter is set to 0) must be actively revoked to terminate its usage. As described above, to support cross-site authentication, a token must be
both expirable and refreshable. Note that this kind of token cannot be revoked. The only way to terminate its usage is to revoke its refresh
token, so its usage will be terminated next time its expiry period lapses.
"Revoking" a cross-instance authentication token
To terminate usage of a token used for cross-instance authentication, you need to revoke its refresh token.

REST API
All management of access tokens is done via REST API through the endpoints described below.

Create Token
Creates an access token.
For details, refer to the REST API documentation for Create Token.

Refresh Token
Refresh an access token to extend its validity. If only the access token and the refresh token are provided (and no other parameters), this pair
is used for authentication. If username or any other parameter is provided, then the request must be authenticated by a token that grants
admin permissions.
For details, refer to the REST API documentation for Refresh Token.

Revoke Token
Revoke an access token
For details, refer to the REST API documentation for Revoke Token.

Get Service ID
Provides the service ID of an Artifactory instance or cluster
For details, refer to the REST API documentation for Get Service ID.

UI
Admin users can view details on all created Access Tokens in the Admin module under Security | Access Tokens.
The Access Tokens page allows you to view, revoke, search by subject and filter to view only expirable tokens.
Additional functionalities, such as creating new tokens, is done via REST API.

Troubleshooting
An exception is thrown for "java.lang.IllegalStateException: Provided private key and latest private key fingerprints mismatch"

Symptoms

During startup, Artifactory fails to start and an error is thrown:
java.lang.IllegalStateException: Provided private key and latest private key fingerprints mismatch.

Cause

Artifactory tries to validate and compare access keys' fingerprint that reside on Artifactory's database and the local file system. If the keys d
not match, the exception above will be thrown along with the mismatching fingerprint IDs.
This could occur during an attempted upgrade/installation of Artifactory.

Resolution

Follow the steps below to make sure that all instances in your circle of trust have the same private key and root certificate:
Key rotation will invalidate any issued access tokens
The procedure below will create new key pairs which in turn will invalidate any existing Access Tokens.

a. Add the following JVM property (under the JAVA_OPTIONS enviroment variable) to $ARTIFACTORY_HOME/bin/artifactory
efault:

-Djfrog.access.force.replace.existing.root.keys=true

b. Start up the new instance and verify that the $ARTIFACTORY_HOME/logs/artifactory.log or
$ARTIFACTORY_HOME/access/logs/access.log file shows the following entry:

*******************************************************************
*** Forcing replacement of the root private key and certificate ***
*******************************************************************

c. Delete the JVM property you added to $ARTIFACTORY_HOME/bin/artifactory.default in step a.
Following an upgrade of an Artifactory HA cluster node, the node fails to start up.
Symptoms

After correctly following the upgrade procedure, an Artifactory HA cluster node fails to start up

Cause

In Artifactory 5.4, the implementation of access tokens was taken out of the Artifactory WAR file and moved to a
separate WAR file. As a result, your Tomcat's server.xml file needs to be modified.

Resolution

Make sure that your $ARTIFACTORY_HOMEtomcat/conf/server.xml file is configured with 2 start/stop threads as
shown in the example below (see :

The access token I generated is not working
Symptoms

Authentication with an access token doesn't work with an error that says "Token validation failed".

Cause

The implementation of access tokens was changed in Artifactory 5.4. The change is backwards compatible, so tokens
created with earlier versions of Artifactory can be authenticated in the new version, however the reverse is not true.
Tokens created in versions 5.4 or later cannot be authenticated by versions earlier than 5.4.

Resolution

Either upgrade your older Artifactory instances, or make sure you only create access tokens with the older instances.

Access Log
The Artifactory access.log
Artifactory maintains an access log containing all security-related events, their source IP and context. Events
include information on accept/reject of logins, and download, browsing and deployment of artifacts.
The access log is located at $ARTIFACTORY_HOME/logs/access.log.
You can also view and download the access log from the Artifactory UI. In the Admin module go to Advance
d | System Logs.

Page Contents
The Artifactory access.log
Watches

Watches
You can also choose to receive focused information about events for a specific repository section, using the Watches Add-on.

Configuring a Reverse Proxy
Overview
In many cases, an organization may provide access to Artifactory through a reverse proxy such as NGINX or
Apache. In some cases, for example with Docker, this set up is even mandatory. To simplify configuring a
reverse proxy, from version 4.3.1, Artifactory provides a Reverse Proxy Configuration Generator screen in
which you can fill in a set of fields to generate the required configuration snippet which you can then
download and install directly in the corresponding directory of your reverse proxy server. You can also use
the REST API to manage reverse proxy configuration.
If you are using Artifactory behind a reverse proxy, we recommend that you set your Custom URL
Base to match your Artifactory Server Name.

Page Contents
Overview
Reverse Proxy Settings
Docker Reverse Proxy Settings
Using Subdomain
Using Port Bindings
REST API

Reverse Proxy Settings
To configure a reverse proxy, in the Admin module, select Configuration | Reverse Proxy and execute the following steps:
Fill in the fields according to your configuration.
Generate the configuration file. You may click the icons in the top right of the screen to view your configuration (which you may copy) or
download it as a text file.
Place the configuration file in the right place under your reverse proxy server installation and reload the configuration.
Using NGINX? Note these requirements.
To use NGINX as a reverse proxy to work with Docker, you need NGINX v1.3.9 or higher.
The NGINX configuration file should be placed under the sites-enabled directory.
For more details, please refer to Configuring NGINX.

Using Apache? Note these requirements.
Some features in the Apache configuration are only supported from Apache HTTP Server v2.4.
To use Apache as your reverse proxy server, make sure you have the following modules installed and activated:
proxy_http
proxy_ajp
rewrite
deflate
headers

proxy_balancer
proxy_connect
proxy_html
ssl
lbmethod_byrequests
slotmem_shm
proxy
Support to generate Apache reverse proxy configuration is available from Artifactory version 4.4.1.
For more details, please refer to Configuring Apache.

Best practice
When using a reverse proxy, we recommend passing it the X-Artifactory-Override-Base-Url header as follows:
For NGINX:
proxy_set_header X-Artifactory-Override-Base-Url
port>/

$http_x_forwarded_proto://$:/

The reverse proxy type.
Web
Server
Type

Artifactory
Server
Name

The internal server name for Artifactory. If the Web Server is installed on the same machine as Artifactory you can use localhost,
otherwise use the IP address or the machine name.

The port configured for Artifactory. The default value is 8081.
Artifactory
Port

The path which will be used to access Artifactory. If Artifactory is accessible at the root of the server, leave this field empty.
Artifactory
Context
Path

Balance
Members
(Apache)
Upstream
Name
(NGINX)

Only available in an Artifactory HA installation. Defines the group of servers in the HA cluster for load balancing. (default:
artifactory).
For more details, please refer to the NGINX documentation or Apache documentation accordingly.
Multiple Artifactory instances under the same domain
If using multiple Artifactory instances under the same domain, e.g. artdev.mycompany.org and artprod.mycompany.org
you must assign a different names for balance members / upstream name to each cluster configuration since the
session cockies will be avilable to both clusters and can cause an issue if trying to access both clusters in the same
time.

The server name which will be publicly used to access Artifactory within the organization.
Public
Server
Name

Public
Context
Path

The path which will be publicly used to access Artifactory. If Artifactory is accessible on the root of the server leave this field
empty.

You can configure access to Artifactory via HTTP, HTTPS or both (at least one is required). For each of these check boxes that you set, you need
to fill in the corresponding fields as follows:

When set, Artifactory will be accessible via HTTP at the corresponding port that is set.
Use HTTP

The port for access via HTTP. The default value is 80.
HTTP Port

When set, Artifactory will be accessible via HTTPS at the corresponding port that is set.
Use HTTPS

The port for access via HTTPS. The default value is 443.
HTTPS Port

The full path to the key file for access via HTTPS.
SSL Key Path

The full path to the certificate file for access via HTTPS.
SSL Certificate Path

Docker Reverse Proxy Settings
When using Artifactory as a private Docker registry, the Docker client can only access Artifactory through a reverse proxy (Artifactory SaaS is an
exception since it is external to your organization). Therefore, your Docker repositories must be configured with the corresponding Reverse Proxy
settings in the Docker Repository Configuration Advanced tab. The Reverse Proxy Configuration screen also sets up your Docker
Repository configuration.
There are two ways to configure Docker repositories to work with a reverse proxy: Port bindings or Subdomain.

Using Subdomain
If you select Subdomain as the Reverse Proxy Method, when configuring a Docker Repository, the Registry Name in the Docker Repository
Configuration Advanced tab will be set automatically to the required value, and will use the Repository Key as the Subdomain.
Wildcard certificate
Using the Subdomain method requires a Wildcard certificate such as. *.myservername.org. You also need to ensure that the
certificate you use supports the number of levels used in your subdomain.

Docker Reverse Proxy Settings in Reverse Proxy Configuration

Corresponding Reverse Proxy settings in Docker Repository
Advanced Configuration

Using Port Bindings
If you select Port as the Reverse Proxy Method, when configuring a Docker Repository, you will need to set the Registry Port in the Docker
Repository Configuration Advanced tab. Together with the Public Server Name, this is the port the Docker client will use to pull images from
and push images to the repository. Note that in order for all of your Docker repositories to be included in your reverse proxy configuration, you first
you need to set the port for each Docker repository defined in your system, and only then generate the reverse proxy configuration. Note also that
each repository must be bound to a unique port
Best Practice
We recommend creating a Docker Virtual Repository which aggregates all of your other Docker repositories, and use that to pull and pu
sh images. This way you only need to set up the NGINX configuration for that virtual repository.

Docker Reverse Proxy Settings in Reverse Proxy Configuration

Corresponding Reverse Proxy settings in Docker Repository
Advanced Configuration

REST API
Artifactory also supports managing reverse proxy configuration through the REST API using the following endpoints:
Retrieves the reverse proxy configuration JSON.
Get Reverse Proxy Configuration

.Updates the reverse proxy configuration
Update Reverse Proxy Configuration

Gets the reverse proxy configuration snippet in text format.
Get Reverse Proxy Snippet

Configuring Apache
Setting Up Apache HTTP Server
You can set up Apache HTTP Server as a front end to Artifactory using either the HTTP or
AJP protocol.

Client ----------> HTTPD ---------->
Artifactory
HTTP
HTTP/AJP

Using AJP
The AJP protocol offers optimized low-level binary communication between the servlet
container and Apache with additional support for smart-routing and load balancing.
The configuration is flexible and can be used either with mod_proxy_ajp, or with mod_jk.
The example below shows how to configure Apache using mod_proxy_ajp which is distributed
by default, however you need to install and then enable as follows:

Enabling mod_proxy_ajp
sudo a2enmod proxy_ajp

Configuring Apache With mod_proxy_ajp Installed

The sample virtual host below refers to Apache as a reverse proxy to Tomcat, where Tomcat
runs with the AJP connector on port 8019:
Page Contents
Setting Up Apache HTTP Server
Using AJP
Configuring Apache With mod_proxy_ajp Installed
Configuring Your Tomcat
Configuring Apache With a Custom Artifactory Path
Using an HTTP Proxy
Configuring Apache With mod_proxy_ajp Installed
Setting Up Apache HTTPS
Using AJP
Using an HTTP Proxy
Configuring Apache With mod_proxy_ajp Installed and Tomcat
Configuring a Custom URL Base in Artifactory

Configuring Apache with mod_ajp

Reset Your Cookies
When changing the Artifactory context path in Apache make sure to reset your browser's host and session cookies.
Having a stale context path value cached by cookies can lead to inconsistent issue with the user interface such as Not authorized
to instantiate class errors when switching between tabs.

Configuring Your Tomcat

If you are using a dedicated Tomcat rather than the one that is bundled with the Artifactory download zip file, you must configure the AJP
connector located, by default, under $CATALINA_HOME/conf/server.xml:

Configuring a Dedicated Tomcat

Please refer to Apache Tomcat Configuration Reference for more configuration options.
Configuring Apache With a Custom Artifactory Path

You can configure Apache using the same setup as above but here the goal is to have http://artifactory.yourdomain.com/repositor
y/ as the root URL for Artifactory as follows:

Configuring Apache With Your Custom Artifactory Path

ServerAdmin your@email.address.com
DocumentRoot "/srv/www/httpd/htdocs"
ServerName artifactory.yourdomain.com
ErrorLog "logs/artifactory-error_log"
ProxyPreserveHost on
ProxyPass /repository ajp://:8019/artifactory
ProxyPassReverse /repository
http://artifactory.yourdomain.com/artifactory
ProxyPassReverseCookiePath /artifactory /repository

Using an HTTP Proxy
When running Artifactory with Tomcat, we recommend that you set up Apache to proxy Artifactory via HTTP.
You must configure redirects correctly using the PassReverse directive, and also set the base URL in Artifactory itself so that the UI links show up
correctly.
Configuring Apache With mod_proxy_ajp Installed

The sample virtual host assumes that the Tomcat HTTP connector runs on port 8081.
Ensuring HTTP Redirect Works Correctly
For HTTP redirects to work, you must set a PassReverse directive on Apache, otherwise the underlying container base URL is passed
in redirects
In the example below it is set to http://artifactory.yourdomain.com/artifactory/.

Setting a PassReverse Directive on Apache

ServerAdmin your@email.address.com
DocumentRoot "/srv/www/httpd/htdocs"
ServerName artifactory.yourdomain.com
ErrorLog "logs/artifactory-error_log"
ProxyPreserveHost on
ProxyPass /artifactory http://:8081/artifactory
ProxyPassReverse /artifactory
http://artifactory.yourdomain.com/artifactory

Setting Up Apache HTTPS
You can set up Apache with SSL (HTTPS) as a front end to Artifactory using either the HTTP or AJP protocol.

Client ----------> HTTPD ----------> Artifactory
HTTPS
HTTP/AJP

Using AJP
If you are not running Artifactory with Tomcat, then it is recommended to use AJP since it provides the servlet container with all the information
about the correct base URL and requires no configuration in Artifactory.

Using an HTTP Proxy
Configuring Apache With mod_proxy_ajp Installed and Tomcat

The Apache and Tomcat sample configuration is as described in the section on Apache HTTP Server above under Using AJP.
Configuring a Custom URL Base in Artifactory

When using an HTTP proxy, the links produced by Artifactory, as well as certain redirects contain the wrong port and use the http instead of htt
ps.
Therefore, you must configure a custom base URL as follows:
1. On the Admin tab select Configuration | General Custom URL Base field.
2. Set the Custom URL Base field to the value used to contact Artifactory on Apache
For example: https://artifactory.yourdomain.com/artifactory
Please refer to General Configuration for more details about configuring the base URL.

Configuring NGINX
Setting Up the NGINX Server
You can use Artifactory behind an nginx server.

When setting up nginx as a front end to Artifactory it is recommended to use HTTP or HTTPS.

Using HTTP or HTTPS
You must set the base URL in Artifactory itself so that the links in the user interface appear correctly.
In the example below, the configuration assumes that the Tomcat HTTP connector runs on port 8081.
Page Contents
Setting Up the NGINX Server
Using HTTP or HTTPS
Configuring a Custom URL Base in Artifactory
Advanced Tomcat Configuration

Configuring nginx to use HTTP or HTTPS
## add ssl entries when https has been set in config
ssl_certificate
/etc/nginx/ssl/docker.jfrog.com.crt;
ssl_certificate_key /etc/nginx/ssl/docker.jfrog.com.key;
ssl_session_cache shared:SSL:1m;
ssl_prefer_server_ciphers
on;
## server configuration
server {
listen 443 ssl;
listen 80 ;
server_name artifactory.jfrog.com;
if ($http_x_forwarded_proto = '') {
set $http_x_forwarded_proto $scheme;
}
## Application specific logs
## access_log /var/log/nginx/artifactory.jfrog.com-access.log timing;
## error_log /var/log/nginx/artifactory.jfrog.com-error.log;
rewrite ^/$ /artifactory/webapp/ redirect;
rewrite ^/artifactory/?(/webapp)?$ /artifactory/webapp/ redirect;
chunked_transfer_encoding on;
client_max_body_size 0;
location / {
proxy_read_timeout 900;
proxy_pass_header
Server;
proxy_cookie_path
~*^/.* /;
if ( $request_uri ~ ^/artifactory/(.*)$ ) {
proxy_pass
http://:8081/artifactory/$1;
}
proxy_pass
http://rproxy_artifactory:8081/artifactory/;
proxy_set_header
X-Artifactory-Override-Base-Url
$http_x_forwarded_proto://$host:$server_port/;
proxy_set_header
X-Forwarded-Port $server_port;
proxy_set_header
X-Forwarded-Proto $http_x_forwarded_proto;
proxy_set_header
Host
$http_host;
proxy_set_header
X-Forwarded-For
$proxy_add_x_forwarded_for;
}
}

Internal Proxies
Regular expression (using java.util.regex) that a proxy's IP address must match to be considered an internal proxy. Internal
proxies that appear in the remoteIpHeader are trusted and do not appear in the proxiesHeader value.
If not specified, the default value of 10\.\d{1,3}\.\d{1,3}\.\d{1,3}|192\.168\.\d{1,3}\.\d{1,3}|169\.254\.\d{1,3
}\.\d{1,3}|127\.\d{1,3}\.\d{1,3}\.\d{1,3} is used.

Configuring a Custom URL Base in Artifactory
When using an HTTP proxy, the links produced by Artifactory, as well as certain redirects contain the wrong port and use the http instead of htt
ps.

Therefore, you must configure a custom base URL as follows:
1. On the Admin tab select Configuration | General Custom URL Base field.
2. Set the Custom URL Base field to the value used to contact Artifactory on Apache
For example: https://artifactory.yourdomain.com/artifactory
Please refer to General Configuration for more details about configuring the base URL.

Advanced Tomcat Configuration
On Tomcat you may modify your HTTP connector configuration to support advanced capabilities, for example:

Configuring the HTTP connector

HTTP connector location
By default, the HTTP Connector can be found in $CATALINA_HOME/conf/server.xml

Mail Server Configuration
Overview
Artifactory supports sending mail to notify administrators and other users for significant events that happen in
your system.
Some examples are:
Watch notifications
Alerts for backup warnings and errors
License violation notifications
To enable mail notifications, you need to configure Artifactory with your mail server details as described
below.
Page Contents
Overview
Setup

Setup
To access the mail server configuration, in the Admin module select Configuration | Mail.
Setup is straightforward and can be verified by sending a test message. Simply click "Send Test Mail" in the Configure Mail screen.

When set, mail notifications are enabled
Enabled

The host name of the mail server
Host

The port of the mail server
Port

The username for authentication with the mail server
Username

The password for authentication with the mail server
Password

The "from" address header to use in all outgoing mails.
From (optional)

A prefix to use for the subject of all outgoing mails
Subject Prefix

The Artifactory URL to use in all outgoing mails to denote links to Artifactory.
Artifactory URL (optional)

When set, uses Transport Layer Security when connecting to the mail server
Use TLS

When set, uses a secure connection to the mail server
Use SSL

The email address of a recipient to receive a test message
Test Message Recipient

Configuration Files
All Artifactory configuration files are located under the $ARTIFACTORY_HOME/etc folder.
On Linux, Solaris and MacOS $ARTIFACTORY_HOME is usually a soft link to /etc/artifact
ory.

Global Configuration Descriptor
The global Artifactory configuration file is used to provide a default set of configuration
parameters.
The file is located in $ARTIFACTORY_HOME/etc/artifactory.config.xml and is
loaded by Artifactory at initial startup. Once the file is loaded, Artifactory renames it to artifa
ctory.config.bootstrap.xml and from that point on, the configuration is stored internally
in Artifactory's storage. This ensures Artifactory's configuration and data are coherently stored
in one place making it easier to back up and move Artifactory when using direct database
backups. On every startup, Artifactory also writes its current configuration to $ARTIFACTORY_
HOME/etc/artifactory.config.startup.xml as a backup.
At any time, the default configuration can be changed in the Artifactory UI Admin module.
There are two ways to directly modify the Global Configuration Descriptor:
1. Using the Artifactory UI
2. Using the REST API
Page Contents
Global Configuration Descriptor
Modifying Configuration Using the UI
Modifying Configuration Using the REST API
Bootstrapping the Global Configuration
Security Configuration Descriptor
Modifying Security Using the UI
Modifying Security Using the REST API
Bootstrapping the Security Configuration
Content Type/MIME Type
MIME Type Attributes
Setting Content-Type During Download
System Properties
Logging Configuration Files
Storage Properties

Care
Direct modification of the global configuration descriptor is an advanced feature, and if done incorrectly may render Artifactory in an
undefined and unusable state. We strongly recommend backing up the configuration before making any direct changes, and taking
great care when doing so.

Modifying Configuration Using the UI
You can access the Global Configuration Descriptor in the Admin module under Advanced | Config Descriptor. There you can modify the file's
contents directly or copy the contents from the entry field.

Modifying Configuration Using the REST API
You can retrieve or set the global configuration by sending a GET or POST request to http://:/artifactory/api/system
/configuration. For example:

Retrieving and Setting the Global Configuration Descriptor
curl -u admin:password -X GET -H "Accept: application/xml"
http://localhost:8080/artifactory/api/system/configuration
curl -u admin:password -X POST -H "Content-type:application/xml"
--data-binary @artifactory.config.xml
http://localhost:8080/artifactory/api/system/configuration

Bootstrapping the Global Configuration
You can bootstrap Artifactory with a predefined global configuration by creating an $ARTIFACTORY_HOME/etc/artifactory.config.impor
t.xml file containing the Artifactory configuration descriptor.
If Artifactory detects this file at startup, it uses the information in the file to override its global configuration. This is useful if you want to copy the
configuration to another instance of Artifactory.

Security Configuration Descriptor
There are two ways to directly modify the Security Configuration Descriptor:
1. Using the Artifactory UI
2. Using the REST API
Care
Direct modification of the security descriptor is an advanced feature, and if done incorrectly may render Artifactory in an undefined and
unusable state. We strongly recommend backing up the configuration before making any direct changes, and taking great care when
doing so.

Modifying Security Using the UI

You can access the Security Configuration Descriptor in the Admin module under Advanced | Security Descriptor. There you can modify the
file's contents directly or copy the contents from the entry field.

Modifying Security Using the REST API
You can retrieve or set the security configuration by sending a GET or POST request to http://:/artifactory/api/syste
m/security. For example:

Modifying the Security Descriptor
curl -u admin:password -X GET -H "Accept: application/xml"
http://localhost:8080/artifactory/api/system/security
curl -u admin:password -X POST -H "Content-Type: application/xml"
--data-binary @security.xml
http://localhost:8080/artifactory/api/system/security

Admin privileges
You must supply a user with Admin privileges to modify the security descriptor through the REST API

Bootstrapping the Security Configuration
Artifactory stores all security information as part of its internal storage.You can bootstrap Artifactory with a predefined security configuration by
creating an $ARTIFACTORY_HOME/etc/security.import.xml file containing the Artifactory exported security configuration information.
If Artifactory detects this file at startup, it uses the information in the file to override all security settings. This is useful if you want to copy the
security configuration to another instance of Artifactory.

Content Type/MIME Type
Artifactory provides a flexible mechanism to manage content type/MIME Type. You can define system-wide MIME types for common usage, but
you can also overwrite the MIME types for specific files as needed. The list of default MIME types can be found in in $ARTIFACTORY_HOME/et
c/mimetypes.xml and can be edited in order to add, remove or change MIME types. If a file has an extension that is not supported by any of
the MIME types, or does not have an extension at all, Artifactory will use the default MIME type of application/octet-stream. To determine
an artifact's MIME type, Artifactory compares its extension with the those in the mimetype.xml file, and applies the MIME type of the first
extension that matches.

MIME Type Attributes
Each MIME type may have the following attributes:
The MIME type unique name (mandatory)
type

A comma separated list of file extensions mapped to this MIME type (mandatory)
extensions

True if this MIME type should be indexed for archive searching (valid only for supported archive files)
index

True if this MIME type is a browsable archive
archive

True if this MIME type can be viewed as a text file inside Artifactory UI
viewable

The UI highlighter syntax to for this MIME type (only relevant if this is a viewable type)
syntax

The css class of a display icon for this mime type
css

Example of mimetype.xml

For example, from the extensions parameter in the above mimtypes.xml file sample we can conclude that:
test.properties is a text/plain MIME type
test.css is a text/css MIME type
test.doc is an application/octet-stream MIME type since "doc" is not included in any of the other MIME types).

IMPORTANT: Make sure you restart Artifactory for your changes to take affect.

Artifactory MIME Types
Some of the Mime-Types specified in mimetypes.xml (e.g. application/x-checksum) are used by Artifactory. Great care
should be taken before changing these Mime-Types to ensure Artifactory continues to function correctly.

Setting Content-Type During Download
Using Artifactory, when downloading files you can override the Content-Type HTTP header by setting the artifactory.content-type pr
operty.
If the artifactory.content-type property is not explicitly set, Artifactory will use the default mechanism of matching the artifact name
extension to the extensions in the mimtypes.xml file to apply the Content-Type.
This feature is only available with Artifactory Pro.

System Properties
Rather than configuring properties in the JVM runtime configuration of the hosting container, you can edit $ARTIFACTORY_HOME/etc/artifac
tory.system.properties file and restart Artifactory.
The Artifactory system properties are documented within this file.
Since these settings impact the entire container VM, we recommend using this feature primarily for specifying Artifactory-related properties only
(such as changing the database used by Artifactory, etc.).
Setting properties in artifactory.system.properties is an advanced feature and is typically not required.
Do not confuse these setting with those in the $ARTIFACTORY_HOME/data/artifactory.properties file, which are for internal
use.

Logging Configuration Files
Artifactory uses the Logback Framework to manage logging and lets you configure the verbosity of log files. For details please refer to Configuring
Log Verbosity

Storage Properties
Artifactory provides you with a binarystore.xml file so that you can configure the specific storage solution used in your system. For details
please refer to Configuring the Filestore.

Exposing Maven Indexes
Overview
Artifactory exposes Maven indexes for use by Maven integrations of common IDEs ( for example,
IntelliJ IDEA, NetBeans, Eclipse).

Page Contents
Overview
Usage

Indexes are fetched remotely from remote repositories that provide them and are calculated for
local and virtual repositories (note that many repositories do not provide indexes, or do not keep an
updated index).
If Artifactory cannot find a remote index, it calculates one locally, based on the remote repository's
previously cached artifacts.
Artifactory's search and indexing facilities are not related to Maven indexes
The indexing performed by Artifactory is secure, immediately effective and supports a larger variety of search options, including
custom metadata searches.

Maven indexes only exist in Artifactory for the purpose IDE integrations. They are periodically calculated, contain a limited set of
data and are non-secure by design.
Information about the content of a repository is exposed to anyone with access to the repository's index, regardless of any effective
path permission you have in place. If this is a concern, do not expose an index for that repository.

Using Artifactory SaaS?
The Maven Indexer service is only available on Artifactory SaaS dedicated servers.

Usage
To administer Maven indexes, in the Admin module select Services | Maven Indexer.
Artifactory provides you with controls to specify how frequently indexing is run and which repositories are included in the index calculation.

When set, indexing is enabled and will run according to the Cron Expression setting
Enabled

Cron Expression

A valid Cron expression that determines the frequency in which Maven indexes on the selected repositories will be
recalculated
Indicates the next scheduled indexing run

Next Indexing Time

Invokes indexing immediately
Run Indexing Now

Specifies the repositories that should be indexed on the next run
Included
Repositories

Specifies the repositories that should not be indexed on the next run
Excluded
Repositories

Removes all repositories from the Included Repositories list
Clear All

Indexing is resource intensive
Calculating and indexing for a repository may be a resource intensive operation, especially for a large local repository or if the
repository is a virtual one containing other underlying repositories.
Therefore, we recommend that you do not include repositories that do not require indexing for a periodic index calculation.

Clustering Artifactory
Active/Active Architecture
Artifactory HA is an Active/Active clustered installation of Artifactory that provides a full set of true High
Availability features and is supported with an Artifactory Enterprise License.
For full details please refer to Artifactory High Availability.

Active/Passive Architecture
Overview
Artifactory clustered Active/Passive architecture provides fast disaster recovery and can be implemented in
one of the following two ways:
Deployment on fault-tolerant storage (strongly recommended)
Periodic cross-server data sync.

Deployment on Fault-tolerant Storage
Using a fault-tolerant disk mounted on another machine allows for a very short MTR (Mean Time to
Recovery) in case the "active" server goes down. If Artifactory is deployed on a NAS or SAN the "passive"
machine can immediately mount the storage, bootstrap Artifactory from it and start accepting requests in
place of the originally "active" machine that is has gone down.
Page Contents
Active/Active
Architecture
Active/Passive
Architecture
Overview
Deployment
on
Fault-tolerant
Storage
Cross-server
Data
Synchronizati
on
Synch
ronizi
ng the
Data
and
Confi
gurati

on
Direct
ories
Synch
ronizi
ng the
Datab
ase
Time
Synch
roniza
tion
on the
Stand
by
Serve
r

To set this up quickly and efficiently, we recommend using the built-in Virtual Machine Failover feature offered by virtualization software providers
as follows:
1. Create a VM image that runs the Artifactory startup script and mounts the auxiliary storage.
2. The storage should contain the full Artifactory installation along with the data in a location defined as $ARTIFACTORY_HOME.
3. Use the VM image on two Virtual Machines and have Artifactory running on one machine while the other machine is readily available as a
failover target by the virtualization monitor.

Cross-server Data Synchronization
If deployment on fault-tolerant storage, as described in the previous section, is not possible (or if redundancy is required), fault-tolerance can be
achieved by correctly replicating the data folder to a warm standby server.
The setup of an up-to-date passive replication server for the active Artifactory server requires database replication and synchronization of file
system directories.

Synchronizing the Data and Configuration Directories
To synchronize the data and configuration directories you need to run rsync on $ARTIFACTORY_HOME/data and $ARTIFACTORY_HOME/etc.
This can be done by running the rsync command on $ARTIFACTORY_HOME while excluding the directories that are not required as follows:

rsync -vvah --del --progress --log-file=/home/replication/replication.log
--exclude-from=rsync-excludes.txt \
artifactory@active-artifactory-host:$ARTIFACTORY_HOME/ $ARTIFACTORY_HOME/

For the above example the rsync-excludes.txt file appears as follows:

/work/
/data/tmp*/
/data/cache/
/logs/

rsync
The rsync should be executed from the passive stand-by server

Synchronizing the Database
Database Replication
Database replication must run before executing rsync.

The procedure to synchronize a database varies between the different database vendors. Please refer to the relevant documentation for your
specific database.
For example, instructions on how to synchronize with MySQL can be found in the MySQL documentation for How to Set Up Replication.
It is also possible to use a full dump/restore procedure on the database to synchronize the database and filestore state. In this case, we
recommend that you perform the dump in a single routine along with rsync (in case of File System Storage Types).

Time Synchronization on the Standby Server
It is very important that the metadata stored in the database and the data stored on the file system are synchronized on the standby server.
A straightforward way to achieve this, is to make sure that the database synchronized is in a state that is prior to the file system (data/filestore)
state.
This allows you to:
Make a database dump before executing the file system sync,
Activate database replication on demand just before executing rsync.
Since the sync operations are not atomic, there may be a gap between the data from rsync and data from database replication.
1. The snapshot time that Artifactory is set to is the database replication time.
2. Items synced to the file system which have no representation in the database can be purged by clicking on Prune
Unreferenced Data in the Admin tab and then Advanced | Maintenance in the Artifactory configuration.

System Monitoring and Maintenance
Overview
Artifactory provides a set of tools that allow you to monitor and maintain your system to keep it running and
responsive:
System Information lets you examine the various properties and parameters of your system at
runtime and is a valuable resource when investigating any issues that may arise.
You can monitor storage to view the number of artifacts and physical files in your system as well as
the amount of space that they occupy.
Log files let you monitor all the activity that has occurred in your system
JMX Beans let you monitor repositories, executor pools and storage
You can configure regular, periodic maintenance operations to manage resource allocation and free
up disk space
You can define a regimen for complete system backup
You can import and export data both at system level and repository level
You can monitor activity related to a specific artifact by defining a watch
Read More
System Information
Monitoring Storage
Artifactory Log Files
Artifactory JMX MBeans
Regular Maintenance Operations
Managing Backups
Importing and Exporting
Managing Disk Space Usage
Getting Support

System Information

Overview
Artifactory can display different system information such as JVM runtime parameters, JVM arguments,
memory usage and more.
This can be useful if you need to examine your system at runtime and is a valuable resource when
investigating any issues that may arise.
To view Artifactory system information, in the Admin module, go to Advanced | System Info.
Page Contents
Overview

Monitoring Storage
Overview
Artifactory allows you to monitor various statistics related to the amount of storage that repositories occupy in
your system. You can view the number of artifacts and physical files as well as the amount of space that they
occupy. To monitor usage of storage in your system, in the Admin module, go to Advanced | Storage
Summary.
Page Contents
Overview
Binaries
File Store
Filestore Sharding
Repositories

Binaries
This section provides information on the number of files in your system and the amount of physical and virtual storage that they occupy.

The total number of physical binaries stored in your system.
Binaries
Count

The amount of physical storage occupied by the binaries in your system.
Binaries Size

The amount of physical storage that would be occupied if each artifact was a physical binary (not just a link).
Artifacts Size

Optimization

The ratio of Binaries Size to Artifacts Size. This reflects how much the usage of storage in your system has been reduced by
Artifactory
The total number of items (both files and folders) in your system.

Items Count

File Store
Your system is set up to store binaries as defined in

your storage configuration file.

This section provides information on where your binaries are stored and the amount of storage space they are
using.

The type of storage used (e.g. "File system").
Storage Type

If Storage Type is "filesystem" then this is the path to the physical file store.
Storage
Directory

If Storage Type is "fullDb" then this is the path to the directory that caches binaries when they are extracted from the
database.
Displays the amount of storage used out of the total available.

Usage

Storage space warning and limit thresholds set for your system are also displayed.

Filestore Sharding
From version 4.6, Artifactory offers an additional and highly flexible way to manage storage through Configuring the Filestore. If you use the
advanced configuration to setup filestore sharding in your system, your usage of storage is displayed with details of how sharding is configured.

You can select any of the sharding zones to drill down and get more details about it.

Repositories
The Repositories section provides detailed information about the storage used by each repository in your system.

The repository id.
Repository Key

Indicates if this is a local repository, remote repository cache or a virtual repository.
Repository
Type

The repository's package type.
Package Type

The percentage of the total available space occupied by this repository.
Percentage

Artifacts Size

The amount of space used by artifacts in this repository. Similar to the total export size (including non-unique artifact
references).

The total number of files in this repository.
Files

The total number of folders in this repository.
Folders

The total number of items (folders and files) in this repository.
Items

Artifactory Log Files
Overview
Artifactory uses the Logback Framework to manage logging. Activity is logged according to type in four
different log files which can be found under the ARTIFACTORY_HOME/logs folder.
The following log files are available:
The main Artifactory log file containing data on Artifactory server activity.
artifactory.log

access.log

Security log containing important information about accepted and denied
requests, configuration changes and password reset requests. The originating IP
address for each event is also recorded.
Generic http traffic information similar to the Apache HTTPd request log.

request.log

A log used for tracking the process of long-running import and export commands.
import.export.log

sha256_migration.log

Logs status and errors when migrating the Artifactory database to include
SHA256 values.

Page Contents
Overview
Configuring Log Verbosity
Minimizing Output to catalina.out
Log File Structure
Request Log
Access Log
Viewing Log Files from the UI
Sending Artifactory Logs to Syslog

Tomcat/Servlet container-specific log files
When running Artifactory inside an existing servlet container, the container typically has its own log files.
These files normally contain additional information to that in artifactory.log or application bootstrapping-time information that is
not found in the Artifactory logs.
In Tomcat, these files are catalina.out and localhost.yyyy-mm-dd.log respectively.

Configuring Log Verbosity

The verbosity of any logger in your system can be configured by entering or modifying the level value in the corresponding entry in the Logback
configuration file ARTIFACTORY_HOME/etc/logback.xml.
For example:

Modifying the verbosity of a logger

Artifactory loads any changes made to the Logback configuration file within several seconds without requiring a restart.

Minimizing Output to catalina.out
When running Artifactory as a background service, Artifactory log messages are redirected to catalina.out which may cause this file to be
over-inflated with content. To reduce the volume of logging to catalina.out we recommend adding a "threshold filter" to the "CONSOLE" appender
in logback.xml as follows:

...

ERROR

%date ${artifactory.contextId}[%thread] [%-5p]
$%-20c{3}:%L$ - %m%n

...

Log File Structure
The Request and Access log files each display specific type of activity and as such have a consistent and specific file structure for maximum
readability

Request Log
A request log file record has the following structure:

Request log file record sample
20140508154145|2632|REQUEST|86:12:14:192|admin|GET|/jcenter/org/iostreams/
iostreams/0.2/iostreams-0.2.jar|HTTP/1.1|200|8296

Date and time stamp

The date and time the request was completed and entered into the log file. Format is
[YYYYMMDDHHMMSS]
The time in ms taken for the request to be processed

Request time

DOWNLOAD for a download request
Request type

UPLOAD for an upload request
REQUEST for any other request
The requesting user's IP address

The requesting user's user name or "non_authenticated_user" when accessed anonymously
User name

The HTTP request method. e.g. GET, PUT etc.
Request method

Relative path to the requested resource
Requested resource path

The HTTP protocol version
Protocol version

The HTTP response code
Response code

If request method is GET: Size of response
Size (bytes) of request or
response

If request method is PUT or POST: Size of request

Access log file record
2014-05-08 15:52:27,456 [ACCEPTED DOWNLOAD]
jcenter-cache:org/iostreams/iostreams/0.2/iostreams-0.2.jar for
anonymous/86:12:14:192.

The date and time that the entry was logged. Format is [YYYY-MM-DD HH:MM:SS, milliseconds]
Date and Time stamp

The response (ACCEPTED/DENIED) and the action type (e.g. DOWNLOAD, UPLOAD etc.)
[Action response and type]

The repository that was accessed
Repository path (Optional)

An optional system message
Message (Optional)

The accessing user's user name or "anonymous" when accessed anonymously
User name

The accessing user's IP address
IP

Viewing Log Files from the UI
You can view or download any of the Artifactory log files from the UI.
In the Admin module, under Advanced | System Logs, select the file you want to view from the drop-list. The log tail view is automatically
refreshed every few seconds, however can be paused and resumed if you wish to browse the log.

To save system resources, do not leave the log view open in your browser unnecessarily.

Sending Artifactory Logs to Syslog
Some sites want to consolidate logs into the syslog facility. Switching artifactory to use syslog in addition to, or instead of the standard log files
takes a quick edit of a couple of files. Artifactory currently uses the logback library for logging, so that's what needs to be configured.

First edit the $ARTIFACTORY_HOME/etc/logback.xml file to send logs to the syslog facility. You need to add an appender to syslog:

localhost
SYSLOG
[%thread] %logger %msg

then you need to add this appender to the output, in the section:

add:

before the line.
Save the file, you will not need to restart artifactory for this to take effect.
Since logback is using internet sockets, you have to make sure your syslog facility accepts them. Modern linux distributions are using the rsyslog
daemon for syslogging. Ensure that the configuration for internet domain sockets is enabled, either by editing /etc/rsyslog.conf and
uncommenting:
# Provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514
# Provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 514
or placing it in a file under /etc/rsyslog.d ending in .conf
Rsyslog will need restarting with service rsyslog restart for this to take effect.

Artifactory JMX MBeans
Overview
Artifactory exposes MBeans under the org.jfrog.artifactory domain that let you monitor repositories,
executor pools, storage and HTTP connection pools.

Page Contents
Overview
Repositories
Executor Pools
Storage
HTTP Connection Pools
Logging

Repositories
This section lists the available repositories under the current instance of Artifactory.
Read-only attributes are as follows:
Name of the repository
RepositoryKey

Number of artifacts in the repository
ArtifactsCount

Total size of all of the artifacts in the repository
ArtifactsTotalSize

Executor Pools
This section lists the executor pools in use by Artifactory.
Read-only attributes are as follows:
Total number of tasks that have ever been scheduled for execution
TaskCount

Total number of tasks that have been completed by the executors
CompletedTaskCount

Executor pool size
CorePoolSize

Maximum size of the executor pool
MaximumPoolSize

Number of active executors
ActiveCount

The largest pool size that has been active at any one time
LargestPoolSize

Storage
This section describes File System Binary Storage and Database Data Source read-only attributes.
There is only one File System Binary Storage read-only attribute:
Total size of Artifactory storage in bytes
Size

Database Data Source read-only attributes are:
Maximum number of active connections to the database
MaxActive

Database URL
Url

Number of idle database connections
Idle

Number of active database connections
ActiveConnectionsCount

Maximum number of idle database connections allowed
MaxIdle

Timeout in ms when attempting to get a free connection
MaxWait

Minimum number of idle database connections to maintain
MinIdle

HTTP Connection Pools
Artifactory supports JMX MBeans for the following HTTP resources:
Remote repositories
Distribution Repositories
Xray Client Connection
Replication Queues
Event propagation service for Artifactory HA cluster nodes

The following read-only attributes are available for each HTTP connection pool:
Number of available connections
Available

Number of currently active connections
Leased

The maximum number of connections possible
Max

The number of connections in process and pending completion
Pending

Logging
To support log analytics, Artifactory implements log appenders that send log information to Sumo Logic. The following log appenders can be
monitored through JMX MBeans:.
Access
Console

Request
Traffic
For each log appender, Artifactory displays the following read-only attributes:
The maximum number of log entries the queue can hold
QueueMaxSize

The current number of log entries in the queue
QueueCurrentSize

Below this remaining capacity threshold, trace and debug log entries will be discarded
QueueDiscardingThreshold

The maximum number of log entries a batch can contain before it is processed
BatchMaxSize

The size of the current batch pending to be sent to Sumologic
BatchCurrentSize

BatchQuietPeriod

The time window (in milliseconds) log entries are collected in a batch before it is being sent to
Sumologic
The category header value which is sent to Sumologic for this appender

CategoryHeader

Regular Maintenance Operations
Overview
Artifactory provides several facilities allowing you to maintain your system for optimal performance.
To configure your global system maintenance, in the Admin module select Advanced | Maintenance.
Artifactory SaaS Users
JFrog manages regular maintenance operations for all instances of Artifactory SaaS. If you are an
Artifactory SaaS user, the features described on this page are all monitored and optimally
managed for you by JFrog Artifactory SaaS administrators.

Page Contents
Overview
Garbage Collection
Storage Quota Limits
Cleanup Unused Cached Artifacts
Cleanup Virtual Repositories
Storage

Garbage Collection

Artifactory uses checksum-based storage to ensure that each binary file is only stored once.
When a new file is deployed, Artifactory checks if a binary with the same checksum already exists and if so, links the repository path to this binary.
Upon deletion of a repository path, Artifactory does not delete the binary since it may be used by other paths. However, once all paths pointing to
a binary are deleted, the file is actually no longer being used. To make sure your system does not become clogged with unused binaries,
Artifactory periodically runs a "Garbage Collection" to identify unused ("deleted") binaries and dispose of them from the datastore. By default, this
is set to run every 4 hours and is controlled by a cron expression.
For example, to run garbage collection every 12 hours you should specify the following expression:

0 0 /12 * * ?

Specifies the frequency in which garbage collection should be run automatically
Cron Expression

Indicates the next automatic run of garbage collection according to the specified Cron Expression
Next Run Time

Manually invokes garbage collection immediately
Run Now

Garbage collection frequency
Garbage collection is a resource intensive operation. Running it too frequently may compromise system performance.

Storage Quota Limits

Artifactory lets you set a limit on how much of your entire system disk space storage may be used to ensure that your server file system capacity
is never used up. This helps to keep your system reliable and available.
Once disk space used for storage reaches the specified limit, any attempt to deploy a binary is rejected by Artifactory with a status code of 413
Request Entity Too Large and a "Datastore disk space is too high" error is displayed at the bottom of the Maintenance screen.
When using filesystem storage, the partition checked is the one containing the $ARTIFACTORY_HOME/data/filestore directory.
When using database blob storage, the partition checked is the one containing the $ARTIFACTORY_HOME/data/cache directory.
To help you avoid reaching your disk space quota, Artifactory also allows you to specify a warning level. Once the specified percentage of disk

space is used, Artifactory will log a warning in the $ARTIFACTORY_HOME/logs/artifactory.log file and display a "Datastore disk space is
too high" warning at the bottom of the Maintenance screen.

Enable Quota
Control

Storage Space
Limit

When set, Artifactory will monitor disk space usage and issue warnings and errors according to the quotas specified in Stor
age Space Limit and Storage Space Warning

The percentage of available disk space that may be used for storage before Artifactory rejects deployments and issues
errors

The percentage of available disk space that may be used for storage before Artifactory issues warnings
Storage Space
Warning

Cleanup Unused Cached Artifacts

When configuring a remote repository, the Keep Unused Artifacts setting lets you specify how long a cached unused artifact from that repository
should be kept before it is a candidate for cleanup. This setting does not immediately clean up the unused cached artifact, but merely marks it for
clean up after the specified number of hours. The Cleanup Unused Cached Artifacts setting specifies when the cleanup operation should run,
and only then unused, cached artifacts marked for cleanup are actually removed from the system.
The cleanup frequency is specified with a cron expression. For example, to run cleanup every 12 hours you should specify the following
expression:

0 0 /12 * * ?

Cleanup Virtual Repositories

Virtual repositories use an internal cache to store aggregated metadata such as POM files. The Cleanup Virtual Repositories operation deletes
cached POM files that are older than 168 hours (one week)
The cleanup frequency is specified with a cron expression. For example, to run cleanup every 12 hours you should specify the following
expression:

0 0 /12 * * ?

Storage

Compress
the Internal
Database

Derby database only
This feature is only relevant when using the internal Derby database

A Derby database may typically contain unused allocated space when a large amount of data is deleted from a table or its
indices are updated. By default, Derby does not return unused space to the operating system. For example, once a page has
been allocated to a table or index, it is not automatically returned to the operating system until the table or index is destroyed.
When you invoke this action, Artifactory reclaims unused and allocated space in a table and its indexes thereby compressing
the internal database.
We recommend running this when Artifactory activity is low, since compression may not be able to complete when
storage is busy (in which case the storage will not be affected).

Prune
Unreferenced
Data

Unreferenced binary files may occur due to running with wrong file system permissions on storage folders, or running out of
storage space.
When you invoke this action, Artifactory removes unreferenced binary files and empty folders present in the filestore or cache
folders.
Ensure complete shutdown
To avoid such errors, we recommend that you always allow Artifactory to shut down completely

Managing Backups
Complete System Backup
You can automatically and periodically backup the entire Artifactory system. The backup process creates a
time-stamped directory in the target backup directory.
To define multiple backups, in the Admin module, select Services | Backups. Each

backup may
have its own schedule and repositories to either process or exclude.
Page Contents
Complete System Backup

Restoring a Backup

Backup content is stored in standard file system format and can be loaded into any repository, so that Artifactory never locks you out.

Backing up very large filestores
If you are backing up more than 1TB of storage, please refer to this article in our Knowledge Base for instructions.
In the Backups page you may select an existing Backup to edit, or click "New" to create a new Backup.

A unique logical name for this backup
Backup Key

Cron Expression

A valid Cron expression that you can use to control backup frequency. For example, to back up every 12 hours use
a value of: 0 0 /12 * * ?
When the next backup is due to run

Next Time Backup

Server Path for Backup

The directory to which local repository data should be backed up as files
The default is $ARTIFACTORY_HOME/backup/[backup_key]
Each run of this backup will create a new directory under this one with the time stamp as its name.
If set, all Artifactory administrators will be notified by email if any problem is encountered during backup.

Send Mail to Admins if
there are Backup
Errors

Exclude all builds from the backup.
Exclude Builds

Retention Period

The number of hours to keep a backup before Artifactory will clean it up to free up disk space. Applicable only to
non-incremental backups.
Do not store any custom files under the target backup directory, since the automatic backup cleanup
processes may delete them!

Verify enough disk
space is available for
backup

Incremental

If set, Artifactory will verify that the backup target location has enough disk space available to hold the backed up
data. If there is not enough space available, Artifactory will abort the backup and write a message in the log file.

When set, this backup should be incremental. In this case, only changes from the previous run will be backed up, so
the process is very fast.
The backup directory name will be called current (as opposed to using the timestamp)

The backup files can be used by any incremental file-system based backup utility (such as r
sync).
If set, backups will be created within a Zip archive
Backup to a Zip Archie
(Slow and CPU
Intensive)

Monitoring Backup Progress

During a system backup, Artifactory writes several messages to the ARTIFACTORY_HOME/logs/artifactory.log file. To
monitor progress of the backup process, look for messages that indicate the beginning and the end of
a full system export as in the following example:

2016-06-09 02:00:00,023 [art-exec-1] [INFO ]
(o.a.s.ArtifactoryApplicationContext:508) - Beginning full system
export...
...
2016-06-09 02:00:00,357 [art-exec-1] [INFO ]
(o.a.s.ArtifactoryApplicationContext:620) - Full system export
completed successfully.

Restoring a Backup
To restore a system backup you need perform a system import. For details please refer to System Import and Export.

Importing and Exporting
Overview
Artifactory supports import and export of data at two levels:
System level
Repository level
At system level, Artifactory can export and import the whole Artifactory server: configuration,
security information, stored data and metadata. The format used is identical to the System Backup
format. This is useful when manually running backups and for migrating and restoring a complete
Artifactory instance (as an alternative to using database level backup and restore).
At repository level, Artifactory can export and import data and metadata stored in a repository.
This is useful when moving store data, including its metadata between repositories and for batch
population of a repository.

Page Contents
Overview
System Import and
Export
System Import
and Export for
an HA Cluster
Repositories Import and
Export
Export
Import
Import
Layout

System Import and Export
To access import and export of your entire system, in the Admin module, select Import & Export | System

The target directory for the exported files. You may browse your file system to select the directory
Target Export Dir

Export: When set, repository binaries are excluded from the export.
Exclude Content

Import: When set, binaries and metadata are excluded from the import. Only builds and configuration files are
imported.

Exclude Metadata

When set, repository metadata are excluded from the import/export.
(Maven 2 metadata is unaffected by this setting)
Docker repositories must have metadata
For Docker repositories to work they must have their metadata intact. Therefore, if you have Docker
repositories, make sure that Exclude Metadata is not checked when doing a system export or import.

When set, all builds are excluded from the export
Exclude Builds

When set, includes Maven 2 repository metadata and checksum files as part of the export
Create .m2 Compatible
Export

When set, creates and exports to a Zip archive
Create a Zip Archive
(Slow and CPU
Intensive!)

When set, lowers the log level to "debug" and redirects the output from the standard log to the import-export log.
Output Verbose Log

Monitoring the log
You can monitor the log in the System Logs page.

The source/target of the import/export operations are folders (Zip archives are not recommended) on the
Artifactory server itself.
You can use the built-in server-side browsing inside Artifactory to select server-side source/target folders:

Importing or exporting a large amount of data may be time consuming. During the import/export operation you can browse away
from the page and sample the System Logs to monitor progress.

System Import and Export for an HA Cluster
When performing a system export and subsequent import for an HA cluster, you need to follow the procedure below to ensure that the cluster
is able to correctly synchronize its nodes.
Perform a normal system export from the source cluster as described above
In the target cluster, keep the primary node running, and perform a graceful shutdown of all secondary nodes
Perform normal system import to the target cluster (which now has only the primary node running) as described above
Perform a graceful shutdown of the primary node and then restart it
Create the bootstrap bundle on the primary node
For each secondary node:
Delete the following folders
$ARTIFACTORY_HOME/access
$ARTIFACTORY_HOME/etc/security
$ARTIFACTORY_HOME/etc/ui
$ARTIFACTORY_HOME/etc/plugins
Delete the $ARTIFACTORY_HOME/etc/db.properties file
Delete the $ARTIFACTORY_HOME/etc/binarystore.xml file
Copy the bootstrap bundle you created on the primary node, bootstrap.bundle.tar.gz, to the $ARTIFACTORY_HOME/
etc folder on the secondary node.
Bootstrap Bundle and db.properties
This is a critical step in the import process. The bootstrap bundle must be installed in each secondary node before
you start it up for it to operate correctly in the cluster.

Note also, if the $ARTIFACTORY_HOME/etc folder in your secondary node already contains a db.properties f
ile, it will prevent the bootstrap bundle from being properly extracted when you start up the secondary node
causing the import to fail.
Start up the secondary node
Once you have completed the import, we recommend verifying that your HA cluster is up and running normally as described in Testing your
HA Configuration.

Repositories Import and Export
To access import and export of repositories, in the Admin tab, select Import & Export | Repositories

Export

When exporting, you need to specify the following parameters:
You can specify a single repository to export, or All Repositories
Source Local Repository

The export target directory on your server
Export to Path

Exclude Metadata

When set, repository metadata are excluded from the export.(Maven 2 metadata is unaffected by this
setting)
When set, includes Maven 2 repository metadata and checksum files as part of the export

Create .m2 Compatible
Export

Output Verbose Log

When set, lowers the log level to "debug" and redirects the output from the standard log to the
import-export log.
Monitoring the log
You can monitor the log in the System Logs page.

Import
You can import repositories from a server side folder, or by zipping a repository and uploading it to Artifactory.

When importing, you need to specify the following parameters:

Target Local
Repository

You can specify a single repository to import, or All Repositories. The repository layout should be different depending
on your selection. Please refer to Import Layout

The import source directory on your server
Server Path for
Import

When set, repository metadata are excluded from the import
Exclude
Metadata

When set, lowers the log level to "debug" and redirects the output from the standard log to the import-export log.
Output Verbose
Log

Monitoring the log
You can monitor the log in the System Logs page.

Don't exclude metadata for Docker
To work with a Docker repository, it must have its metadata intact. Therefore, when importing to/exporting from a Docker repository
make sure that Exclude Metadata is not checked.

Importing into a Remote Repository Cache
You can take advantage of remote repositories you have already downloaded to your local environment, and import them directly
into a local repository.
For example, you can take your local Maven repository (usually located under ~/.m2) and upload it into Artifactory so that all the
artifacts you have already downloaded are now available on the server.

Import Layout
An imported repository needs to be formatted using a Maven 2 repository layout.
When importing a single repository, the file structure within the import folder (or zip file) should be as follows:

IMPORT_FOLDER/ZIP_FILE
|
|--LIB_DIR_1

When importing all repositories, the file structure within the import folder should be as follows:

When importing all repositories, you need to ensure that the names of the directories representing the repositories in the archive
match the names of the target repositories in Artifactory.

Managing Disk Space Usage
Overview
Artifactory includes features to help you manage the amount of disk space used by your system. This
is done by providing alerts, limiting the amount of space allocated for the output of automatic
procedures, and by cleaning up unused artifacts in a controlled manner.

Garbage Collection
When an Artifactory user "deletes" a file, what is actually deleted is the reference from the Artifactory
database to the physical file. Before actually deleting a file Artifactory must scan the system to ensure
that there are no other users referencing the file. Scanning the system is very CPU intensive, and
locks files while the scan is in process, and this may stress the development environment. Therefore
this can be scheduled to run periodically as a "Garbage Collection" process during times when
demands on the system are low.
This is done in the Artifactory UI Admin module under Advanced | Regular Maintenance
Operations, where you can schedule an automatic run of Garbage Collection with a Cron expression.
You can also invoke an immediate run by clicking "Run Storage Garbage Collection".

Page Contents
Overview
Garbage Collection
Storage Quota
Limiting the Number of Snapshots
Deleting Unused Cached Artifacts
Deleting Complete Versions
User Plugins

Manual Cleanup with the REST API
Discarding old builds with Jenkins Artifactory plugin

Storage Quota
To avoid running out of disk space Artifactory allows you to limit the storage space allocated for your repositories.
In the Admin module, under Advanced | Maintenance, set Enable Quota Control, and specify Storage Space Limit to specify the percentage
of disk space that you allocate for your repositories. An attempt to store binaries above the allocated storage percentage will fail with an error. You
may also set Storage Space Warning to specify at what percentage of disk space usage to receive a warning from Artifactory.

Limiting the Number of Snapshots
Working with snapshots is a standard development practice, however depending on the number of snapshots that are saved, this can use up
large quantities of disk space.
To specify the maximum number of snapshots that may be stored, select the Repositories module and click the repository whose settings you
want to edit.
In the Basic settings, check Handle Snapshots and then set the Max Unique Snapshots field. This value is zero by default, which means that
all snapshots are saved.

To avoid issues of concurrency, Artifactory requires that you store a minimum of 2 unique snapshots, however can can control the maximum
number of snapshots that are stored.
Redundant snapshots are not deleted immediately
Every time you deploy a snapshot, Artifactory will check the value Max Unique Snapshots for the repository, and if exceeded will mark
any excess old snapshots for deletion. Then, every 5 minutes, Artifactory runs a background process that deletes those oldest
snapshots that have been marked. For example, if you set Max Unique Snapshots to 5 and deploy a sixth and seventh snapshot to
the repository, then next time the background process runs, it will delete the two oldest snapshots.

Deleting Unused Cached Artifacts
When working with remote repositories, to optimize performance, Artifactory locally caches and aggregates snapshots of remote artifacts that
are being used. However, if at some point, these artifacts are no longer used, Artifactory can identify and remove them.
You can control how long an unused artifact will remain cached before it is eligible for cleanup. In the Edit Repository screen under Advanced
Settings, specify the number of hours in the Unused Artifacts Cleanup Period field.
By default this value is set to zero which means that an artifacts from the corresponding repository are never removed from the cache.

Cleaning up unused cached artifacts can be scheduled to run automatically during times when demands on the system are low using a Cron
expression in the Admin module under Advanced | Maintenance. You

can also invoke an immediate run by clicking "Run

Unused Cached Artifacts Cleanup"

Recommended Frequency for Deleting Unused Cached Artifacts
Deleting unused cached artifacts is a resource-intensive operation, so to avoid concurrency and performance issues it is recommended
to do it no more than once or twice a day, and preferably during "quiet time" such as outside of regular working hours.

Deleting Complete Versions
Artifactory supports a complete manual deletion of an installed version. This is fully described in Deleting a Version.

User Plugins
Artifactory supports cleanup by allowing you to write custom User Plugins which you can develop to meet your own specific cleanup
requirements.

JFrog provides a number of cleanup scripts on GitHub which you can use as provided or modify to suit your
own needs. For example the following artifactCleanup plugin deletes artifacts that have not been downloaded for
a specified number of months.

Manual Cleanup with the REST API
Using the Artifactory REST API, you may write scripts to implement virtually any custom cleanup logic. This provides you with an extensive and
flexible set of customization capabilities as provided by the REST API.
Examples:
Use the REST API as described Artifacts Not Downloaded Since, to identify artifacts that have not been downloaded since a specific
Java epoch, and then remove them.
Use the REST API as described in Artifacts Created in Date Range to identify artifacts created within a specific date range and then
remove them.

Discarding old builds with Jenkins Artifactory plugin
When using Jenkins for continuous integration, you can configure a policy to discard old builds that are stored in Artifactory along with their
artifacts.
For more details please refer to the Artifactory Plugin page of the Jenkins Wiki Documentation.

Getting Support
Overview
JFrog provides SLA based support for Pro and Enterprise licensing tiers. If you have purchased one of these
tiers you may contact JFrog support through the JFrog Support Portal. In most cases, JFrog support will
require some initial information about your system and relevant log files. In order to expedite handling of your
issue, Artifactory lets you generate all the initially required information in the Admin module Support Zone s
creen. When opening a support ticket, you can attach the information bundle to expedite handling of your
issue.
Artifactory OSS and Pro users
If you are running Artifactory on an OSS license, and therefore do not have access to JFrog
Support Portal, you may visit JFrog website support page to access the Artifactory Community
Forum.

Availability
Support Zone is only available for Artifactory on-prem installations.

Page Contents
Overview
Requesting Support
Collecting an Information Bundle
Previously Created Bundles
REST API

Requesting Support
To request support, create an information bundle with the relevant information, and then login to JFrog Support Portal where you can open a
support ticket and attach the information bundle.
What should I include?
Unless you are sure about the information JFrog support will need in order to address your issue, we recommend providing all items in
the information bundle you upload.

Collecting an Information Bundle
The support zone provides a variety of options to select what information is included in the bundle you provide JFrog support.

System info

Security
descriptor

Config
descriptor

If checked, provides information about your system including storage, system properties, JVM information and plugin status.
For details please refer to System Information.
If checked, provides information about how you have security configured in Artifactory. For details please refer to Security Co
nfiguration Descriptor.

If checked, provider your Artifactory config descriptor which includes detailed information on how Artifactory and its
repositories are configured. For details please refer to Global Configuration Descriptor.

If checked, provides configuration files that affect Artifactory's functionality.
Configuration
files

Storage
summary

If checked, provides information about your system's storage including binaries, file store, and repositories. For details,
please refer to Monitoring Storage.

If checked, passwords and private information such as email addresses are removed from all items in the information bundle.
Scrub
passwords
and private
information

Thread dump

If checked, Artifactory will create a thread dump for all running threads. By default a single thread dump is created, however,
to get a picture of how data may change over time, you can request several thread dumps separated by a specified time
interval with the Number of Thread Dumps and Interval fields.

System logs

If checked, system logs are included in the information bundle. You may specify the time span for which system logs should
be included.
Date range
Date range considers files according to the time stamp present in the file name, not by its contents.

Once you have checked all the information items you wish to include in your information bundle, click "Create" to create the bundle.
Artifactory HA
When creating an information bundle for an Artifactory HA installation, the bundle is created by the specific HA node that happens to
handle the "Create" request.

Resource intensive operations
Note that creating a Thread dump and System logs may be resource intensive operations and may create large information bundles.

Previously Created Bundles
Every information bundle you create is stored in Artifactory and is available for download under Previously Created Bundles.

REST API
Artifactory REST API provides the following endpoints you can use to work with information bundles:
Create a new support information bundle
Create Bundle

Lists previously created bundle currently stored in the system
List Bundles

Downloads a previously created bundle currently stored in the system
Get Bundle

Deletes a previously created bundle from the system.
Delete Bundle

Artifactory High Availability
Overview
From version 3.1, Artifactory supports a High Availability network configuration with a cluster of 2 or
more, active/active, read/write Artifactory servers on the same Local Area Network (LAN).
Setting up several servers in an HA configuration is supported with an Enterprise License and
presents several benefits to your organization:

Maximize Uptime
Artifactory HA redundant network architecture means that there is no single-point-of-failure, and
your system can continue to operate as long as at least one of the Artifactory nodes is operational.
This maximizes your uptime and can take it to levels of up to "five nines" availability.

Page Contents
Overview
Maximize
Uptime
Manage Heavy
Loads
Minimize
Maintenance
Downtime
Architecture

Manage Heavy Loads
By using a redundant array of Artifactory server nodes in the network, your system can
accommodate larger load bursts with no compromise to performance. With horizontal server
scalability, you can easily increase your capacity to meet any load requirements as your
organization grows.

Minimize Maintenance Downtime
By using an architecture with multiple Artifactory servers, Artifactory HA lets you perform most
maintenance tasks with no system downtime.

Artifactory HA Version
From version 5.0, Artifactory HA has undergone a major change in infrastructure and
uses a binary provider that manages the distribution of files across the cluster nodes and
supports cloud-native storage providers.
This guide provides instructions for installing and using Artifactory HA from version 5.0
and above.

Architecture
Artifactory HA architecture presents a Load Balancer connected to a
cluster of two or more Artifactory servers that share a common
database where all the Artifactory configuration files are maintained.
Binaries may be stored on a Network File System, or using a zoned
sharded binary provider as described in Configuring Sharding for
High Availability. The Artifactory cluster nodes must be connected
through a fast internal LAN in order to support high system
performance as well as to stay synchronized and notify each other of
actions performed in the system instantaneously. One of the
Artifactory cluster nodes is configured to be a "primary" node. Its
roles are to execute cluster-wide tasks such as cleaning up
unreferenced binaries.
JFrog support team is available to help you configure the Artifactory
cluster nodes. It is up to your organization's IT staff to configure your
load balancer, database and object store.

Network Topology
Load Balancer
The load balancer is the entry point to your Artifactory HA installation
and optimally distributes requests to the Artifactory server nodes in
your system. It is the responsibility of your organization to manage
and configure it correctly.

Use Artifactory's reverse proxy generator
You may generate configuration snippets for Apache
HTTPD and Nginx backed Artifactory High Availability
clusters with the built-in Reverse Proxy generator - it will
detect the existing server nodes and add them to the
generated configuration file.

Network
Topology
Load
Balanc
er
Artifact
ory
Server
Cluster
Local
Area
Networ
k
Filestore
Database

Read more
HA Installation and
Setup
Managing the HA
Cluster
Migrating Data from
NFS
Troubleshooting HA

The code samples below show some basic examples of load
balancer configurations:
Apache load balancer configuration example...

First install the following
modules:
LoadModule proxy_module
modules/mod_proxy.so
LoadModule
proxy_balancer_module
modules/mod_proxy_balancer.
so
LoadModule
proxy_http_module
modules/mod_proxy_http.so

Then configure as follows:

ServerAdmin
admin@frogs.com
ServerName
artifactory.jfrog.com
ServerAlias *.jfrog.com

# Artifactory server #1
BalancerMember
http://IP_SERVER_1:PORT
route=art1
# Artifactory server #2
BalancerMember
http://IP_SERVER_1:PORT
route=art2
ProxySet
lbmethod=byrequests

ProxyPreserveHost on
ProxyPass
/balancer-manager !
ProxyPass /
balancer://tomcats/
ProxyPassReverse
/artifactory
https:///artifactory
RewriteEngine On

RewriteRule
/artifactory

^/$
[R,L]

LogLevel warn
ErrorLog
/var/log/httpd/apache-ha-te
st.error.log
CustomLog

/var/log/httpd/apache-ha-te
st.access.log combined

nginx load balancer configuration example...

http {
...
...
...
upstream artifactory {
server
IP_SERVER_1:8081;
server
IP_SERVER_2:8081;
}
server {
listen 80;
server_name
YOUR_SERVER_NAME;
...
...
...
rewrite ^/$
http://$host/artifactory/we
bapp;
location / {
proxy_pass
http://artifactory;
}
}
}

More details are available on the nginx website.

Artifactory Server Cluster
Each Artifactory server in the cluster receives requests routed to it by the load balancer. All servers share a common database, and
communicate with each other to ensure that they are synchronized on all transactions.

Local Area Network
To ensure good performance and synchronization of the system, all the components of your Artifactory HA installation must be installed on
the same high-speed LAN.
In theory, Artifactory HA could work over a Wide Area Network (WAN), however in practice, network latency makes it impractical to achieve
the performance required for high availability systems.

Filestore
Artifactory HA offers different options for storing binaries. Some examples are:

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 (currently, Amazon S3 and Google Cloud Storage are supported)
Network File System (NFS)

Database
Artifactory HA requires an external database, which is fundamental to management of binaries and is also used to store cluster wide
configuration files. Currently MySQL, Oracle, MS SQL and PostgreSQL are supported. For details on how to configure any of these
databases please refer to Configuring the Database.
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.

HA Installation and Setup
Overview
This page describes how to set up a set of Artifactory nodes as an Artifactory HA cluster.
Each of the HA components is configured individually and a common setup file is configured to
bring together all of the components in the system as a whole.

Requirements
Version

Artifactory HA is supported from Artifactory 3.1 and above. If you are running a previous version of
Artifactory, you first need to upgrade as described in Upgrading Artifactory.
All nodes within the same Artifactory HA installation must be running the same Artifactory version
and the same JVM version.
Licensing

Artifactory HA is supported with an Enterprise License. Each node in the cluster must be activated
with a different license, however, this is transparently and automatically managed by the Artifactory
Cluster License Manager.
Hardware

Artifactory HA requires the following hardware:
Load balancer
External database server with a single URL to the database
Network

All the Artifactory HA components (Artifactory cluster nodes, database server and load
balancer) must be within the same fast LAN
All the HA nodes must communicate with each other through dedicated TCP ports
Network communications between the cluster nodes must be enabled for each of the
cluster nodes.
Database

Artifactory HA requires an external database and currently supports Oracle, MySQL, MS SQL and
PostgreSQL. For details on how to configure any of these databases please refer to Configuring
the Database.

Page Contents
Overview
Requirements
Home Directory
Installing Artifactory HA
The Bootstrap
Bundle
The Installation
Process
Setting Up Your
Storage
Configuration
Using
Filesyst
em
Storage
with the
NFS
Using
Filesyst
em
Storage
Without
the
NFS
Using
Cloud
Storage
With
the
NFS
Using
Cloud
Storage
Without
the
NFS
Installing the
Cluster Nodes
Installin
g the
Primary
Node
Creatin
g the

Bootstr
ap
Bundle
Add
License
s
Set the
URL
Base
Add
Second
ary
Nodes
Upgrading Artifactory
HA
Testing Your HA
Configuration
Cluster License
Management
Adding
Licenses
License Expiry
Deleting
Licenses
REST API
Screencast

|- lib/
|- /
|- bin/
|- misc/
|-backup/
|-support

Installing Artifactory HA
An Artifactory HA node is first installed as an Artifactory Pro instance, and is then modified to operate as a node in the HA cluster by
configuring the $ARTIFACTORY_HOME/etc/ha-node.properties file. Once the primary node is set up, it is used to create a bootstrap
bundle which is then used to configure the secondary nodes in the cluster.

The Bootstrap Bundle
The bootstrap bundle, bootstrap.bundle.tar.gz, contains a set of security keys and configuration files required for the proper functioning of the
cluster. During the process of installing and configuring the HA nodes, the bootstrap bundle is generated by calling the Create Bootstrap
Bundle REST API endpoint on the primary node. The same bootstrap bundle should be copied manually to each secondary node during its
installation process (into the etc folder). There’s no need to unpack the archive, Artifactory handles this process when starting up.

The Installation Process
The binary storage in an HA installation must be accessible to all nodes in the cluster. This is achieved either by mounting a Network File
System (NFS) on each cluster node, using shared object storage, or by using the nodes' local file systems while using a mechanism that
synchronizes the binaries between them.
The installation procedure involves two stages:
1. Setting up your storage configuration
The storage configuration varies depending on your decision for two parameters of your setup:
a. Binary store: Do you plan to use Filesystem Storage to store binaries on your nodes' filesystems, or a Cloud Storage pro
vider such as S3, GCS or any other S3-compliant provider?
b. NFS: Do you plan to use the Network File System (NFS) or not?
2. Installing the cluster nodes
Once your storage is configured and set up, the rest of the installation process is identical

Setting Up Your Storage Configuration
Your choice for binary store and use of NFS or not leads to one of the following four options for setting up your storage configuration:

Using Filesystem Storage with the NFS
Click here to expand for details...
To set up your HA cluster to use filesystem storage with the NFS, follow these steps which are detailed below:
Create and configure $ARTIFACTORY_HOME/etc/ha-node.properties
Create an NFS mount
Configure the binarystore.xml file
Once you have completed configuring your filestore, you are ready to complete the HA installation process by installing the cluster nodes.
Create ha-node.properties

Create the $ARTIFACTORY_HOME/etc/ha-node.properties file and populate it with the following parameters:

node.id

Unique descriptive name of this server.
Uniqueness
Make sure that each node has an id that is unique on your whole network.

context.url

The context url that should be used to communicate with this server within the cluster.
There are two ways to specify the context.url field:
As an explicit IP address
As a host name. In this case, you need to specify the hazelcast.interface field with wildcards.
For details, please refer to the description for hazelcast.interface field below.

membership.port

The port that should be used to communicate with this server within the cluster.
If not specified, Artifactory will allocate a port automatically, however we recommend to set this to a fixed
value to ensure that the port allocated is open to all of your organizations security systems such as
firewalls etc.

primary

(true | false) Indicates if this is the primary server. There must be one (and only one) server configured in
the cluster to be the primary server. For other servers this parameter is optional and its value defaults to
"false".

artifactory.ha.data.dir

This property provides the full path to the root directory of your NFS binary storage.

artifactory.ha.backup.dir

This property provides the full path to the root directory of your Artifactory back-up data on the NFS.

hazelcast.interface

[Optional] When nodes in the same cluster are running on different networks (e.g. nodes on different
docker hosts), set this value to match the server's internal IP address.
If you have specified the context.url as a host name, you need to use to the wildcard character (i.e.,
an asterisk - '*') so as to include the server's internal IP address as well as that of all members in the
cluster.
For example, if you have two nodes with the following parameters:
Node

Host name

10.1.2.22

node.a

10.1.3.33

node.b

then the hazelcast.interface field should be set to 10.1.*.*
Another example, if you have two nodes with the following parameters:
Node

Host name

10.1.2.22

node.a

10.1.2.33

node.b

then the hazelcast.interface field should be set to 10.1.2.*

ha-node.properties file permissions
On Linux, once the ha-node.properties file is created, the Artifactory user should be set as its owner and its permissions
should be set to 644(-rw-r--r--)
The example below shows how an ha-node.properties file may be configured for using filesystem storage with the NFS

node.id=art1
context.url=http://10.0.0.121:8081/artifactory
membership.port=10001
primary=true
artifactory.ha.data.dir=/mnt/shared/artifactory/ha-data
artifactory.ha.backup.dir=/mnt/shared/artifactory/ha-backup
hazelcast.interface=192.168.0.2 (optional)

Escaping the backslash in Windows systems
Note that in Windows-based system the backslash characters in the paths to the ha-data and ha-backup directories need to be
escaped with another backslash. For example:
artifactory.ha.data.dir = \\\\windows\\UNC\\path\\ha-data artifactory.ha.backup.dir = \\\\windows\\UNC\\path\\ha-backup

Create an NFS mount

When setting up Artifactory HA you need to configure the $ARTIFACTORY_HOME directory separately for each of the Artifactory cluster
nodes in your system, and a common $DATA_DIR that is accessible to all nodes to host all your filestore binaries
Create an NFS mount which will be accessible to all nodes. This mount will serve as the $DATA_DIR.
In addition, you need to set up a $BACKUP_DIR that must be accessible by the master node. It may be located on the same NFS mount,
however this is not compulsory.
Privileges
Each of the Artifactory cluster nodes must have full write privileges on the $DATA_DIR directory tree and the UID/GID for the
artifactory user must match on all nodes.

Mounting the NFS from Artifactory HA nodes
When mounting the NFS on the client side, make sure to add the following option for the mount command:
lookupcache=none
This ensures that nodes in your HA cluster will immediately see any changes to the NFS made by other nodes.

Configure the binarystore.xml File

The default binarystore.xml that comes with Artifactory out-of-the-box contains the file-system template. Since this is exactly the
configuration you need, there is no need to modify the binarystore.xml file.
In this configuration, Artifactory uses the artifactory.ha.data.dir as the location for all binaries.
You are now ready to complete the HA installation process by installing the cluster nodes.

Using Filesystem Storage Without the NFS
Click here to expand for details...
To set up your HA cluster to use filesystem storage without the NFS, follow these steps which are detailed below:
Create and configure $ARTIFACTORY_HOME/etc/ha-node.properties
Configure the binarystore.xml file
Create ha-node.properties

Create the $ARTIFACTORY_HOME/etc/ha-node.properties file and populate it with the following parameters:
node.id

Unique descriptive name of this server.
Uniqueness
Make sure that each node has an id that is unique on your whole network.

context.url

The context url that should be used to communicate with this server within the cluster.
There are two ways to specify the context.url field:
As an explicit IP address
As a host name. In this case, you need to specify the hazelcast.interface field with wildcards. For
details, please refer to the description for hazelcast.interface field below.

membership.port

The port that should be used to communicate with this server within the cluster.
If not specified, Artifactory will allocate a port automatically, however we recommend to set this to a fixed value
to ensure that the port allocated is open to all of your organizations security systems such as firewalls etc.

primary

(true | false) Indicates if this is the primary server. There must be one (and only one) server configured in the
cluster to be the primary server. For other servers this parameter is optional and its value defaults to "false".

hazelcast.interface

[Optional] When nodes in the same cluster are running on different networks (e.g. nodes on different docker
hosts), set this value to match the server's internal IP address.
If you have specified the context.url as a host name, you need to use to the wildcard character (i.e., an
asterisk - '*') so as to include the server's internal IP address as well as that of all members in the cluster.
For example, if you have two nodes with the following parameters:
Node

Host name

10.1.2.22

node.a

10.1.3.33

node.b

then the hazelcast.interface field should be set to 10.1.*.*
Another example, if you have two nodes with the following parameters:
Node

Host name

10.1.2.22

node.a

10.1.2.33

node.b

then the hazelcast.interface field should be set to 10.1.2.*

ha-node.properties file permissions
On Linux, once the ha-node.properties file is created, the Artifactory user should be set as its owner and its permissions
should be set to 644(-rw-r--r--)
The example below shows how the ha-node.properties file might be configured for your cluster nodes to use filesystem storage
without the NFS:

node.id=art1
context.url=http://10.0.0.121:8081/artifactory
membership.port=10001
primary=true
hazelcast.interface=192.168.0.2 (optional)

Configure the binarystore.xml File

The default binarystore.xml that comes with Artifactory out-of-the-box contains the file-system template which uses the NFS.
Therefore, to setup your filestore so that it doesn't use the NFS, you need to modify this file.
Take care when modifying binarystore.xml
Making changes to this file may result in losing binaries stored in Artifactory!
If you are not sure of what you are doing, please contact JFrog Support for assistance.

We recommend using the cluster-file-system template which is one of the built-in templates that come with Artifactory out-of-the-box.
This configuration uses the default filestore location (under $ARTIFACTORY_HOME/data) to store binaries locally on the filesystem,
unless specified otherwise. A mechanism connected to all other nodes in the cluster is used to keep binaries synchronized and
accessible to all nodes, based on the required redundancy value (which is 2 by default).
How to use the cluster-file-system template
To learn how to configure your binarystore.xml to use the cluster-file-system template, please refer to Basic Configuration
Elements under Configuring the Filestore.

If your cluster has only two nodes, we recommend modifying the lenientLimit from its default value of 0 which would prevent
writes to Artifactory if one of the nodes goes down.

You are now ready to complete the HA installation process by installing the cluster nodes.

Using Cloud Storage With the NFS
Click here to expand for details...
To set up your HA cluster to use cloud storage with the NFS, follow these steps which are detailed below:
Create and configure $ARTIFACTORY_HOME/etc/ha-node.properties
Create an NFS mount
Configure the binarystore.xml file
Create ha-node.properties

Create the ha-node.properties file and populate it with the following parameters:
node.id

Unique descriptive name of this server.
Uniqueness
Make sure that each node has an id that is unique on your whole network.

context.url

membership.port

primary

artifactory.ha.data.dir

This property provides the full path to the root directory of your NFS binary storage.

artifactory.ha.backup.dir

This property provides the full path to the root directory of your Artifactory back-up data on the NFS.

hazelcast.interface

Host name

10.1.2.22

node.a

10.1.3.33

node.b

then the hazelcast.interface field should be set to 10.1.*.*
Another example, if you have two nodes with the following parameters:
Node

Host name

10.1.2.22

node.a

10.1.2.33

node.b

then the hazelcast.interface field should be set to 10.1.2.*

The example below shows how the ha-node.properties file might be configured for your cluster nodes to use cloud storage with the
NFS:

Escaping the backslash in Windows systems
Note that in Windows-based system the backslash characters in the paths to the ha-data and ha-backup directories need to be
escaped with another backslash. For example:
artifactory.ha.data.dir = \\\\windows\\UNC\\path\\ha-data
artifactory.ha.backup.dir = \\\\windows\\UNC\\path\\ha-backup

ha-node.properties file permissions
On Linux, once the ha-node.properties file is created, the Artifactory user should be set as its owner and its permissions
should be set to 644(-rw-r--r--)

Create an NFS mount

Create an NFS mount which will be accessible to all nodes. This mount will serve as the $DATA_DIR.
In addition, you need to set up a $BACKUP_DIR that must be accessible by the master node. It may be located on the same NFS mount,
however this is not compulsory.

Privileges
Each of the Artifactory cluster nodes must have full write privileges on the $DATA_DIR directory tree.

Configure the binarystore.xml file

The default binarystore.xml that comes with Artifactory out-of-the-box contains the file-system template. Therefore, to setup your
filestore so to use cloud storage with the NFS, you need to modify this file.

Warning: Take care when modifying the binarystore.xml file
Making changes to this file may result in losing binaries stored in Artifactory!
If you are not sure of what you are doing, please contact JFrog Support for assistance.

We recommend using either the s3 chain or the google-storage chain which are among the built-in chain templates that come with
Artifactory out-of-the-box. These chains use the shared filestore location (under $DATA_DIR) to store binaries in a staging area, before
they are moved to the cloud storage.
Tip: To learn how to configure your binarystore.xml to use the s3 and google-storage chain templates, please refer to Basic
Configuration Elements under Configuring the Filestore.
You are now ready to complete the HA installation process by installing the cluster nodes.

Using Cloud Storage Without the NFS
Click here to expand for details...
To set up your HA cluster to use cloud storage without the NFS, follow these steps which are detailed below:
Create and configure $ARTIFACTORY_HOME/etc/ha-node.properties
Configure the binarystore.xml file
Create ha-node.properties

Create the ha-node.properties file and populate it with the following parameters:
node.id

Unique descriptive name of this server.
Uniqueness
Make sure that each node has an id that is unique on your whole network.

context.url

The context url that should be used to communicate with this server within the cluster.
There are two ways to specify the context.url field:
As an explicit IP address
As a host name. In this case, you need to specify the hazelcast.interface field with wildcards. For
details, please refer to the description for hazelcast.interface field below.

membership.port

The port that should be used to communicate with this server within the cluster.
If not specified, Artifactory will allocate a port automatically, however we recommend to set this to a fixed value
to ensure that the port allocated is open to all of your organizations security systems such as firewalls etc.

primary

(true | false) Indicates if this is the primary server. There must be one (and only one) server configured in the
cluster to be the primary server. For other servers this parameter is optional and its value defaults to "false".

hazelcast.interface

[Optional] When nodes in the same cluster are running on different networks (e.g. nodes on different docker
hosts), set this value to match the server's internal IP address.
If you have specified the context.url as a host name, you need to use to the wildcard character (i.e., an
asterisk - '*') so as to include the server's internal IP address as well as that of all members in the cluster.
For example, if you have two nodes with the following parameters:
Node

Host name

10.1.2.22

node.a

10.1.3.33

node.b

then the hazelcast.interface field should be set to 10.1.*.*
Another example, if you have two nodes with the following parameters:
Node

Host name

10.1.2.22

node.a

10.1.2.33

node.b

then the hazelcast.interface field should be set to 10.1.2.*

ha-node.properties file permissions
On Linux, once the ha-node.properties file is created, the Artifactory user should be set as its owner and its permissions
should be set to 644(-rw-r--r-The example below shows how the ha-node.properties file might be configured for your cluster nodes to use cloud storage without
the NFS:

node.id=art1
context.url=http://10.0.0.121:8081/artifactory
membership.port=10001
primary=true
hazelcast.interface=192.168.0.2 (optional)

Configure the binarystore.xml File

The default binarystore.xml that comes with Artifactory out-of-the-box contains the file-system template. Therefore, to setup your
filestore so to use cloud storage without the NFS, you need to modify this file.
Take care when modifying binarystore.xml
Making changes to this file may result in losing binaries stored in Artifactory!
If you are not sure of what you are doing, please contact JFrog Support for assistance.
We recommend using either the cluster-s3 chain or the cluster-google-storage chain which are among the built-in templates that come
with Artifactory out-of-the-box. These templates use a mechanism connected to all other nodes in the cluster to keep binaries
synchronized and accessible to all nodes according to the required redundancy (which is 2 by default). Binaries are first stored locally on
each node (under $ARTIFACTORY_HOME/data/eventual by default), with additional copies on other nodes according to the
redundancy configured, before moving on to persistent cloud storage.
How to use the s3 and google-storage chain templates
To learn how to configure your binarystore.xml to use the cluster-s3 and cluster-google-storage chain templates, please
refer to Basic Configuration Elements under Configuring the Filestore.
You are now ready to complete the HA installation process by installing the cluster nodes.

Installing the Cluster Nodes
Once you have completed setting up your filestore configuration, the process for installing the cluster nodes is identical and described in the
steps below:
1.
2.
3.
4.
5.

Install the primary node
Create the bootstrap bundle
Add licenses
Set the cluster's URL Base
Add secondary nodes

Installing the Primary Node
Go through a regular installation of Artifactory Pro as described in Installing Artifactory, and then convert it to be the HA primary node by
adding the ha-node.properties file you created when you set up your storage configuration to the $ARTIFACTORY_HOME/etc. Do
not start up the instance yet.
Note that an external database must be configured for usage at this point, as mentioned in the Requirements section
You should also verify that your database JDBC driver is correctly located in $ARTIFACTORY_HOME/tomcat/lib for each Artifactory cluster
node.

Creating the Bootstrap Bundle
First, start up the primary node. Once your primary node is up and running, you can create the bootstrap bundle by calling the Create
Bootstrap Bundle REST API endpoint on the primary node. This creates the bundle, bootstrap.bundle.tar.gz, and stores it under $AR
TIFACTORY_HOME/etc. You will need the bootstrap bundle later on when adding secondary nodes.
Note: The bootstrap bundle file is only used when none of the files it includes are present in the corresponding locations in the secondary
cluster nodes. Once Artifactory is finished with it (either used it or deemed unnecessary) the bundle file is deleted as it contains sensitive files.
Tip: We recommend backing up the bootstrap bundle to a folder that is different from where the Artifactory cluster data or
ARTIFACTORY_HOME folder are located until you have added all your secondary nodes and have verified that the cluster is up and running
correctly.

Add Licenses
There are several ways you can add licenses to the cluster:
Using the Cluster License Manager UI or REST API as described in Adding Licenses
As part of the onboarding wizard you will get when you start up Artifactory for the first time
Using the YAML configuration file (NOTE: this will only work for the primary node)
Since currently, the only operative node is the primary node, you can install your licenses there. Once you add the secondary nodes to the
cluster, they will be licensed automatically through the Cluster License Manager.

All licenses used must be Enterprise licenses.

Set the URL Base
After you have installed the node and verified that your system is working correctly as an HA installation, you should configure the Custom
URL Base.
In the Admin tab under Configuration | General, set the Custom URL Base field to the URL of the Load Balancer.

Add Secondary Nodes
You should also verify that your database JDBC driver is correctly located in $ARTIFACTORY_HOME/tomcat/lib for each Artifactory cluster
node.
To add secondary nodes, for each node, follow these steps:
1. Create an ha-node.properties file according to how you want to set up your storage configuration.
2. Go through a new Artifactory Pro installation as described in Installing Artifactory. Do not start up the instance yet.
Note that an external database must be configured for usage at this point, as mentioned in the Requirements section
3. Once the Artifactory Pro installation is complete, add the ha-node.properties file you created to the $ARTIFACTORY_HOME/etc
folder.
4. Copy the bootstrap bundle you created on the primary node, bootstrap.bundle.tar.gz, to the $ARTIFACTORY_HOME/etc fold
er on the secondary node.
Warning: Bootstrap Bundle and db.properties

This is a critical step in the upgrade process. The bootstrap bundle must be installed in each secondary node before you start it up
for it to operate correctly in the cluster.
Note also, if the $ARTIFACTORY_HOME/etc folder in your secondary node already contains a db.properties file, make sure to
remove it. Presence of this file will prevent the bootstrap bundle from being properly extracted when you start up the secondary node
causing the upgrade to fail.
5. Start up the cluster node. Upon starting up, the node is automatically allocated a license by the Cluster License Manager, and is
automatically configured through the bootstrap bundle.
6. Test your HA configuration after each cluster node that you add to your system.
Warning: Ensure network communication
Make sure that network communication is enabled between the cluster nodes for each of the following:
context.url
hazelcast.interface and membership.port (used together. For example, 172.24.0.1:10001)

Upgrading Artifactory HA
Upgrading Artifactory HA depends on which version you are starting from. For detailed instructions, please refer to Upgrading an Enterprise
HA Cluster.

Testing Your HA Configuration
The following are a series of tests you can do to verify that your system is configured correctly as an HA installation:
1. Directly Access the Artifactory UI for the server you have just configured
2. In the Admin module go to Advanced | System Logs to view the log and verify that you see an entry for HA Node ID.

3. The bottom of the module navigation bar should also indicate that you are running with an Enterprise licens. In case of an error you
will see an error message in the page header.

6. In the Admin module under Configuration | General, verify that the Custom URL Base field is correctly configured to the URL of
the Load Balancer.

Cluster License Management
Artifactory 5.0 introduces an automated license management interface for HA clusters through which all licenses are allocated automatically
to nodes as they are added to the cluster. A batch of licenses can be added through the UI and REST API to any node in a cluster.
A new node starting up will request an available license from the pool automatically, and will be allocated the license with the latest expiry
date. The license is also automatically returned to the pool if the node is shut down or removed from the HA cluster.
Which license is allocated?
Note that adding a license through a node does not necessarily mean that the license will be attached to that specific node. The
license is added to the pool available and the available license with the latest expiry date will be allocated to the node.
Once you have purchased a set of licenses, they are provided to you as a space-separated or newline-separated list.

Adding Licenses
There are three ways that licenses can be added to an HA cluster:
Through the UI
Using the REST API
Adding them to the primary node's filesystem (for automation).
Specifying multiple licenses
When specifying multiple licenses, whether in the Artifactory UI, using the REST API or in the artifactory.cluster.license
file, make sure that the licenses are separated by a newline.

Using the UI

Through the UI, in the Admin module, under Configuration | Artifactory Licenses, you can view all licenses uploaded to your cluster.

To add licenses to your cluster, click New and copy your license key(s) into the License Key entry field. You can also simply drag and drop
the file containing the license key(s) into the same field. Make sure that each license is separated by a newline.

Using the REST API

You can also add licenses through the Install License REST API endpoint
Using the Primary Node's Filesystem

To accommodate spinning up Artifactory HA nodes using automation, before booting up your primary node, you can place the artifacto
ry.cluster.license file in its $ARTIFACTORY_HOME/etc folder. Upon being booted up, the primary node automatically extracts one of
the licenses.
Similarly, upon being started up, each secondary node also automatically extracts one of the remaining available licenses.

License Expiry
Nodes running with a license that is about to expire will automatically be updated with a new license available from the pool. Artifactory
administrators can manually delete the expired license from within the UI or using REST API.

Deleting Licenses
A license can be deleted under one the following conditions:
It is not currently being used,
There is an alternative license available in the pool. In this case, the node to which the deleted license was attached will
automatically be allocated with an alternative license.
Perpetual License
Note that Artifactory licenses are perpetual and may continue to activate an Artifactory instance indefinitely, however, an instance
running on an expired license may not be upgraded and is not eligible for support.

REST API
You can manage your Artifactory HA licenses using the HA License Information, Install HA Cluster Licenses and Delete HA Cluster License R
EST API endpoints.

Screencast

Managing the HA Cluster
Overview

You can view the status of, and manage your HA cluster nodes in the Admin module under Configuration |
High Availability.
This screen displays a table with details on all the Artifactory nodes in your cluster as displayed below:

Page Contents
Overview
Monitoring for
Unresponsive Nodes
Removing an Unused
Node

The table columns are as follows:
Unique descriptive name of the server.
ID

The time that the server was started .
Start Time

The context URL that should be used to communicate with this server within the cluster.
URL

The port that should be used to communicate with this server within the cluster.
Membership
Port

The current state of the server as follows:
State

Offline - The node has started in an invalid state (For example, same HA license, or the same node id has been set on two
different nodes). In this case you should the specific server logs for details.
Starting - The node is starting up.
Running - The node is up and running. This is the normal state for a node.
Stopping - The node is in the process of shutting down.
Stopped - The node is shut down.
Converting - The node is converting database tables and configuration files.
The role of the server as follows:

Role

Primary - The primary node.
Member - A regular member node.
Standalone - The node is not configured into your HA cluster. It is running as a separate
installation of Artifactory (Pro or Open Source).
The last time this server signaled that it is up and running. By default, each node signals every 5 seconds.
Last
Heartbeat

The Artifactory version running on this cluster node.
Version

The Artifactory revision number running on this cluster node.
Revision

The Artifactory release running on this cluster node.
Release

Monitoring for Unresponsive Nodes
You can use the Last Heartbeat field to identify unresponsive nodes. If a node abruptly stops working (e.g. system crash on the server), then it
may not be able to correctly update its State value, and will continue to appear as Running.
However, since the server Heartbeat does not get updated for a long interval of time, it is displayed in red with a warning sign as displayed below.
In this case you should check that the corresponding server is up and running and fully connected to your HA cluster and the database.

Removing an Unused Node
If you remove a node from your cluster, it will still appear in your database and will therefore be displayed in the list of cluster nodes.
To avoid confusion you should remove it from your list of cluster nodes (and detach it from the database) so that it doesn't interfere with normal
cluster behavior.
To do so, hover over the corresponding server from the list and click "Delete".

When to remove a node
The "Remove" button is only available once a node has not signaled a Heartbeat for a "long" time.
We recommend that you only remove a node from your list if it has indeed been removed from your system.

the Heartbeat will not be updated and
Artifactory will alert you to this as described in the previous section.
In case of an error in one of the nodes, or if a node is shut down for maintenance,

In this case there is no need to remove the node from your list. Once you fix the error and restart the
server the Heartbeat will be updated and the warning will be dismissed.

Migrating Data from NFS
Overview
Previous to version 5.0, an Artifactory HA installation stored binaries and configuration files on an
NFS mount. This mount was used by the $CLUSTER_HOME folder to synchronize configuration
and binary files between the cluster nodes. From version 5.0, you have the option of migrating your
binaries to alternative storage which presents the following advantages:
The filestore can be distributed between the cluster nodes or on a cloud storage provider
(S3)
Limitations of the network (such as file size limits) no longer affect the filestore
The cluster nodes do not require access to one central location
Once removed from the NFS, binaries are stored with redundancy in a clustered sharding
configuration
This page is designated for users who have upgraded their Artifactory HA installation from version
4.x to version 5.x. During the upgrade process, all configuration files will have been migrated to the
database, and will be synchronized and managed there henceforth, however, the data in these
installations is still stored on an NFS mount under the $CLUSTER_HOME/ha-data folder which
leaves you still reliant on the NFS. While you may continue operating in this mode, you also have
the option of migrating your data to alternative storage and removing the NFS mount.
Migrating data is optional. NFS is still supported.
While migrating your data from NFS presents the advantages described above, this is
optional. Artifactory 5 still supports an HA cluster storing its data on the NFS.
The instructions on this page describe how to move your binary data away from the $CLUSTER_HO
ME/ha-data folder on the NFS mount allowing you to remove the mount altogether. We will cover
three main use cases:

Use Case

Initial State

Page contents
Overview
Configuring the
Migration
Verifyi
ng
Versio
ns
Verify
Config
uration
Files
are
Synchr
onized
Edit
the
ha-nod
e.prop
erties
File
Copy
Data
to the
New
Locati
on

Use Case 1: NFS Lo
Use Case 2: NFS Eve
Use Case 3: NFS Lo

Final State

NFS:
All data is stored on the NFS

Local FS:
All data is stored on each
node's local file system

NFS Eventual + S3:
NFS is used as the Eventual
Binary Provider before copyin
g data over to S3 for
persistent object store

Local FS Evenutal + S3:
Each node's local file system
is used as the Eventual
Binary Provider before
copying data over to S3 for
persistent object store

NFS:
All data is stored on the NFS

Local FS Evenutal + S3:
Each node's local file system
is used as the Eventual
Binary Provider before copyin
g data over to S3 for
persistent object store

Config
ure
binary
store.x
ml

Local FS
Local FS Eventual + S
Testin
g Your
Config
uration

For all these use cases, once the data has been migrated, you will be able to completely remove
the NFS mount.

Configuring the Migration
Before migrating your data away from the NFS, make sure all nodes in your HA cluster are up and running. Then, to configure migration of
your data for the use cases described above, follow the procedure below:
1.
2.
3.
4.
5.
6.

Verify versions
Verify configuration files are synchronized
Edit the ha-node.properties file
Copy data to the new location
Configure binarystore.xml to match your setup
Test the configuration

Verifying Versions
Before proceeding with transferring your data, you need to verify that all cluster nodes are installed with exactly the same version which must
be 5.0 and above. To verify the version running on each node in your HA cluster, in the Admin module under Configuration | High
Availability, check the Version column of the table displaying your HA nodes.

Verify Configuration Files are Synchronized
When upgrading your HA cluster from version 4.x to version 5.x, an automatic conversion process synchronizes the configuration files for all
the cluster nodes. This replaces the need for the $CLUSTER_HOME/ha-etc folder that was used in v4.x. Once you have verified that all
nodes are running the same version, you should verify that all configuration files are synchronized between the nodes. For each node,
navigate to its $ARTIFACTORY_HOME/etc folder and verify the following:
Each node should still have this file configured as described in Create ha-node.properties
ha-node.properties

db.properties

binarystore.xml

communication.key

This file was introduced in Artifactory 5.0 and it defines the connection to the database. The password specified in
this file is encrypted by the key in the communication.key file. It should be identical in each cluster node.
This file opens up the full set of options to configure your binary storage without the NFS. It will contain the binary
provider configuration according to how you wish to store your binaries. For each of the use cases described above,
you can find the corresponding binary provider configuration under Configure binarystore.xml.
This file contains the key used to encrypt and decrypt files that are used to synchronize the cluster nodes. It should
be identical on each cluster node.

From version 5.0, Artifactory HA synchronizes configuration files from the primary to all secondary nodes, a change made to one of these files
on the primary triggers the mechanism to synchronize the change to the other nodes.
Sync carefully
Since changes on one node are automatically synchronized to the other nodes, take care not to simultaneously modify the same
file on two different nodes since changes you make on one node could overwrite the changes you make on the other one.

Edit the ha-node.properties File
Locate the ha-node.properties file in each node under the $ARTIFACTORY_HOME/etc and comment out or remove the following entries
otherwise Artifactory will continue write according to the previous path you have configured to the shared file system.

artifactory.ha.data.dir=/var/opt/jfrog/artifactory-ha
artifactory.ha.backup.dir=/var/opt/jfrog/artifactory-backup

Copy Data to the New Location
Once you have verified your configuration files are correctly synchronized, you are ready to migrate your data. The sub-sections below
describe how to migrate your data for the three use-cases described in the Overview above.

Use Case 1: NFS Local FS
For this use case, we first need to ensure that there is enough storage available on each node to accommodate the volume of data in my /da
ta folder and the desired redundancy. In general, you need to comply with the following formula:

Max storage * redundancy < total space available on all nodes

For example,
If you expect the maximum storage in your environment to be 100 TB

Your redundancy is 2
You have 4 nodes in your cluster,
Then each node should have at least 50 TB of storage available.
For a redundancy of N, copy the data from your NFS to N of the nodes in your cluster.
For example, for a redundancy of 2, and assuming you have two nodes named "Node1" and "Node2" respectively, copy the $CLUSTER_HOME
/ha-data folder to the $ARTIFACTORY_HOME/data folder on each of Node1 and Node2.
Optimize distribution of your files
Once you have copied your filestore to to each of the N nodes according to the desired redundancy, we recommend invoking the
Optimize System Storage REST API endpoint in order to optimize the storage by balancing it storage amongst all nodes in the
cluster.

Use Case 2: NFS Eventual + S3: Local FS Eventual + S3
This use case refers to using S3 as persistent storage, but is equally applicable to other cloud object store providers such as GCS, CEPH,
OpenStack and other supported vendors.
In this use case, you only need to ensure that there are no files in the eventual folder of your NFS. If any files are still there, they should
be moved to your cloud storage provider bucket, or to one of the nodes' eventual folder.

Use Case 3: NFS Local FS Eventual + S3
Migrating a filestore for a single installation to S3 is normally an automatic procedure handled by Artifactory, however, in the case of moving
an HA filestore from the NFS, the automatic procedure does not work since the folder structure changes.
In this case, you need to copy the data under $CLUSTER_HOME/ha-data from your NFS to the bucket on your cloud storage provider (here
too, other providers described in Use Case 2 are also supported) while making sure that there are no files left in the _queue or _pre folders
of the eventual binary provider on your node's local file system.

Configure binarystore.xml
In this step you need to configure the binarystore.xml to match the setup you have selected in the use case. Note that the three use cases
above use one of two final configurations:
All data is stored on the cluster node's local filesystem (labelled here as Local FS)
The cluster nodes use the cluster node's local filesystem as an eventual binary provider and data is persistently stored on S3 (labelled here
as Local FS Eventual + S3)
Node downtime required
To modify the binarystore.xml file for a node, you first need to gracefully shut down the node, modify the file and then restart the
node in order for your new configuration to take effect

Local FS
In this example, all data is stored on the nodes' file systems. For the sake of this example, we will assume that:
We have 3 nodes
We want redundancy = 1
To accomplish this setup, you need to:
Copy the data from the $CLUSTER_HOME/ha-data on your NFS to the $ARTIFACTORY_HOME/data folder on two of the nodes.
Once all data has been copied, you need to place the binarystore.xml under $ARTIFACTORY_HOME/etc of each cluster node.
Finally, you need to gracefully restart each node for the changes to take effect.
Optimizing the redundant storage
After restarting your system, you can trigger optimization using the REST API so that all three nodes are utilized for redundancy.
For details, please refer to Optimize System Storage.
Example
In this use case, the binarystore.xml used with the NFS before migration would look like the following if you are using one of the default

file-system template.

After migrating the data, the new binarystore.xml placed on each cluster node you can use the cluster-file-system template.

While you don't need to configure anything else, this is what the cluster-file-system template looks like:
Redundancy leniency
We recommend adding the lenientLimit parameter to the below configuration under the sharding-cluster provider configuration:
1
Without this parameter, Artifactory won't accept artifact deployments while the number of live nodes in your cluster is lower than the
specified redundancy.

local

remote

crossNetworkStrategy
crossNetworkStrategy
2

Local FS Eventual + S3
In this example, data is temporarily stored on the file system of each node using an Eventual binary provider, and is then passed on to your
S3 object storage for persistent storage.
In this use case, the binarystore.xml used your NFS for cache and eventual with your object store on S3 before migration will look like the
following if you are using the S3 template.

After migrating your filestore to S3 (and stopping to use the NFS), your binarystore.xml should use the cluster-s3 template as follows:

The cluster-s3 template looks like this:
Redundancy leniency
We recommend adding the lenientLimit parameter to the below configuration under the sharding-cluster provider configuration:
1
Without this parameter, Artifactory won't accept artifact deployments while the number of live nodes in your cluster is lower than the
specified redundancy.

crossNetworkStrategy
crossNetworkStrategy
2

remote

local

http://s3.amazonaws.com
[ENTER IDENTITY HERE]
[ENTER CREDENTIALS HERE]
[ENTER PATH HERE]
[ENTER BUCKET NAME HERE]

Because you must configure the s3 provider with parameters specific to your account (but can leave all others with the recommended
values), if you choose to use this template, your binarystore.xml configuration file should look like this:

http://s3.amazonaws.com
[ENTER IDENTITY HERE]
[ENTER CREDENTIALS HERE]
[ENTER PATH HERE]
[ENTER BUCKET NAME HERE]

Testing Your Configuration
To test your configuration you can simply deploy an artifact to Artifactory and then inspect your persistent storage (whether on your node's file
system on your cloud provider) and verify that the artifact has been stored correctly.

Troubleshooting HA
Artifactory Does Not Start Up
There are no log file entries in $ARTIFACTORY_HOME/logs/artifactory.log

Cause

Resolution

Something within your $ARTIFACTORY_HOME or $CLUSTER_HOME
directory is either not defined, or misconfigured
In some cases in which the $ARTIFACTORY_HOME directory tree is not
validly constructed, log file entries are written to $ARTIFACTORY_HOME
/logs/catalina/localhost//logs. Check the contents of this file to see
which specific errors were logged.

After restarting a cluster node which uses a shared NFS mount, the startup fails

Cause

The $NFS_MOUNT/ha-etc still contains the bootstrap bundle archive used for the last upgrade. Artifactory tries
redeploy the archive's contents to its respective locations under the $ARTIFATORY_HOME and runs in a conflict. The
jfrog-access.bootstrap.log shows the following output:

[jfrog-access] [INFO ] Found bootstrap bundle file:
/clusterhome/ha-etc/bootstrap.bundle.tar.gz
[jfrog-access] [INFO ] Deploying bootstrap bundle file
to: /var/opt/jfrog/artifactory

Resolution

Delete the bootstrap bundle archive from the $NFS_MOUNT/ha-etc folder. Restart the node and the startup should
succeed.

The log says "Stopping Artifactory start up ,another server running converting process".
You are upgrading more than one server at a time.
Cause

Resolution

When upgrading your system, make sure you complete the upgrade
process on one server before starting to upgrade the next one.

The log says "Stopping Artifactory start up ,another server with different version has been
found".

Cause

You are trying to install different versions of Artifactory into the same
system.

Resolution

Make sure that all the instances of Artifactory installed in your system are
the same version.

The log says "Stopping Artifactory since duplicate node ids have been found in registry. If
you restarted this server, make sure to wait at least 30 seconds before re-activating it"
This may happen in one of two cases:
Cause

Resolution

1. Two servers are configured into your system with the same node.id
specified in the $ARTIFACTORY_HOME/etc/ha-node.propertie
s file.
2. You have shut down an Artifactory server and tried to restart it within
30 seconds.
Make sure that all servers within your Artifactory HA installation have a
unique node.id value.
Shut down your server and wait at least 30 seconds before you restart it.

The log says "Node could not join cluster. A Configuration mismatch was detected:
Incompatible partition count! expected: 8, found: 1 Node is going to shutdown now!"

Cause

Resolution

A new node has new Artifactory Hazelcast system property values
defined $ARTIFACTORY_HOME/etc/artifactory.system.propert
ies file and it is trying to join a cluster with nodes with different Hazelcast
property values.
Make sure that all servers within your Artifactory HA installation have the
same values.
Shut down your cluster (not rolling restart), start the nodes one by one.

Page Contents
Artifactory Does Not Start Up
Artifactory Starts Up But Remains
Offline
Artifactory UI login still prompts for
credentials after a successful
attempt
Artifactory Starts Up But Not as an
HA Installation
A Cluster Node Does Not
Synchronize with Other Nodes
Upgrading from Version 5.4.5 or
Below to Version 5.5 or Above Fails

Artifactory Starts Up But Remains Offline
The log says "Changing Artifactory mode to offline since the server is configured as HA but the license does not exist or is not an HA License"

Your server does not have a valid HA license installed
Cause

Install a valid HA license in your server and restart it
Resolution

The log says "Changing Artifactory mode to offline since the local server is running as HA but found no HA server in registry."

Cause

You are starting an Artifactory server as an HA installation, however you already have an Artifactory Pro (or OSS version)
running within the same system.

Resolution

Make sure your system is consistent - either you have a set of Artifactory Pro instances running separately, or you all of your
servers are configured as Artifactory HA

The log says "Could not find cluster properties"
Your $CLUSTER_HOME/ha-etc/cluster.properties file is not defined.
Cause

Resolution

When installing Artifactory HA, you need to manually create a $CLUSTER_HOME directory and the $CLUSTER_HOME/ha-et
c/cluster.properties file. For details please refer to Configuring the Cluster.

Artifactory UI login still prompts for credentials after a successful attempt
Artifactory version 5.x and above running with Hazelcast allow UI logins made without sticky session/persistance configuration required on the
load balancer.

Cause

You have not opened the required Hazelcast ports (Artifactory's nodes syncronized memory component) which are
configured under:
$ARTIFACTORY_HOME/etc/ha-node.properties file

Resolution

1. Open the membership ports on your operating system level
2. Ensure communication to the newly opened ports from the membering cluster nodes
3. Verify that the UI login works now (no restart is needed)

Artifactory Starts Up But Not as an HA Installation
Artifactory starts up as an instance of Artifactory Pro
You have not created a valid $ARTIFACTORY_HOME/etc/ha-node.properties file
Cause

Resolution

1.
2.
3.
4.
5.
6.
7.
8.

Shutdown the node
Delete the $ARTIFACTORY_HOME/access folder
Delete the $ARTIFACTORY_HOME/etc/security/access folder
Delete $ARTIFACTORY_HOME/etc/security/communication.key
Delete $ARTIFACTORY_HOME/etc/binarystore.xml
Delete $ARTIFACTORY_HOME/etc/db.properties
Delete $ARTIFACTORY_HOME/etc/cluster.id
Copy the bootstrap bundle you created on the primary node, bootstrap.bundle.tar.gz, to the $ARTIFACTORY_HO
ME/etc folder on the secondary node.
9. Ensure that the bundle is owned by artifactory user (chown artifactory:artifactory bootstrap.bundle.tar.gz)
10. Create a valid $ARTIFACTORY_HOME/etc/ha-node.properties file as described in Installing Artifactory HA.
11. Start up the node

A Cluster Node Does Not Synchronize with Other Nodes

The node does not contain the right bootstrap bundle
The node was installed without the right bootstrap bundle (bootstrap.bundle.tar.gz) or no bootstrap bundle at all.
Cause

Install the right bootstrap bundle using the following procedure:
Resolution

1.
2.
3.
4.
5.
6.
7.
8.

Upgrading from Version 5.4.5 or Below to Version 5.5 or Above Fails
The log says "To upgrade your HA installation to this version, you first need to upgrade to version 5.4.6 which implements changes required to
accommodate a database schema change."

Cause

Resolution

Artifactory 5.5 introduces a change to the database schema. To upgrade to this version or above, the database must first be
migrated to the new schema
Artifactory 5.4.6 implements a process that performs the required database schema migration. To upgrade to version 5.5 or
above from version 5.4.5 or below, you first need to upgrade to version 5.4.6 using the normal upgrade procedure according
to your installation type, and then upgrade to your desired version (5.5 or above), also using the normal upgrade procedure.

Xray Integration
Overview
JFrog Xray is a universal binary analysis product that works with Artifactory to analyze software components,
and reveal a variety of issues at any stage of the software application lifecycle. By scanning binary
components and their metadata, recursively going through dependencies at any level, JFrog Xray provides
unprecedented visibility into issues lurking in components anywhere in your organization. As a
complementary product to Artifactory, JFrog Xray has access to the wealth of metadata Artifactory stores
which, combined with deep recursive scanning, puts Xray in a unique position to analyze the relationships
between binary artifacts and provide radical transparency into your component architecture to reveal the
impact that an issue in one component has on any other.
For more information about the types of analyses that Xray performs, please refer to Watches in the JFrog
Xray User Guide.

How Does It Work
For Xray to perform its analyses it needs to be connected to an instance of Artifactory in order to access its
repositories and metadata. Once connected, Xray can index the artifacts in Artifactory's repositories to
efficiently access them for Scanning or Impact Analysis. Since the indexing process is resource intensive,
Xray does not automatically analyse all of your repositories; you need to specify which repositories should be
indexed. All builds are indexed automatically.

Version Compatibility
JFrog Xray can connect to Artifactory from version 4.0 and above.
Page Contents
Overview

How Does It Work
Version Compatibility
Configuring the Integration
Connecting to JFrog Xray
Specifying Repositories for Analysis
Per Repository
In Bulk
Configuring Download Blocking
Indexing Artifacts

Configuring the Integration
Configuring Artifactory to work with JFrog Xray involves the following three main steps:
1. Connecting Artifactory to JFrog Xray
2. Specifying repositories whose artifacts should be indexed for analysis by Xray and configuring download blocking
3. Indexing artifacts
In addition, JFrog Xray should be properly configured as described in Configuring Xray in the JFrog Xray User Guide

Connecting to JFrog Xray
The connection between Artifactory and Xray is established by Xray which creates a user with "admin" privileges called xray in Artifactory in order
to access the data it needs to perform its different analyses and functions.
For details, please refer to Connecting to Artifactory in the JFrog Xray User Guide.

Specifying Repositories for Analysis
For Xray to analyze the artifacts in your installation efficiently, it first needs to index them in its database. If Xray were to index and analyze all of
the artifacts in your Artifactory installation, that could cause excessive processing and cluttered component graphs which may obscure the
significant components you are really interested in. Therefore, to let you focus on the most important artifacts in your Artifactory installation, Xray
will only analyze artifacts from repositories your mark for indexing. There is no need to specify builds; all builds are automatically indexed by Xray.
Repositories marked for indexing by Xray are found in the Admin module under Configuration | JFrog Xray

To enable analysis of repositories in general, you first need to globally enable Xray by setting the Enable Xray Integration checkbox.

Once repositories are marked for analysis, Xray will index (and reindex) their artifacts based on different triggers such as adding, deleting and
moving artifacts. Artifacts in all builds are indexed automatically by JFrog Xray and re-indexed each time a new build is created.
There are two ways to specify repositories whose artifacts should be indexed:
1. Per repository
2. In bulk

Per Repository
To specify a specific repository for indexing, in the repository Basic configuration, under Xray Integration, check Enable Indexing in Xray.

In Bulk
The Xray Integration screen displays the repositories that have been enabled for indexing. To add more repositories for indexing, click Add.

From the list of Available Repositories select the repositories you wish to add for indexing and click "Save".

Configuring Download Blocking
To prevent potentially harmful artifacts from being used by developers, an administrator can prevent them from being downloaded from Artifactory
using the following two settings in the repository Basic configuration, under Xray Integration:

Block Unscanned
Artifacts

Block Downloads With
Severity Above

When checked, Artifactory will block download of artifacts from this repository until they have been scanned by
JFrog Xray.

When set, Artifactory will block download of artifacts that have been identified to include an issue with a
severity of the degree selected at least.

Once these parameters are set, a System Watch is created in Xray to detect artifacts that meet the set specifications and block their being
downloaded.

Indexing Artifacts
Once JFrog Artifactory and JFrog Xray have been configured to work together, artifacts will be indexed for analysis on an ongoing basis according
to different events that happen in Artifactory. To set up the initial database of artifacts Xray, you need to invoke indexing manually. For details,
please refer to Indexing Artifacts in the JFrog Xray User Guide.

Bintray Integration
Bintray is JFrog's platform for storage and distribution of software libraries on the cloud. It is the new way for
developers to publish, download and share software across one unified community around the world. The
free, cloud-based platform empowers developers to control and streamline the entire process of making
software libraries publicly available, with all the services needed to collaborate, advertise and deploy a new
software solution.
Distributing Software Through Bintray
For details on how to use Bintray, please refer to the Bintray User Guide.
Naturally, Artifactory integrates with Bintray in more than one way:
Remote Search in Bintray's JCenter repository - the most comprehensive collection of Maven
artifacts.
Information insight from Bintray on artifacts - package description and latest released version.
Pushing artifacts to Bintray through a Distribution Repository.
Complete continuous delivery stack for selected OSS projects based on oss.jfrog.org and Bintray.

Read More
Bintray info panel
Distribution Repository
Deploying Snapshots to oss.jfrog.org

Bintray info panel
Overview
As part of Artifactory's integration with Bintray information about components stored in Bintray is fetched and
displayed in the Tree Browser under Package Information.
To view Bintray Package Information:
You need to be logged in
You need to have the Bintray user and API Key configured in your Artifactory profile.
The selected file type is supported (e.g., pom, jar, war, ear)
Page Contents
Overview

Distribution Repository
Overview
Artifactory takes its integration with JFrog Bintray to the next step with Distribution Repositories. Distribution
repositories provide an easy way to move artifacts from Artifactory to Bintray, for distribution to end users. As

opposed to other repositories in Artifactory, distribution repositories are not typed to a particular package
format, but rather, are governed by a set of rules that specify how an artifact that gets to the distribution
repository should be routed to its corresponding repository in Bintray.

Configuring a Distribution Repository
You can access your distribution repositories in the Admin module under Repositories | Distribution.

Page Contents
Overview
Configuring a Distribution Repository
Connecting to Bintray
Basic Distribution Parameters
Advanced Settings
Managing Rules
Rule Order
Specifying Rule Parameters
Repository and Path Filter Parameters
Using Unnamed Capture Groups
Using Named Capture Groups
Enumerating Capture Groups
Distributing Artifacts
Distributing Through the UI
Dry Run
Distributing via REST API

To set up a new distribution repository, click New and execute the following main steps:
1.
2.
3.
4.

Connect to Bintray - obtain authorization from your Bintray account for Artifactory to connect and deploy packages
Configure distribution - specify basic distribution parameters
Configure Advanced Settings - specify advanced settings
Define rules - specifies the rules that govern how this distribution repository will deploy packages to Bintray

Connecting to Bintray
Artifacts are synchronized from your Artifactory distribution repository to Bintray through a Bintray organization to which you have administration
privileges. To set up the connection, you first need authorize Artifactory to access your Bintray organization. Artifactory will display a popup dialog
where you can enter your Bintray credentials.

Already logged into Bintray?
If you are already logged into your Bintray account, Artifactory will skip this step
After authorizing access to your account, you need to select the organization in that account that you authorize Artifactory to manage.

Bintray will issue an authorization code which you need to copy, and then paste in your distribution repository configuration.

When you close the popup with the authorization code, Artifactory will display a popup for you to enter it.

Once the process is complete, you can verify that Artifactory has been authorized to access your Bintray organization, in that organization's profile
page under OAuth Applications.

Basic Distribution Parameters
Once you have set up Artifactory as an authorized application in your Bintray organization, you can set up the distribution parameters

Repository Key

The repository key.

General

Description

A description of the repository.

Bintray Product

Use This Repository
To Distribute a Product

When set, indicates that artifacts distributed through this repository should be linked to a product. Artifactory will
create the product (if necessary) and link deployed packages to the product.

Product Name

The product name.

Bintray Application

customer ID

The client ID assigned by Bintray to Artifactory as an authorized application.

Organization

The Bintray organization which Artifactory is authorized to manage for distribution.

Default Repository
Settings

If Artifactory creates a new repository on Bintray for distribution, this setting specifies if the repository should be
private or public. If the repository exists, Artifactory will not override its access regardless of this setting.

Default Package
Settings

Licenses

Specifies the OSS licenses that should be attached to any packages distributed through this repository.

VCS URL

Specifies the VCS URL for packages distributed through this repository.

Advanced Settings

Select a proxy to use when synchronizing artifacts to Bintray.
Proxy

When set, Artifactory will GPG sign artifacts synchronized to Bintray.
GPG Signing

The passphrase to use for GPG signing.
GPG Passphrase

Map Properties to Bintray
Attributes

Specify a list of properties which, if they annotate the artifact distributed, should be mapped to version
attributes in Bintray.

Managing Rules
As opposed to local, remote and virtual repositories in Artifactory, distribution repositories are not limited to a specific package type. Instead, you
specify a set of rules, based on package type, and different filters, that give you fine-grained control over how different packages are pushed to
Bintray for distribution. To view the rules defined for your repository, click the Rules tab. New distribution repositories come with a pre-defined set
of rules which you can modify, delete or add to as needed.

Filtering and deleting
Start typing the name of a rule in the filter box to find the rule you are looking for.
Hover over a rule and click the delete icon on the right to delete it, or select a number of rules in the left column and click Delete to
remove several rules at a time.

Rule Order
The order in which rules are displayed specifies the order in which they are applied. To change the rule order, you can select a rule and drag it to
a new location in the list.
Conflicting rules
While it is possible to specify rules that conflict, since rules are applied in the order in which they appear, the first rule that is applied will
take precedence.

Specifying Rule Parameters

To specify rule parameters, click New for a new rule, or the Name of a rule you want to edit.

Name

A logical name for this rule

Parameters that determine which packages in Artifactory this rule applies to.
Artifactory
Input

Package
Type

Specifies the artifact package type for which this rule should be applied. Artifacts of other package types are ignored

Available
Tokens

According to the package type selected, this specifies which tokens can be used to specify the deployment path in Bintray

Repository
Filter

Wildcard expression that specifies for which original source repositories this rule should be applied. Packages in other
repositories are ignored.

Path Filter

Wildcard expression that specifies the artifact path for which this rule should be applied. Packages that have a different path
are ignored.

Parameters that determine how artifacts should be deployed to Bintray.
Output
Bintray

Repository

The Bintray repository to which artiafcts should be deployed.

Package

The Bintray package in the specified Bintray repository to which the artifact should be deployed. If the package does not exist,
it will be created

Version

The Bintray version in the specified Bintray package and repository to which the artifact should be deployed. If the version does
not exist, it will be created.

Path

The path in Bintray into which the artifact should be deployed in the specified repository.

Repository and Path Filter Parameters
Rules give you enormous flexibility in how you deploy artifacts to Bintray through use of regular expressions with capture groups where the
capture groups may be named or unnamed.
Unnamed capture groups are back-referenced using placeholder tokens, while named capture groups are back-referenced using their names.

Using Unnamed Capture Groups
For each regular expression used in Repository Filter or Path Filter fields of the Artifactory Input section, you can place tokens in fields of the
Bintray Output section to back-refrence them.
Tokens are written using the following format:

${source:x}

where:
source

path: A wildcard from the Path Filter field should be replaced
repo: A wildcard from the Repository Filter field should be replaced

The wildcard number.

For example,
${path:1} means replace the first regular expression in the Path Filter field
${repo:2} means replace the second regular expression in the Repository Filter field
Example 1

Under Artifactory Input, set Path Filter = jfrog-(.*).rpm
Under Bintray Output, set Repository = rpm-${path:1}
With these settings, a package called jfrog-artifactory.rpm will be deployed to a repository in Bintray called rpm-artifactory, while a
package called jfrog-mission-control.rpm will be deployed to a repository in Bintray called rpm-mission-control
Example 2

Under Artifactory Input, Repository Filter = libs-(.*)
Under Bintray Output, Repository = rpm-${repo:1}
With these settings:
A package called jfrog-artifactory.rpm from libs-release-local will be deployed to a repository in Bintray called rpm-release-lo
cal.
A package called jfrog-artifactory.rpm from libs-snapshot-local, will be deployed to a repository in Bintray called rpm-snapshotlocal.

Using Named Capture Groups
You can give capture groups in the Repository Filter or Path Filter fields of the Artifactory Input section specific names and then
back-reference the capture group using its name in the fields of the Bintray Output section.
Named capture groups are written using the following format:

(?regex)

where:
name

A logical name for the capture group

regex

The regular expression that defines repositories or paths that should pass through the filter

Once capture groups are defined, you can back-reference them in the fields of the Bintray Output section using the following format:

$(source:name)

where:
source

path: A capture group from the Path Filter field should be back-referenced
repo: A capture group from the Repository Filter field should be back-referenced

name

The name of the capture group.

Example 1

If you set:
Under Artifactory Input, Repository Filter = (?-local)
Under Bintray Output, Repository= generic-$(repo:myRepo)
Then a package in repository builds-local will be deployed to a repository in Bintray called generic-builds.
Example 2

If you set:
Under Artifactory Input, Path Filter = jfrog-(?.*).rpm
Under Bintray Output, Repository= rpm-$(path:myPath)
Then a package called jfrog-artifactory.rpm in repository libs-release-local will be deployed to a repository in Bintray called rpm-a
rtifactory, while a package called jfrog-mission-control.rpm will be deployed to a repository in Bintray called rpm-mission-contro
l.

Enumerating Capture Groups
You can use multiple capture groups when specifying rule parameters, and they are enumerated in the order in which they are received .
For example, if you set:
Under Artifactory Input, Path Filter = jfrog-(.*).(.*)
Under Bintray Output, Repository = ${path:2}-${path:1}
Then:
jfrog-artifactory.rpm will be deployed to a repository in Bintray called rpm-artifactory
jfrog-artifactory.zip will be deployed to a repository in Bintray called zip-artifactory
jfrog-mission-control.rpm will be deployed to a repository in Bintray called rpm-mission-control
jfrog-mission-control.zip will be deployed to a repository in Bintray called zip-mission-control
You can even mix both named and unnamed capture groups together when specifying rule parameters, however, they are still enumerated in the
order in which they are received.
Expanding the example above, if you set:
Under Artifactory Input, Path Filter = jfrog-(?.*).(.*)
Under Bintray Output, Repository = ${path:2}-${path:type}

"type" is enumerated as the first capture group, and it is back-referenced using its name.
The unnamed capture group is unnamed and second in the enumeration order, so it is back-referenced using its number, 2.

Distributing Artifacts
Once you have your distribution repositories configured, the last step in getting your files to Bintray is to invoke distribution. When you invoke
distribution, Artifactory goes through the rules defined for your distribution repository in order until the artifact you are trying to distribute passes
one of them, and then uploads the file to Bintray in accordance with that rule. Once distributed, the file will also appear in your distribution
repository to indicate that it has been uploaded to Bintray.
There are two ways to do this:
1. Distributing through the UI
2. Distributing via REST API

Distributing Through the UI
To distribute a file through the UI, select it in the Artifact Repository Browser and click Distribute in the right-click menu.

Artifactory will pop up the Distribution dialog where you can set final parameters for distribution.

Distribution Repository

Distribute Artifacts
Asynchronously

The distribution repository through which the artifact should be uploaded to Bintray. The rules defined for this
repository will govern if/how the file is uploaded.
When checked, the file will be uploaded asynchronously. To verify upload to Bintray succeeded, refresh your
distribution repository to see the distributed file.
When unchecked, if upload to Bintray fails, Artifactory will display an error message.
If upload to Bintray fails, please refer to the Artifactory System Log for details.
When checked, files uploaded to Bintray are published to make them available for download by end users

Publish Distributed
Artifacts

When checked, the uploaded file will override another file with the same name if it exists in the upload path.
Override Existing Files

Unticking Distribute Artifacts Asynchronously will produce a UI screen representing the progress and summary of the distribution process:
Once distribution is complete, Artifactory displays the outcome of the process in a Success section and an Error section.
The Success section displays the repository, package and version in which the distributed artifacts will be hosted in Bintray. If the distribution
process created a package or version, this will also be indicated in the Success section. In the example below, both a package and a version
were created.

If an error occurs in moving distributed files to Bintray, the Distribution dialog will also display an Errors section. In the example below, the
success section shows that there was an attempt to upload files to version 4.0.2 in package JSON in repository generic. The Errors section
provides a detailed error message explaining the failure.

Dry Run
A dry run simulates the act of moving your selected files to Bintray without actually distributing them. This is a good way to ensure your
configuration is correct and that there is no impediment to moving your files to Bintray.
Click "Dry Run" to start the simulation. Once completed, Artifactory will display the Success and Error sections as if the files were actually
distributed.
Don't get confused
In a dry run, no files are moved; it's just a simulation

Distributing via REST API
JFrog Artifactory exposes a REST API that lets you automate deploying artifacts to Bintray. For details please refer to Distribute Artifact and Distri
bute Build.

Deploying Snapshots to oss.jfrog.org
Overview
What is OJO
oss.jfrog.org, or OJO for short, is an Artifactory Cloud instance for hosting your maven-compatible build
snapshots, provided free of charge for selected opensource software projects.
All projects in OJO are public (i.e., all the artifacts and builds can be viewed by anyone).
Existing Bintray users are granted deploy permissions to relevant folders in Artifactory, according to the
Maven Group ID of the packages they build.

Target Audience
This page is designed to help OSS contributors who want a free repository to host build snapshots, and
eventually publish release versions to distribution via Bintray.

At a Glance
The process of on-boarding to OJO, working with it to deploy continuous snapshots, and finally, promoting
these snapshots from OJO to Bintray for distribution involves three simple steps:
1. Creating an account on OJO
2. Building and deploying to the OJO Artifactory
3. Promoting a snapshot build to Bintray

Page Contents
Overview
What is OJO
Target Audience
At a Glance
Getting Started with OJO
Working with OJO
Resolving from and Publishing to OJO
Releasing to Bintray
Promoting a Release Build

Getting Started with OJO
To get account on OJO you must first have an account on Bintray.
1. Create a Maven repo on Bintray if it does not exist yet, and create your package inside this repo.
You can give your package any logical name, for example: maven2gradle
2. Ask for inclusion of the package in JCenter, by clicking the "Add to JCenter" button in the package main page.
In the request form, check "Host my snapshot build artifacts on the OSS Artifactory at https://oss.jfrog.org" and enter the desired
Maven group ID for your package.
For example: org.github.jbaruch.maven2gradle

After your request has been approved by the Bintray Team (usually within a few hours), you'll receive a confirmation email on the inclusion of your
package in JCenter and the creation of your new OJO account.
OJO is Artifactory!
OJO is just a regular Artifactory Pro server, so getting familiar with Artifactory is recommended.

Bintray Organizations Support
When requesting an OJO account for a repository belonging to an Bintray organization, the permissions in OJO will be granted to all the
organization members, not only the member who asked for the OJO account.

Working with OJO
Once your OJO account has been created, you (and all the team members in the case of an organization) should be able to login to OJO using

your Bintray username and API key as the password.
You will see that a folder corresponding to the Maven Group ID has been created in OJO in the oss-release-local and the oss-snapshotlocal repositories:

You have deploy permissions to these folders:

Resolving from and Publishing to OJO
There is nothing unusual about working with repositories in OJO. You can configure your build tool to resolve release and snapshot dependencies
from the libs-release and the libs-snapshot OJO virtual repositories, respectively; and to deploy build snapshots to the oss-snapshotlocal repository. As long as the in your pom (for Maven) or the project.group (for Gradle) matches the group ID you requested
during onboarding, the deployment should succeed.
Please consult the Artifactory documentation on how to set up Maven or Gradle for resolution and deployment.
Artifactory Build Info is a must!
In order to release and promote snapshots to Bintray you need to deploy a Build Info BOM to Artifactory. The easiest way to achieve
this automatically it is to use the Build Integration feature of Artifactory or the Gradle Artifactory Plugin; These and other options are
described in the next section.

Releasing to Bintray
Currently, you have two ways to deploy artifacts to Bintray:
1. Promoting a Release Build
This will promote snapshot artifacts to release and then deploy them to Bintray:
a. Use promotion from the Jenkins Artifactory plugin - This allows you to use the Jenkins UI to promote the snapshot artifacts from
a selected job run.
b. Invoking promotion with REST - This allows promotion of a build created with any build server/tool and full programatic
automation of the promotion process.
2. Uploading Release Artifacts
Directly upload deployed release artifact to Bintray. If you have a released version of an artifact or a build, you can deploy them to Bintray
using the regular Bintray integration.

Promoting a Release Build

Promoting a Build from Jenkins

Promotion from Jenkins is performed by invoking a custom "snapshotsToBintray" promotion plugin. Here's what you need to do:
1. Install the Jenkins Artifactory Plugin and configure Artifactory servers and repositories as described in the Jenkins documentation. You
should configure the oss-release-local and oss-snapshot-local as release and snapshot targets, respectively.
2. In your build configuration, add the "Deploy artifacts to Artifactory" post-build action and check "Deploy Maven artifacts", "Capture and
publish build info" and "Allow promotion of non-staged builds":

3. Run your build. Upon successful completion, the build result page will have a link to the "Artifactory Release Promotion" action:

4. In the promotion configuration screen, select "snapshotsToBintray" promotion plugin:

There are two parameters to configure here:
a. Override the release version. By default, the version is calculated by removing the -SNAPSHOT suffix from the snapshot version,
e.g. 1.0-SNAPSHOT will be released to Bintray as version 1.0.
Specifying a value in this field overrides the default version scheme.
b. Append a timestamp to the version. This will add a timestamp string (in Maven's timestamp format: yyyyMMdd.HHmmss) to the
release version. Values of true, y or 1 will cause the timestamp suffix to be appended.
5. Click the "Update" button. Your release artifacts are now uploaded to Bintray.
Promoting a Build Using REST API

If you don't use Jenkins or if you need fully automated promotion, you can issue an HTTP PUT request that will trigger promotion and release to
Bintray. Promotion still operates on a Build Info BOM, previously saved in Artifactory.
Here's what you need to do:

1. Deploy a build to Artifactory in one of the following ways:
a. Using a build server with an Artifactory plugin. Plugins currently exist for Jenkins, Hudson, Bamboo and TeamCity. Please see
the Artifactory Build Integration documentation for further instructions on getting the build info BOM into Artifactory.
b. Using the Gradle Artifactory Plugin.
c. Configure Maven to use Artifactory Listener as described here.
2. Execute the build promotion plugin call. The call accepts the same parameters as the invocation of Jenkins promotion plugin. Here's an
example using CURL:

curl -X POST -u bintrayUser:apiKey
http://oss.jfrog.org/api/plugins/build/promote/snapshotsToBintray/bui
ldName/3

Log Analytics
Overview
The Sumo Logic App for Artifactory automatically creates an account with Sumo Logic and sends it logs for
analysis. Once an account is created through Artifactory, you can connect several instances to that same
account. The Sumo Logic data analytics platform will, in turn, display pre-enabled dashboards which can be
customized as needed. This enables you to access Sumo Logic’s premium operational analytics directly from
Artifactory, letting you index and analyze both structured metrics data and unstructured log data together in
real time. The Sumo Logic App for Artifactory provides you with a customizable dashboard showing a variety
of analytics such as:
Traffic by geo-location
Active IPs
Most active repositories
Top referred files
Requests by status codes
Denied login attempts
and much more.
For more details about the different analytics that the Sumo Logic App for Artifactory can provide, please visit
the Sumo Logic website.
Page Contents
Overview
Configuration
Credentials
Creating a New Account
Using an Existing Account
Connection Established
Traffic Log
Webinar

Configuration
The Log Analytics Configuration can be found in the Admin module under Advanced | Log Analytics.

Get started by setting the Enable checkbox.
Continue by obtaining your Sumo Logic credentials as described in the next section.

Credentials
To access the Sumo Logic Artifactory dashboard, you need a Client ID and Secret.

Creating a New Account
If this is the first time you are using the Sumo Logic App for Artifactory you need to create an account to obtain your login credentials. Select Crea
te New Connection. and click "Access Dashboard".
Artifactory will connect you to the Sumo Logic App for Artifactory. Your user name will automatically be taken as the email from your Artifactory
account.

Select your region, agree to the Service License Agreement and click "Access Dashboard".
Region
For best performance, make sure to select the region that is geographically closest to your Artifactory instance.

Trial account is free for for 30 days
The account created through this integration with Artifactory is a 30-day free trial account. To continue using the integration through this
account beyond 30 days, you need to access your account on Sumo Logic and upgrade it to a paid account.

Using an Existing Account
If you already have a Sumo Logic account, you can use the credentials you already have and enter them in the corresponding fields (if you
obtained them using the same browser you are currently using, they should be filled in automatically). Note that you may use credentials
generated for the current Artifactory instance or from any other instance from which you have connected to Sumo Logic.

Connection Established
Once the connection is established, the Sumo Logic App will start analyzing your log files and populating the dashboard. This process may take
several minutes to complete.
Out-of-the-box, the Sumo Logic App comes pre-configured with several dashboards. You can modify these and add to them as needed.

For details on how to work with and modify your dashboard, please refer to the Sumo Logic documentation.

The Log Analytics screen in Artifactory will reflect the connected status showing the Client ID and Secret needed to log into your account.

Traffic Log
To activate the traffic.log file, add the following parameter to your $ARTIFACTORY_HOME/etc/artifactory.system.properties file :
artifactory.traffic.collectionActive=true
For this change to take effect so you can start collecting site traffic information, you will need to restart your system.

Webinar
For more details on how to set up and use Artifactory's integration with Sumo Logic, please watch the webinar below.

Artifactory Pro
Overview
Artifactory Pro exposes an extensive set of capabilities on top of the core repository management features that are available to you from
Artifactory Open Source:
Pro and Enterprise
Features

A wide range of features to support the needs for enterprise artifact management including security, high availability,
replication, advanced search and more

Package

Full support for all major package formats and dependency managers

Management
Ecosystem
Integration

Integration with the build ecosystem and additional JFrog products

CI Server Integration

Integration with all major CI servers

Comparing ArtifactoryPro , Artifactory OSS and Artifactory Online
To compare the features and services offered by each version of Artifactory please refer to the Artifactory Version Comparison
Matrix to see which version of Artifactory best fits your needs.
For more information please contact support@jfrog.com.

Page Contents
Overview
Package Management
Download
Installation and Upgrade
Activating Artifactory Pro

Read More
Artifactory Comparison Matrix
Pro Features
Package Management
Ecosystem Integration
Build Integration

Download
If you need a license, please visit the JFrog website and either purchase a license or request an evaluation license.
Once you submit the corresponding form, a download link will be provided to you by email.
You may also access the latest version through the Artifactory Pro Download Site.

Installation and Upgrade
Performing a clean installation of Artifactory Pro is identical to installing Artifactory OSS. Please refer to Installing Artifactory.
To upgrade from a previous version of Artifactory Pro or Artifactory OSS, please refer to Upgrading Artifactory.
Data is preserved when upgrading from Artifactory OSS to Artifactory Pro
For a standalone installation, to upgrade an instance of Artifactory OSS to Artifactory Pro of the same version you only need to
replace the artifactory.war file and enter a valid license key. All data stored in Artifactory is preserved in the process.
Once you have entered a valid Artirfactory Pro license key, all Artifactory Pro features will be available with the same settings and
content you had on the Artifactory OSS version from which you upgraded.

Activating Artifactory Pro
Whether you have requested an evaluation of Artifactory Pro, or have purchased a license, your license key is provided in the same email that
contains the download link sent to you.
Your Artifactory administrator should enter the license key into the corresponding field in the Admin module under Configuration | Register
License.

Administrator
You must be an Artifactory administrator in order to access the License Key field.

Using encrypted passwords
If you are using encrypted passwords with an IBM JDK/JRE, you may encounter encryption restrictions. For details please refer to Usin
g Your Secure Password.

Artifactory Comparison Matrix
Choose the Artifactory Edition that Fits You Best
OSS

Pro

SaaS

Enterprise

SaaS
(Dedicated
Server)
Basic Artifact Management:
Details...
Proxy and cache remote repository artifacts
Bulk artifact deployment (from archive)
Include/exclude patterns for stored artifacts
Deploy Artifacts via the UI or via REST/HTTP
Move/copy/delete artifacts through the UI
Checksum-based Storage with Deduplication

On Demand Jar Signing and Web Start Application
Hosting
Custom repository layout for non-Maven module
management
Repository Replication
Multi-push Replication
Universal support for all major package formats:
Maven
Other package formats...
Bower
Chef Cookbooks
CocoaPods
Conan
Debian
Docker
Git LFS
NPM
NuGet
Opkg
P2
PHP Composer
Puppet
PyPI
RPM
RubyGems
SBT
Vagrant
VCS
Integration with all leading CI-servers
Promotion, demotion and cleanup of build artifacts
Managing build artifacts for reproducible builds
Powerful REST API for Release Automation
Extend Artifactory with Groovy-based User Plugins
Basic Security
Details...
LDAP Authentication
Role-based authorization with teams and
permissions

LDAP Groups
Multiple additional options for authentication
Details...
Active Directory, Atlassian Crowd and JIRA, OAu
th (multiple providers)
Automatic 3rd Party License Violation Detection
per Build
Powerful SSO integration for NTLM, Kerberos, Etc.
Search by Name, Archive, Property or Checksum
Values
Artifactory Query Language (AQL)
Annotate Artifacts with Searchable Properties
Aggregate and Run Bulk Operations on Search
Results

Advanced Storage Solutions
Details...
S3 Object Storage

(Managed by JFrog)

Google Cloud Storage
Microsoft Azure Cloud Storage
Filestore Sharding

High Availability
Details...
Five-nines Availability
Redundant Cluster of Servers
Unlimited Server Scalability
Near-zero Maintenance Downtime
Integration with Other JFrog Products

JFrog Bintray and JFrog CLI
JFrog Xray
JFrog Mission Control

(view only)

Disaster Recovery
SaaS Features
Details...
SaaS-based Maintenance-free Hosted Repository
Always up-to-date Artifactory Version
Setup Free Automated Backups
Maintenance and Administration
Details...
Incremental and Historical Backup Services
Focused Email Notifications for Artifact Changes
Free Upgrades
SLA-based Support
(Pro Plus and Pro
X)

Pro Features
Overview
Artifactory Pro exposes a full set of capabilities that takes you beyond basic repository management to
include advanced features for security, build integration, replication, advanced search, automation through a
REST API and more.

Artifactory
Query
Language

A simple way to formulate complex queries that can find artifacts based on any number
of search criteria.

Black Duck
Code Center
integration

Automate security and license governance of open source components and software.

Filtered
Resources

Provision common settings and configuration to clients by turning any textual artifact
into a dynamic template based on request parameters, current user identity and artifact
properties.

GPG Signing

Manage signing key pairs so you can sign packages in different formats for
authentication.

JFrog CLI

A simple interface that automates access to Artifactory through a compact and smart
client.

LDAP Groups

Synchronize your LDAP groups with Artifactory and leverage your existing
organizational structure to manage group-based permissions.

License Control

Manage and control your organization's licensing policies for third-party dependencies
used by your software.

Properties

Annotate your artifacts and folders with fully-searchable properties.

Repository
Layouts

Define the layout by which software modules areindentifiedin your repository for
automatic cleanup of old versions and cross-repository layout conversion.

Repository
Replication

Actively synchronize your repository content and metadata with remote Artifactory
repositories using pull or push replication.

REST API

Automate your repository management and release life-cycle with a powerful REST
API.

Smart Search

Save search results in a stash browser for easy access and perform bulk operations on
the result set.

SSO

Integrate with SSO infrastructures such as Apache HTTPd, Atlassian Crowd and SAML.

User Plugins

Extend Artifactory by plugging in your own custom Groovy scripts.

Watches

Watch selected artifacts, folders, or repositories for any event , and receive email
notifications on changes that are interesting to you.

Webstart and
JAR Signing

Manage signing keys and sign JAR files for use with Java Web Start

Enterprise Features
When activated with an enterprise license, JFrog Artifactory Pro offers and additional set of features to meet
the high-end needs for repository management in larger enterprises.
Filestore
Sharding

Implement a sharded filestore for a flexible filestore that offers unmatched stability, unlimited
scalability and optimized performance.

Google
Cloud
Storage

Let your Artifactory filestore reside with GCS for unlimited scalability, security and disaster
recovery capabilities.

High
Availability

Deploy Artifactory in a high availability configuration to maximize uptime (up to five-nines
availability), manage heavy loads and minimize maintenance downtime.

Multi-push
Replication

Replicate a repository to multiple remote sites simultaneously.

S3 Object
Storage

Manage your filestore on the cloud with any S3 compliant provider such as Amazon S3.

Page Contents
Overview
Enterprise Features

Read more
Artifactory Query Language
Atlassian Crowd and JIRA Integration
Azure Blob Storage
Black Duck Code Center Integration
Filestore Sharding
Filtered Resources
Google Cloud Storage
GPG Signing
LDAP Groups
License Control
OAuth Integration
Properties
Repository Layouts
Repository Replication
S3 Object Storage
SAML SSO Integration
Single Sign-on
Smart Searches
SSH Integration
User Plugins
Watches
WebStart and Jar Signing

Artifactory Query Language
Overview
Artifactory Query Language (AQL) is specially designed to let you uncover any data related to the
artifacts and builds stored within Artifactory. Its syntax offers a simple way to formulate complex
queries that specify any number of search criteria, filters, sorting options, and output parameters. AQL
is exposed as a RESTful API which uses data streaming to provide output data resulting in extremely
fast response times and low memory consumption. Currently, AQL can only extract data that resides
in your instance of Artifactory, so it runs on local repositories, remote repository caches and virtu
al repositories.
Here are a few simple examples:

// Return all artifacts of the "artifactory"
build.
items.find({"@build.name":{"$eq":"artifactory"}})
// Return all builds that have a dependency with
a license that is not Apache.
builds.find({"module.dependency.item.@license":{"
$nmatch":"Apache-*"}})
// Return all archives containing a file called
"org/artifactory/Main.class".
items.find({"archive.entry.name":{"$eq":"Main.cla
ss"} ,
"archive.entry.path":{"$eq":"org/artifactory"}})

Here is a slightly more complex example.

// Return all entries of any archive named
"Artifactory.jar" from any build named
"Artifactory" with
// build number 521.
archive.entries.find( {
"archive.item.name":{"$eq":"Artifactory.jar"},
"archive.item.artifact.module.build.name":{"$eq":
"Artifactory"},
"archive.item.artifact.module.build.number":{"$eq
":"521"}
})

Page Contents
Overview
Architecture
Supported Domains
Usage
Syntax
Using Fields
Execution
Entities and Fields
Constructing Search Criteria
Field Criteria
Properties Criteria
Compounding Criteria
Matching Criteria on a Single Property ($msp)
Comparison Operators
Using Wildcards
Using Wildcards with $match and $nmatch
"Catch all" Notation on Properties
Examples
Date and Time Format
Relative Time Operators
Specifying Output Fields
Displaying All Fields
Displaying Specific Fields
Users Without Admin Privileges
Filtering Properties by Key
Sorting
Display Limits and Pagination
Working With Virtual Repositories
Filtering on a Virtual Repository
Output Fields

Here is an another example that shows the full power of AQL to mine information from your repositories in a way that no other tool can match.

// Compare the contents of artifacts in 2 "maven+example" builds
items.find(
{
"name":{"$match":"multi2*.jar"},
"$or":[
{
"$and":[
{"artifact.module.build.name":{"$eq":"maven+example"}},
{"artifact.module.build.number":{"$eq":"317"}}
]
},
{
"$and":[
{"artifact.module.build.name":{"$eq":"maven+example"}},
{"artifact.module.build.number":{"$eq":"318"}}
]
}
]
}).include("archive.entry")

Click to view the output of this query...
{
"results" : [ {
"repo" : "ext-snapshot-local",
"path" : "org/jfrog/test/multi2/3.0.0-SNAPSHOT",
"name" : "multi2-3.0.0-20151012.205507-1.jar",
"type" : "file",
"size" : 1015,
"created" : "2015-10-12T22:55:23.022+02:00",
"created_by" : "admin",
"modified" : "2015-10-12T22:55:23.013+02:00",
"modified_by" : "admin",
"updated" : "2015-10-12T22:55:23.013+02:00",
"archives" : [ {
"entries" : [ {
"entry.name" : "App.class",
"entry.path" : "artifactory/test"
}, {
"entry.name" : "MANIFEST.MF",
"entry.path" : "META-INF"
}]
}]
},{
"repo" : "ext-snapshot-local",
"path" : "org/jfrog/test/multi2/3.0.0-SNAPSHOT",
"name" : "multi2-3.0.0-20151013.074226-2.jar",
"type" : "file",
"size" : 1015,
"created" : "2015-10-13T09:42:39.389+02:00",
"created_by" : "admin",
"modified" : "2015-10-13T09:42:39.383+02:00",
"modified_by" : "admin",
"updated" : "2015-10-13T09:42:39.383+02:00",
"archives" : [ {
"entries" : [ {
"entry.name" : "App.class",
"entry.path" : "artifactory/test"
}, {
"entry.name" : "MANIFEST.MF",
"entry.path" : "META-INF"
}]

}]
} ],
"range" : {
"start_pos" : 0,
"end_pos" : 2,
"total" : 2
}
}

Architecture
AQL is constructed as a set of interconnected domains as displayed in the diagram below. You may run queries only on one domain at a time,
and this is referred to as the Primary domain of the query.
Currently, the following are supported as primary domains: Item, Build, Entry, and Promotion. i.e., your queries may be of the form: items.find(.
..), builds.find(...), archive.entries.find(...), or build.promotions.find(...).
You may use fields from other domains as part of your search criteria or to specify fields to display in the output, but in that case, you need to
follow the conventions described in Using Fields.

Supported Domains
AQL was introduced in Artifactory V3.5.0 with support for Item as a primary domain with its attached Property, as well as Statistic as a
secondary domain. Later versions of Artifactory introduced additional domains that can be included in queries. The following table summarizes
from which version each domain is accessible.
3.5.0

Item

Item.Property

Statistic

4.2.0

4.7.0

Archive

Archive.Entry

Artifact

Dependency

Module

Module.Property

Build

Build.Property

Promotion

Usage
Syntax

.find().include().sort()
.limit().offset()

where:
The query corresponding to the primary domain. Must be one of items, builds or entries.
domain_query

The search criteria in valid JSON format
criteria

fields

(Optional) There is a default set of fields for query output. This parameter lets you specify a different set of fields that
should be included in the output

order_and_fields

(Optional) The fields on which the output should be sorted, and the sort order. A default set of fields and sort order is
defined for each domain.

num_records

(Optional) The maximum number of records that should be extracted. If omitted, all records answering the query criteria will
be extracted.
(Optional) The offset from the first record from which to display results (i.e. how many results should be skipped for display)

offset

Limitation
Sort, limit and offset elements only work in the following cases:

Your query does not have an include element
If you do have an include element, you only specify fields from the primary domain in it.
For example, in the following query, sort, limit and offset will not work because the primary domain is item, but the include element s
pecifies that fields from the the artifact, module and build domains should be displayed:

items.find().include("artifact","artifact.module","artifact.module.b
uild")

Using Fields

Any fields from your primary domain can be used directly anywhere in your query. If you use fields from other domains, they must be specified
using a complete relation path from the primary domain.
For example, to find all items in a repository called "myrepo" you would use:

items.find({"repo": "myrepo"})

But to find all items created by modules named "mymodule" you would use:

items.find({"artifact.module.name" : "mymodule"})

And since you may also issue a query from the build domain, to find all builds that generated an item called "artifactory.war", you could also use:

builds.find({"module.artifact.item.name": "artifactory.war"})

Execution
To execute an AQL query, use the Artifactory Query Language REST API.

Entities and Fields
You may issue a find request according to the syntax above, and configure your request to display fields from any of the domains.
Domain

Field Name

Type

Description

item

repo

String

The name of the repository in which this item is stored

path

String

The full path associated with this item

name

String

The name of the item

created

Date

When the item was created

modified

Date

File system timestamp indicating when the item was last modified

updated

Date

When the item was last uploaded to a repository.

created_by

String

The name of the item owner

modified_by

String

The name of the last user that modified the item

type

Enum

The item type (file/folder/any).
If type is not specified in the query, the default type searched for is file

depth

int

The depth of the item in the path from the root folder

original_md5

String

The item's md5 hash code when it was originally uploaded

actual_md5

String

The item's current md5 hash code

original_sha1

String

The item's sha1 hash code when it was originally uploaded

actual_sha1

String

The item's current sha1 hash code

sha256

String

The item's sha256 hash code

size

long

The item's size on disk

virtual_repos

String

The virtual repositories which contain the repository in which this item is stored.

archive
The archive domain currently contains no fields

entry

promotion

build

property

stat

name

String

The entry's name

path

String

The path of the entry within the repository

created

Date

When the build was promoted

created_by

String

The Artifactory user that promoted the build

status

String

The status of the promotion

repo

String

The name of the repository to which the build was promoted

comment

String

A free text comment about the promotion

user

String

The CI server user that promoted the build

url

String

The URL of the build

name

String

The build name

number

String

The build number

created

Date

File system timestamp indicating when the item was last modified

created_by

String

The name of the user who created the build

modified

Date

File system timestamp indicating when the build was last modified

modified_by

String

The name of the last user that modified the build

key

String

The property key

value

String

The property value

downloaded

date

The last time an item was downloaded

downloads

int

The total number of downloads for an item

downloaded_by

String

The name of the last user to download this item

remote_downloads

int

The total number of downloads for an item from a smart remote repository proxying the local repository in
which the item resides

remote_downloaded

date

The last time an item was downloaded from a smart remote repository proxying the local repository in which
the item resides

remote_downloaded_by

String

The name of the last user to download this item from a smart remote repository proxying the local repository
in which the item resides

remote_origin

String

The address of the remote Artifactory instance along a smart remote proxy chain from which the download
request originated.

remote_path

String

The full path along a smart remote proxy chain through which the download request went from the origin
instance to the current instance.

name

String

The name of the artifact

type

String

The type of the artifact

sha1

String

The SHA1 hash code of the artifact

md5

String

The MD5 hash code of the artifact

module

name

String

The name of the module

dependency

name

String

The name of the dependency

scope

String

The scope of the dependency

type

String

The type of the dependency

sha1

String

The SHA1 hash code of the dependency

md5

String

The MD5 hash code of the dependency

artifact

Constructing Search Criteria
The criteria element must be a valid JSON format statement composed of the criteria that specify the items that should be returned. It is
essentially a compound boolean statement, and only elements for which the statement evaluates to true are returned by the query.
Each criterion is essentially a comparison statement that is applied either to a field or a property. Please see the full list of Comparison Operators.
While each criterion may be expressed in complete general format, AQL defines shortened forms for readability as described below.

Field Criteria
The general way to specify a criterion on a field is as follows:

{"" : {"" : ""}}

If the query applied is to a different domain, then field names must be pre-pended by a relation path to the primary domain.
For example:

//Find items whose "name" field matches the expression "*test.*"
items.find({"name": {"$match" : "*test.*"}})
//Find items that have been downloaded over 5 times.
//We need to include the "stat" specifier in "stat.downloads" since
downloads is a field of the stat domain and not of the item domain.
items.find({"stat.downloads":{"$gt":"5"}})
//Find items that have never been downloaded. Note that when specifying
zero downloads we use "null" instead of 0.
//We need to include the "stat" specifier in "stat.downloads" since
downloads is a field of the stat domain and not of the item domain.
items.find({"stat.downloads":{"$eq":null}})
//Find builds that use a dependency that is a snapshot
builds.find({"module.dependency.item.name":{"$match":"*SNAPSHOT*"}})

Fields with "Zero" value in the stat domain
Note that when searching for items that have a "zero" value in the stat domain, you should search for null, not 0. For example, as
shown above, when searching for items with zero downloads you specify "null" instead of 0.

Short notation for Field criteria
AQL supports a short notation for search criteria on fields.
An "equals" ("$eq") criterion on a field may be specified as follows:
{"" : ""}
Find items whose "name" field equals "ant-1.9.4.jar"
Example

items.find({"name":{"$eq":"ant-1.9.4.jar"}})
Regular notation

items.find({"name":"ant-1.9.4.jar"})
Short notation

Properties Criteria
Artifactory lets you attach, and search on properties in three domains: items, modules and builds.
The general way to specify a criterion on a property is as follows:

{"@":{"operator":""}}

Accessing the right properties
If you are specifying properties from the primary domain of your query, you may simply enter the property key and value as described
above. If you are specifying properties from one of the other domains, you need to specify the full relational path to the property.
In the example below, the primary domain is the build domain, but we want to find builds based a property in the item domain, so we
must specify the full path to the property:
builds.find({"module.artifact.item.@qa_approved" : {"$ne" : "true"}})

Here are some examples:

//Find items that have been approved by QA"
items.find({"@qa_approved" : {"$eq" : "true"}})
//Find builds that were run on a linux machine"
builds.find({"@os" : {"$match" : "linux*"}})
//Find items that were created in a build that was run on a linux machine.
items.find({"artifact.module.build.@os" : {"$match" : "linux*"}})

Short notation for properties criteria
AQL supports a short notation for search criteria on properties.
An "equals" ("$eq") criterion on a property may be specified as follows:
{"@" : ""}

Find items with associated properties named "license" with a value that equals "GPL"
Example

items.find({"@artifactory.licenses" : {"$eq" : "GPL"}})
Regular notation

items.find({"@artifactory.licenses" : "GPL"})
Short notation

Compounding Criteria
Search criteria on both fields and properties may be nested and compounded into logical expressions using "$and" or "$or" operators. If no
operator is specified, the default is $and

={<"$and"|"$or">:[{},{}]

Criteria may be nested to any degree
Note that since search criteria can be nested to any degree, you may construct logical search criteria with any degree of complexity
required.
Here are some examples:

//This example shows both an implicit "$and" operator (since this is the
default, you don't have to expressly specify it, but rather separate the
criteria by a comma), and an explicit "$or" operator.
//Find all items that are files and are in either the jcenter or my-local
repositories.
items.find({"type" : "file","$or":[{"repo" : "jcenter", "repo" : "my-local"
}]})
//Find all the items that are either in a repository called "debian" and
whose name ends with ".deb" or are in a repository called "yum" and whose
name ends with ".rpm".
items.find(
{
"$or":
[
{
"$and":
[
{"artifact.module.build.name" : "my_debian_build"} ,
{"name" : {"$match" : "*.deb"}}
]
},
{
"$and":
[
{"artifact.module.build.name" : "my_yum_build"} ,
{"name" : {"$match" : "*.rpm"}}
]
}
]
}
)
//Find all items in a repository called "my_local" that have a property
with a key called "license" and value that is any variant of "LGPL".
items.find({"repo" : "my_local"},{"@artifactory.licenses" : {"$match" :
"*LGPL*"}})

Matching Criteria on a Single Property ($msp)

A search that specifies several criteria on properties may sometimes yield unexpected results.
This is because items are frequently annotated with several properties, and as long as any criterion is true for any property, the item will be
returned in a regular find.
But sometimes, we need to find items in which a single specific property answers several criteria. For this purpose we use the $msp (match on
single property) operator.
The fundamental difference between a regular find and using the $msp operator is:
find will return an item if ANY of its properties answer ALL of the criteria in the search term.
$msp will only return an item if at least ONE of its properties answers ALL of the criteria in the $msp term.
Here is an example.

Consider two items A and B.
A has a license property with value AGPL-V3
B has two license properties . One is LGPL-2.1, and the other LGPL-2.2

Now let's assume we want to find items that use any variety of GPL license as long as it's NOT LGPL-2.1.
In our example we would expect to get both Items A and B returned since A has AGPL-V3 and B has LGPL-2.2.
As a first thought, we might write our query as follows:

items.find({
"@license":{"$match": "*GPL*"},
"@license":{"$nmatch": "LGPL-2.1*"}
})

But this query only returns item A.
Item A is returned because it clearly answers both criteria: "@license":{"$match": "*GPL*"} and "@license":{"$nmatch": "LGPL-2.1*"}
Item B is not returned because it has the property license=LGPL-2.1 which does not meet the criterion of "@license":{"$nmatch": "LGPL-2.1*"}.
If we use the $msp operator as follows:

"items.find({
"$msp": [
"@license":{"$match": "*GPL*"},
"@license":{"$nmatch": "LGPL-2.1*"}
]}).

Then both Item A and Item B are returned.
Item A is returned because it has the @license property AGPL-V3 which meets both the {"@license":{"$match": "*GPL*"}} criterion and
the "@license":{"$nmatch": "LGPL-2.1*"} criterion.
Item B is returned because it has the @license property LGPL-2.2 which also meets both the{"@license":{"$match": "*GPL*"}} criterion and
the "@license":{"$nmatch": "LGPL-2.1*"} criterion.
Note that the $msp operator works equally well on all domains that have properties: item, module and build.

Comparison Operators
The following table lists the full set of comparison operators allowed:
Operator

Types

Meaning

$ne

string, date, int, long

Not equal to

$eq

string, date, int, long

Equals

$gt

string, date, int, long

Greater than

$gte

string, date, int, long

Greater than or equal to

$lt

string, date, int, long

Less than

$lte

string, date, int, long

Less than or equal to

$match

string

Matches

$nmatch

string

Does not match

For time-based operations, please also refer to Relative Time Operators.

Using Wildcards
To enable search using non-specific criteria, AQL supports wildcards in common search functions.
Using Wildcards with $match and $nmatch

When using the "$match" and "$nmatch" operators, the "*" wildcard replaces any string and the "?" wildcard replaces a single character.
"Catch all" Notation on Properties

In addition to supporting "$match" and "$nmatch", AQL supports a notation that uses wildcards to match any key or any value on properties.
If you specify "@*" as the property key, then it means a match on any key.
If you specify "*" as the property value, then it means a match on any value
Find items that have any property with a value of "GPL"
Example

Regular
notation

items.find({"$and" : [{"property.key" : {"$eq" : "*"}}, {"property.value" : {"$eq" :
"GPL"}}]})

items.find({"@*":"GPL"})
Short notation

Find any items annotated with any property whose key is "license" (i.e. find any items with a "license" property)
Example

items.find({"$and" : [{"property.key" : {"$eq" : "license"}}, {"property.value" : {"$eq" : "*"}}]})
Regular notation

items.find({"@artifactory.licenses":"*"})
Short notation

Be careful not to misuse widlcards
Wildcard characters ("*" and "?") used in queries that do not conform to the above rules are interpreted as literals.

Examples

To avoid confusion, here are some examples that use the "*" and "?" characters explaining why they are interpreted as wildcards or literals.
Query

Wildcard
or
Literal

Explanation

What the query
returns

items.find({"name":{"$match":"ant-1.9.4.*"}})

Wildcard

Wildcards on fields are allowed with the $match opera
tor.

All items whose name
matches the expression
"ant-1.9.4.*"

items.find({"name":{"$eq":"ant-1.9.4.*"}})

Literal

Wildcards on fields are only allowed with the $match a
nd $nmatch operators.

Only find items whose
name is literally
"ant-1.9.4.*"

items.find({"@artifactory.licenses":"*"})

Wildcard

For properties, this short notation is allowed and
denotes any value

All items with a property
whose key is "license"

items.find({"@artifactory.licenses":"*GPL"})

Literal

This is the short notation replacing the $eq operator for
properties, but it does not use the "catch all" notation
for properties.

All items with a license
whose value is literally
"*GPL"

items.find({"@artifactory.licenses":{"$match
":"*GPL*"}})

Wildcard

Wildcards on properties are allowed with the $match o
perator.

All items with a license
matches the expression
"*GPL*"

Date and Time Format
AQL supports Date and Time formats according to a W3C profile of the ISO 8601 Standard for Date and Time Formats.
The complete date and time notation is specified as:
YYYY-MM-DDThh:mm:ss.sTZD (e.g., 2012-07-16T19:20:30.45+01:00)
Date/Time specified in partial precision is also supported: (i.e. specify just the year, or year and month, year, month and day etc.)
For example, the following query will return all items that were modified after July 16, 2012 at 30.45 seconds after 7:20pm at GMT+1 time zone:

//Find all the items that have been modified after
2012-07-16T19:20:30.45+01:00
items.find({"modified" : {"$gt" : "2012-07-16T19:20:30.45+01:00"}})
//Find all the builds that have were created after 2012-07-01
builds.find({"created" : {"$gt" : "2012-07-01"}})

For full details, please refer to the W3C documentation.

Relative Time Operators
AQL supports specifying time intervals for queries using relative time. In other words, the time interval for the query will always be relative to the
time that the query is run, so you don't have to change or formulate the time period, in some other way, each time the query is run. For example,
you may want to run a query over the last day, or for the time period up to two weeks ago.
Relative time is specified using the following two operators:
The query is run over complete period up to specified time.
$before

The query is run over period from the specified time until the query is run
$last

Time periods are specified with a number and one of the following suffixes:
"mills", "ms"
milliseconds

"seconds", "s"
seconds

"minutes"
minutes

"days", "d"
days

"weeks", "w"
weeks

"months", "mo"
months

"years", "y"
years

For example, to specify five days, you could use "5d". To specify two weeks, you could use "2w".
Below are some examples using relative time operators:

//Find all the items that were modified during the last three days
items.find({"modified" : {"$last" : "3d"}})
//Find all the builds that were created up to two weeks ago (i.e. no later
than two weeks ago)
builds.find({"created" : {"$before" : "2w"}})

Specifying Output Fields
Each query displays a default set of fields in the result set, however you have complete control this and may specify which fields to display using
an optional include element in your query.
You can even specify to display fields from other entities related to your result set.

Displaying All Fields
Use: .include("*")
For example:

//Find all items, and display all the item fields
items.find().include("*")

Displaying Specific Fields
Each query displays a default set of fields in the output. Using the .include element you can override this default setting and specify any
particular set of fields you want to receive in the output.
Use: .include("", ""...)
For example:

//Find all items, only display the "name" and "repo" fields
items.find().include("name", "repo")

You can also display specific fields from other entities associated with those returned by the query.
If you specify any field from the item domain, then this will override the default output setting, and only the item fields you expressly specified will
be displayed.
If you only specify fields from the property or stat domains, then the output will display the default fields from the item domain, and in addition,
the other fields you expressly specified from the property or stat domains.
For example:

//Find all items, and display the "name" and "repo" fields as well as the
number of "downloads" from the corresponding "stat" entity
items.find().include("name", "repo", "stat.downloads")
//Find all items, and display the default item fields fields as well as the
stat fields
items.find().include("stat")
//Find all items, and display the default item fields as well as the stat
and the property fields
items.find().include("stat", "property")
//Find all items, and display the "name" and "repo" fields as well as the
stat fields
items.find().include("name", "repo", "stat")
//Find all builds that generated items with an Apache license, and display
the build fields as well as the item "name" fields. Click below to view the
output of this query
builds.find({
"module.artifact.item.@license":{"$match":"Apache*"}
}
).include("module.artifact.item.name")

Click to view the output of the last query
Note that the output displays the default fields of the "build" domain, and the "name" field from the item domain. Fields from the module and
artifact domains are not displayed since they were not specified in the include element.
{
"results" : [ {
"build.created" : "2015-09-06T15:49:01.156+03:00",
"build.created_by" : "admin",
"build.name" : "maven+example",
"build.number" : "313",
"build.url" : "http://localhost:9595/jenkins/job/maven+example/313/",
"modules" : [ {
"artifacts" : [ {
"items" : [ {
"name" : "multi-3.0.0-20150906.124843-1.pom"
}]
}]
}]
},{
"build.created" : "2015-09-06T15:54:40.726+03:00",
"build.created_by" : "admin",
"build.name" : "maven+example",
"build.number" : "314",
"build.url" : "http://localhost:9595/jenkins/job/maven+example/314/",
"modules" : [ {
"artifacts" : [ {
"items" : [ {
"name" : "multi-3.0.0-20150906.124843-1.pom"
}]
}]
}]
} ],
"range" : {
"start_pos" : 0,

"end_pos" : 2,
"total" : 2
}
}

Users Without Admin Privileges
To ensure that non-privileged users do not gain access to information without the right permissions, users without admin privileges have the
following restrictions:
1. The primary domain in the query may only be item.
2. The following three fields must be included in the include directive: name, repo, and path.
Note, however, that once these restrictions are met, you may include any other accessible field from any domain in the include directive.

Filtering Properties by Key

As described above, the primary use of the .include element is to specify output fields to display in the result set.
This notion is applied in a similar way in regard to properties. Each item may be annotated with several (even many) properties. In many cases
you may only be interested in a specific subset of the properties, and only want to display those.
So the .include element can be used to filter out unwanted properties from the result, and only display (i.e. "include") those you are interested in.
For example, to display all the properties annotating an item found :

//Find all items, and display the "name" and "repo" fields, as well as all
properties associated with each item
items.find().include("name", "repo", "property.*")

However, if you are only interested in a specific property (e.g. you just want to know the version of each item returned), you can filter out all other
properties and only include the property with the key you are interested in:

//Find all items, and display the "name" and "repo" fields, as well as the
key and value of the "version" property of each item
items.find().include("name", "repo", "@version")

Sorting
AQL implements a default sort order, however, you can override the default and specify any other sort order using fields in your output by adding
the .sort element to the end of your query as follows:
.sort({"<$asc | $desc>" : ["", "",... ]})
You can only specify sorting on fields that are displayed in the output (whether they are those displayed by default or due to a .includ
e element).
Here are some examples:

// Find all the jars in artifactory and sort them by repo and name
items.find({"name" : {"$match":"*.jar"}).sort({"$asc" : ["repo","name"]})
// Find all the jars in artifactory and their properties, then sort them
by repo and name
items.find({"name" : {"$match":"*.jar"}}).include("@").sort({"$asc" :
["repo","name"]})

Display Limits and Pagination
Limitation
Note the important limitation on sort, limit and offset described above.
Using the .limit elements, you can limit the number of records that will be displayed by your query.

// Find all the jars in artifactory and sort them by repo and name, but
only display the first 100 results
items.find({"name" : {"$match":"*.jar"}).sort({"$asc" :
["repo","name"]}).limit(100)

You can also implement pagination when you want to focus on a subset of your results using the .offset element.

//Run the same example, but this time, display up to 50 items but skipping
the first 100
items.find({"name" : {"$match":"*.jar"}).sort({"$asc" :
["repo","name"]}).offset(100).limit(50)

Working With Virtual Repositories
From version 4.8.1, AQL supports virtual repositories. Since virtual repositories only contain items indirectly through the local repositories they
include, several conventions have been laid down as described in the following sections.

Filtering on a Virtual Repository
You may limit queries to search in a specified virtual repository. In practice this means that the query will be applied to local repositories and
remote repository caches included in the specified virtual repository.
For example, find all the items within any repository contained in a virtual repository called "my-virtual":

items.find({"repo" : "my-virtual"})

Output Fields
The item domain has a virtual_repos field which includes the virtual repositories in which a found item is contained. In general, to display this
field, you need to expressly specify it in your query as an output field. However, if your query specifies a virtual repository as its search target, the
virtual_repos field is implicitly included in the search results as an output field.
An item must be accessible in order to be found

A search query will only find an item in a virtual repository if it is accessible by that virtual repository. For example, the local repository
that contains an item may specify and include or exclude pattern which prevents access to the item by the encapsulating virtual
repository. In this case the search query will not find the item.

Atlassian Crowd and JIRA Integration
Overview
The integration between Artifactory and Crowd/JIRA allows you to delegate authentication requests to
Atlassian Crowd/JIRA, use authenticated Crowd/JIRA users and have Artifactory participate in a transparent
SSO environment managed by Crowd/JIRA.
Page Contents
Overview
Usage
Crowd Groups

Usage
Crowd integration can then be configured in the Admin module under Security | Crowd/JIRA.

Field Name

Description
Set this checkbox to enable security integration with Atlassian Crowd or JIRA.

Enable Crowd /
JIRA Users
Management
Integration

Select which User Management Server you are using.
User Management
Server

The full URL of the server to use.
Server URL

The application name configured for Artifactory in Crowd/JIRA.
Application Name

The application password configured for Artifactory in Crowd/JIRA.
Crowd Application
Password

The time window, in minutes, in which the session does not need to be revalidated.
Session Validation
Interval

If this checkbox is set and a default proxy definition exists, it is used to pass through to the Crowd/JIRA Server.
Use Default Proxy
Configuration

Auto Create
Artifactory Users

When automatic user creation is off, authenticated users will not be automatically created inside Artifactory. Instead, for
every request from a Crowd/JIRA user, the user is temporarily associated with default groups (if such groups are
defined), and the permissions for these groups applies.
Without automatic user creation, you will need to manually create the user inside Artifactory in order to manage user
permissions that are not attached to his default groups.
Filter the search to see only groups of the specified username. If unchecked, all Crowd groups are shown.

Filter by Group
Name

To enable Crowd/JIRA integration:
1.
2.
3.
4.
5.
6.
7.
8.

Select which User Management Server you are using. If you select JIRA, SSO will be disabled since it's not supported by JIRA.
Define Artifactory as a Custom Application Client inside Crowd.
Complete the Crowd server URL, and the application credentials defined in Step 1.
The session validation interval defines the principal token validity time in minutes. If left at the default of 0, the token expires only when
the session expires.
If you are using JIRA User Server provide it's URL in the "Crowd Server URL" and check the "Use JIRA User Server". This will disable
SSO, which is not supported by JIRA.
If you have a proxy server between the Artifactory server and the Crowd server, you may set the Use Default Proxy
Configuration check-box.
You may instruct Artifactory to treat externally authenticated users as temporary users, so that Artifactory does not automatically create
them in its security store. In this case, permissions for such users are based on the permissions given to auto-join groups.
Test the configured connection and save it.
System properties
Crowd configuration properties may be added to the run time system properties or to the $ARTIFACTORY_HOME/etc/artifactory.
system.properties file.
NOTE that setting a configuration through properties overrides configurations set through the user interface.

Crowd Groups
To use Crowd/JIRA groups:
1. Set up a Crowd server for authentication as detailed above.
2. Verify your setup by clicking the Refresh button on the Synchronize Crowd Groups sub-panel. A list of available Crowd groups,
according to your settings is displayed.
3. The groups table allows you to select which groups to import into Artifactory and displays the sync-state for each group. A group can
either be completely new or may already exist in Artifactory.
4. Select and import the groups that you wish to import to Artifactory. Once a group is imported (synced) a new external Crowd group is
created in Artifactory with the name of the group.

You can Manage Permissions on the synced Crowd groups in the same way you manage them for regular Artifactory groups.
Users association to these groups is external and controlled strictly by Crowd.
Ensure the Crowd group settings is enabled in order for your settings to become effective.

Azure Blob Storage
Overview
From version 5.4, Artifactory supports managing your Artifactory filestore on the cloud with Azure
Blob Storage providing you with:
1. Massive scalability
On the cloud, your Artifactory filestore is massively scalable. You may freely continue to
upload files without having to install or maintain any file storage devices. You can even
upload files larger than 5 GB using multi-part upload with the blob size limit currently at
4.75 TB. Currently, there is also a 500 TB limit on an Azure Blob Storage account.
2. Security
An Azure Blob Storage account offers a variety of security capabilities such as role-based
access control, Azure Active Directory, in-transit security, Storage Service encryption and
more. For full details on the security capabilities provided by Azure Blob Storage, please
refer to Azure Storage Security Overview.
3. Disaster recovery
Since your files are replicated and stored with redundancy, using Azure Blob Storage
offers the capability for disaster recovery.
Support for Azure Blob Storage is included with JFrog Enterprise Edition.
In order to use Azure Blob Storage with Artifactory, make sure you first install or upgrade to Artifact
ory V5.4.0 or later.

Backup your system. Your current filestore will be deleted.
Setting up Artifactory to use Azure Blob Storage will delete all files in your current
filestore.

Page Contents
Overview
Setting up
Artifactory to
Use Azure
Blob Storage
Setting
Your
Licens
e
Config
uring
Artifact
ory to
Use
Azure
Blob
Storag
e
Migrati
ng
Your
Filesto
re

If you already have a running installation of Artifactory, then before you setup Artifactory
to use Azure Blob Storage and migrate your filestore to the cloud, we strongly
recommend that you do a complete system backup.
To learn more, please refer to Introduction to Microsoft Azure Storage in the Microsoft Azure
documentation.

Setting up Artifactory to Use Azure Blob Storage
First time installation or upgrade
Whether you are installing Artifactory for the first time, or are moving your filestore to Azure Blob Storage in the context of upgradin
g Artifactory, we recommend that you first do a standard installation of Artifactory using the default settings, or a standard upgrade
using your current settings.
To move your Artifactory filestore to Azure Blob Storage, execute the following steps:
Shut down Artifactory.
Set your enterprise license
Configure Artifactory to use Azure Blob Storage
Migrate your filestore to the cloud
Start up Artifactory

Setting Your License
To use Azure Blob Storage, your Artifactory installation needs to be activated with an enterprise license.

Configuring Artifactory to Use Azure Blob Storage
To configure Artifactory to use Azure Blob Storage, you need to use the Azure Blob Storage binary provider described in Configuring the
Filestore.

Migrating Your Filestore
For an Artifactory HA cluster running version 5.0 and above, to migrate your filestore, please refer to Migrating Data from NFS.

Black Duck Code Center Integration
Deprecated
As of Artifactory v5.0, integration of Black Duck Code Center has been deprecated.
Access to Black Duck services is still available through its integration into JFrog Xray. For details, please
refer to the JFrog Xray documentation.

Filestore Sharding
Overview
From version 4.6, Artifactory offers a Sharding Binary Provider that lets you manage your binaries in a
sharded filestore. A sharded filestore is one that is implemented on a number of physical mounts (M), which
store binary objects with redundancy (R), where R <= M.
For example, the diagram below represents a sharded filestore where M=3 and R=2. In other words, the
filestore consists of 3 physical mounts which store each binary in two copies.

Artifactory’s sharding binary provider presents several benefits:
Unmatched stability and reliability
Thanks to redundant storage of binaries, the system can withstand any mount going down as long as M >=
R.

Unlimited scalability
If the underlying storage available approaches depletion, you only need to add another mount; a process that
requires no downtime of the filestore. Once the mount is up and running, the system regenerates the filestore
redundancy according to configuration parameters you control.
Filestore performance optimization
Sharding Binary Provider offers several configuration parameters that allow you to optimize how binaries are
read from or written to the filestore according to your specific system’s requirements.
Enterprise license required
Sharded filestore is available for Artifactory installations activated with an enterprise license.

Page Contents
Overview
Configuring a Sharding Binary Provider
Basic Sharding Configuration
Using Balancing to Recover from Mount Failure
Restoring Balance in Unbalanced Redundant Storage Units
Optimizing System Storage

Configuring a Sharding Binary Provider
A sharding binary provider is a binary provider as described in Configuring the Filestore. Basic sharding configuration is used to configure a
sharding binary provider for an instance of Artifactory Pro.

Basic Sharding Configuration
The following parameters are available for a basic sharding configuration:

This parameter dictates the strategy for reading binaries from the mounts that make up the sharded filestore.
readBehavior

Possible values are:
roundRobin (default): Binaries are read from each mount using a round robin strategy.

writeBehavior

redundancy

Default: r=1
The number of copies that should be stored for each binary in the filestore. Note that redundancy must be
less than or equal to the number of mounts in your system for Artifactory to work with this configuration.
Default: 30,000 ms

concurrentStreamWaitTimeout

To support the specified redundancy, accumulates the write stream in a buffer, and uses “r” threads
(according to the specified redundancy) to write to each of the redundant copies of the binary being written. A
binary can only be considered written once all redundant threads have completed their write operation. Since
all threads are competing for the write stream buffer, each one will complete the write operation at a different
time. This parameter specifies the amount of time (ms) that any thread will wait for all the others to complete
their write operation.
If a write operation fails, you can try increasing the value of this parameter.

concurrentStreamBufferKb

Default: 32 Kb
The size of the write buffer used to accumulate the write stream before being replicated for writing to the “r”
redundant copies of the binary.
If a write operation fails, you can try increasing the value of this parameter.

maxBalancingRunTime

Default: 3,600,000 ms (1 hour)
Once a failed mount has been restored, this parameter specifies how long each balancing session may run
before it lapses until the next Garbage Collection has completed. For more details about balancing, please
refer to Using Balancing to Recover from Mount Failure.
To restore your system to full redundancy more quickly after a mount failure, you may increase the
value of this parameter. If you find this causes an unacceptable degradation of overall system
performance, you can consider decreasing the value of this parameter, but this means that the
overall time taken for Artifactory to restore full redundancy will be longer.

Default: 3,600,000 ms (1 hour)
freeSpaceSampleInterval

To implement its write behavior, Artifactory needs to periodically query the mounts in the sharded filestore to
check for free space. Since this check may be a resource intensive operation, you may use this parameter to
control the time interval between free space checks.
If you anticipate a period of intensive upload of large volumes of binaries, you can consider
decreasing the value of this parameter in order to reduce the transient imbalance between mounts
in your system.

Default: 2
minSpareUploaderExecutor

Artifactory maintains a pool of threads to execute writes to each redundant unit of storage. Depending on the
intensity of write activity, eventually, some of the threads may become idle and are then candidates for being
killed. However, Artifactory does need to maintain some threads alive for when write activities begin again.
This parameter specifies the minimum number of threads that should be kept alive to supply redundant
storage units.
Default: 120,000 ms (2 min)

uploaderCleanupIdleTime

The maximum period of time threads may remain idle before becoming candidates for being killed.

Example 1

The code snippet below is a sample configuration for the following setup:
A cached sharding binary provider with three mounts and redundancy of 2.
Each mount "X" writes to a directory called /filestoreX.
The read strategy for the provider is roundRobin.
The write strategy for the provider is percentageFreeSpace.

// Specify the read and write strategy and redundancy for the sharding
binary provider

roundRobin
percentageFreeSpace
2

//For each sub-provider (mount), specify the filestore location

filestore1

filestore2

filestore3

Example 2

The following code snippet shows the "double-shards" template which can be uses as is for your binary store configuration.

shard-fs-1

shard-fs-2

The double-shards template uses a cached provider with two mounts and a redundancy of 1, i.e. only one copy of each artifact is stored.

To modify the parameters of the template, you can change the values of the elements in the template definition. For example, to increase
redundancy of the configuration to 2, you only need to modify the tag as shown below.

Using Balancing to Recover from Mount Failure
In case of a mount failure, the actual redundancy in your system will be reduced accordingly. In the meantime, binaries continue to be written to
the remaining active mounts. Once the malfunctioning mount has been restored, the system needs to rebalance the binaries written to the
remaining active mounts to fully restore (i.e. balance) the redundancy configured in the system. Depending on how long the failed mount was
inactive, this may involve a significant volume of binaries that now need to be written to the restored mount, which may take significant amount of
time. Since restoring the full redundancy is a resource intensive operation, the balancing operation is run in a series of distinct sessions until
complete. These are automatically invoked after a Garbage Collection process has been run in the system.

Restoring Balance in Unbalanced Redundant Storage Units

In the case of voluntary actions that cause an imbalance the system redundancy, such as when doing a filestore migration, you may manually
invoke rebalancing of redundancy using the Optimize System Storage REST API endpoint. Applying this endpoint raises a flag for Artifactory to
run rebalancing following the next Garbage Collection. Note that, to expedite rebalancing, you can invoke garbage collection manually from the
Artifactory UI.

Optimizing System Storage
Artifactory REST API provides an endpoint that allows you to raise a flag to indicate that Artifactory should invoke balancing between redundant
storage units of a sharded filestore after the next garbage collection. For details, please refer to Optimize System Storage.

Filtered Resources
Overview
The Filtered Resources Add-on (introduced in Artifactory version 2.3.3) allows treating any textual file as a
filtered resource by processing it as a FreeMarker template.
Each file artifact can be marked as 'filtered' and upon receiving a download request, the content of the artifact
is passed through a FreeMarker processer before being returned to the user.
This is an extremely powerful and flexible feature because Artifactory applies some of its own APIs to the
filtering context (see below), allowing you to create and provision dynamic content based on information
stored in Artifactory.
For example, you can provision different content based on the user's originating IP address or based on
changing property values attached to the artifact.
Page Contents
Overview
Marking an Artifact as a Filtered Resource
Filtering Context
Provisioning Build Tool Settings
Example

Marking an Artifact as a Filtered Resource
Any artifact can be specified as filtered by selecting it in the Artifact Repository Browser and setting the Filtered checkbox in the General tab.
Permissions
You must have Annotate permissions on the selected artifact in order to specify it as "Filtered".

Filtering Context
Artifactory provides the following environment variables for the FreeMarker template:
"properties" (org.artifactory.md.Properties) - Contains the properties of the requested artifact and any matrix params included in the
request; when a clash of properties with identical keys occurs, the former takes precedence
"request" (org.artifactory.request.Request) - The current request that was sent for the artifact
"security" (org.artifactory.security.Security) - Artifactory's current security object

Provisioning Build Tool Settings
When logged-in as an admin user, you can provision your user-generated settings for the various build tools (Maven, Gradle and Ivy) using the
Filtered Resources features.
To provision user-generated settings:
1. In the Artifact Repository Browser, click "Set Me Up" to display the settings generator.
2. Select your build tool, set the appropriate repositories and click "Generate Settings".

3.
4.
5.
6.

Download the generated settings and edit them as required.
Back in the Artifact Repository Browser, click "Deploy".
In the Deploy dialog, set your Target Repository, upload your settings file and set your Target Path.
Click "Deploy" to deploy your settings.

Example
The following example demonstrates provisioning a different resource based on the current user group and a property on the requested artifact.

In this example, the artifact 'vcsProj.conf.xml' has a property 'vcs.rootUrl' which holds the root URL for
the version control system. Depending on the user group a different project version control URL is returned.
For the template of 'vcsProj.conf.xml':

<#list properties.get("vcs.rootUrl") as vcsUrl>
<#list security.getCurrentUserGroupNames() as groupName>
${vcsUrl}/<#if groupName == "dev-product1">product1<#elseif
groupName == "dev-product2">product2<#else>global

If, for example, the value of the the 'vcs.rootUrl' property on the 'vcsProj.conf.xml' artifact is 'http://vcs.company.com' and the
file is downloaded by a developer belonging to the 'dev-product2' group, then the returned content is:

http://vcs.company.com/product2

GPG Signing

Overview
Artifactory lets you manage a pair of GPG signing keys so you can sign packages for authentication in
several formats such as Debian, Opkg and YUM. You can manage your GPG signing keys in the Admin mod
ule under Security | Signing Keys.

Generating Keys
The way to generate keys is platform dependent.
The example below shows how to generate the public and private keys on Linux:
Page Contents
Overview
Generating Keys
Uploading Keys
Downloading the Public Key

Generating PGP keys
# generate the keys
gpg --gen-key
# list all keys in your system and select the pair you want to use in
Artifactory
gpg --list-keys
# resolve the key-id from the lists-keys by selecting the relevant license
pub
2048R/8D463A47 2015-01-19
uid
JonSmith (Jon)
key-id = 8D463A47
#export the private key with the specified id to a file
gpg --output {private key file name and path} --armor --export-secret-keys
{key-id}
#export the public key with the specified id to a file
gpg --output {public key file name and path} --armor --export {key-id}

You also need to specify a pass phrase that must be used together with the signing keys. The pass phrase can be saved, or passed in with a
REST API call.

Uploading Keys
To upload your signing keys, in the Admin tab, go to Security | Signing Keys.

Once you have specified the key file, select the "Upload" button for the corresponding field.
Artifactory will indicate when keys are installed, and you can click on the Public key is installed link to download the public key.
If your signing keys were created with a pass-phrase, enter it in the designated field. You can click "Verify" to make sure the pass-phrase matches
the uploaded keys.
Click "Save" to save your changes.
Don't forget to click "Save"
To ensure that your signing keys are properly stored in Artifactory's database, you need to click "Save" even if your signing keys do not
have a pass-phrase.

Upload your pass-phrase with REST
If you prefer not to upload your pass phrase using the UI, you can set it using the REST API.

Downloading the Public Key
Once you have uploaded your signing keys, you can download your public key whenever needed using the Public key is installed link.

Google Cloud Storage
Overview

From version 4.6, Artifactory fully supports Google Cloud Storage (GCS) so your Artifactory filestore can
reside on the cloud. This presents several benefits:
1. Unlimited scalability
Since your files are now stored on the cloud, this means that your Artifactory filestore is scalable and
effectively unlimited (to the extent offered by your storage provider). You may freely continue to
upload files without having to install or maintain any file storage devices. You can even upload files
larger than 5 GB using multi-part upload.
2. Security
Google's security model offers end-to-end process offering a replicated strategy with all data
encrypted both in-flight and at rest.
3. Disaster recovery
Since your files are replicated and stored with redundancy, this offers the capability for disaster
recovery.
Support for GCS is included with JFrog Enterprise Edition.
In order to use GCS with Artifactory, make sure you first install or upgrade to Artifactory V4.6 or later.
Backup your system. Your current filestore will be deleted.
Setting up Artifactory to use GCS will delete all files in your current filestore.
If you already have a running installation of Artifactory, then before you setup Artifactory to use
GCS and migrate your filestore to the cloud, we strongly recommend that you do a complete
system backup.

Page Contents
Overview
Setting up Artifactory
to Use GCS
Setting Your
License
Configuring
Artifactory to
Use GCS
Interoperable
Storage
Access Keys
Migrating Your
Filestore

Setting up Artifactory to Use GCS
First time installation or upgrade
If you are moving your filestore to GCS in the context of upgrading Artifactory, or a first time installation, we recommend that you first do
a standard installation of Artifactory using the default settings, or a standard upgrade using your current settings.
In order to move your Artifactory filestore to the cloud, you need to execute the following steps:
Shut down Artifactory.
Set your enterprise license
Configure Artifactory to use GCS
Migrate your files to the cloud
Start up Artifactory

Setting Your License
To use Artifactory's support for GCS, you need to have an enterprise license with your Artifactory installation.
To do so, make sure your $ARTIFACTORY_HOME/etc/artifactory.lic file contains your enterprise license.

Configuring Artifactory to Use GCS
To configure Artifactory to use a GCS object storage provider, you need to use the Google Cloud Storage binary provider described in Configuring
the Filestore making sure to set the following parameters:
JetS3t Framework
Artifactory uses the JetS3t framework to access GCS. Some of the parameters below are used to set the corresponding value in the
framework. For more details, please refer to the JetS3t Configuration Guide.

Parameter

Description
Default: true

testConnection

When true, the Artifactory uploads and downloads a file when starting up to verify that the connection to the cloud storage
provider is fully functional.
Default: 100,000,000 bytes

multiPartLimit

File size threshold over which file uploads are chunked and multi-threaded.
Your cloud storage provider identity.

identity

Your cloud storage provider authentication credential.
credential

Your globally unique bucket name on GCS.
bucketName

The relative path to your files within the bucket
path

Corresponding parameters if you are accessing the cloud storage provider through a proxy server.
proxyIdentity

proxyCredential

proxyPort

proxyHost

Default: 80
port

The port number through which you want to access GCS. You should only use the default value unless you need to contact
a different endpoint for testing purposes.
Default: commondatastorage.googleapis.com.

endpoint

The GCS hostname. You should only use the default value unless you need to contact a different endpoint for testing
purposes.
Default: false.

httpsOnly

Set to true if you only want to access GCS through a secure https connection.
Default: 443

httpsPort

The port number through which you want to access GCS securely through https. You should only use the default value
unless you need to contact a different endpoint for testing purposes.
Default: false. Only available on google-storage.

bucketExists

When true, it indicates to the binary provider that a bucket already exists in Google Cloud Storage and therefore does not
need to be created.

The following snippet shows the default chain that uses google-storage as the binary provider:

commondatastorage.googleapis.com

XXXXXX
XXXXXXX

Interoperable Storage Access Keys
The Interoperability API lets you use HMAC authentication and lets GCS interoperate with tools written for other cloud storage systems. To use
GCS, you need to turn on this API and use interoperability access details of the current user in GCS. This API is enabled per project member, not
per project. Each member can set a default project and maintain their own access keys. For more details, please refer to Google Cloud Storage
Interoperability.
You can obtain your access key parameters through your Google GCS account console and set them into the corresponding parameters in
Artifactory as follows:
This parameter is provided by GCS as your access key
identity

This parameter is provided by GCS as your access secret
credential

Keep your database settings
Make sure you don't change your database settings in your db.properties file.

Migrating Your Filestore
To migrate your filestore, you need to execute the following steps:
Stop Artifactory
Copy the $ARTIFACTORY_HOME/data/filestore directory to your GCS bucket name and path specified when you configured
Artifactory to use GCS.
Start Artifactory

LDAP Groups
Overview
The LDAP Groups Add-on allows you to synchronize your LDAP groups with Artifactory and leverage your
existing organizational structure for managing group-based permissions.
Unlike many LDAP integrations, LDAP groups in Artifactory use super-fast caching, and has support for both
Static, Dynamic and Hierarchical mapping strategies. Powerful management is accomplished with multiple
switchable LDAP settings and visual feedback about the up-to-date status of groups and users coming from
LDAP.
LDAP groups synchronization works by instructing Artifactory about the external groups authenticated users
belong to. Once logged-in, you are automatically associated with your LDAP groups and inherit group-based
permission managed in Artifactory.
Make sure users log in
Synchronizing LDAP groups does not automatically create users that are members of those
groups. Once the LDAP connection is configured, the LDAP users are only created in Artifactory
after they log in to Artifactory for the first time. Automatic creation of users can be controlled by the
Auto Create Artifactory Users checkbox in the LDAP Settings screen.

Page Contents
Overview
Usage
Group Synchronization Strategies
Synchronizing LDAP Groups with Artifactory
Importing Groups Through the UI
Using the REST API
Watch the Screencast

Usage
LDAP Groups settings are available in the Admin module under Security | LDAP.
To use LDAP groups you must first set up an LDAP server for authentication from the LDAP Settings screen. You must also alert Artifactory
about the correct LDAP group settings to use with your existing LDAP schema.
Active Directory Users
For specific help with setting up LDAP groups for an Active Directory installation please see Managing Security with Active Directory.

Group Synchronization Strategies
Artifactory supports three ways of mapping groups to LDAP schemas:
Static: Group objects are aware of their members, however, the users are not aware of the groups they belong to.
Each group object such as groupOfNames or groupOfUniqueNames holds its respective member attributes, typically member or uniq
ueMember, which is a user DN.
Dynamic: User objects are aware of what groups they belong to, but the group objects are not aware of their members.
Each user object contains a custom attribute, such as group, that holds the group DNs or group names of which the user is a member.
Hierarchy: The user's DN is indicative of the groups the user belongs to by using group names as part of user DN hierarchy.
Each user DN contains a list of ou's or custom attributes that make up the group association.
For example,
uid=user1,ou=developers,ou=uk,dc=jfrog,dc=org indicates that user1 belongs to two groups: uk and developers.
Using OpenLDAP
When using OpenLDAP, you can't apply the Dynamic strategy because the memberOf attribute is not defined by default (memberOf is
an overlay), so Artifactory would not be able to fetch it from the LDAP server.

Synchronizing LDAP Groups with Artifactory
Importing Groups Through the UI
Once you have configured how groups should be retrieved from your LDAP server, you can verify your set up by clicking the Refresh button on
the Synchronize LDAP Groups sub-panel. A list of available LDAP groups is displayed according to your settings.
You are now ready to synchronize/import groups into Artifactory. The groups table allows you to select which groups to import and displays the
sync-state for each group:
A group can either be completely new or already existing in Artifactory. If a group already exists in Artifactory it can become outdated (for
example, if the group DN has changed) - this is indicated in the table so you can select to re-import it.
Once a group is imported (synced) a new external LDAP group is created in Artifactory with the name of the group.

Once you have imported LDAP groups, you can Manage Permissions on them as with regular Artifactory groups. Users association to these
groups is external and controlled strictly by LDAP.
Make sure that LDAP group settings is enabled (in the LDAP Groups Settings panel) in order for your settings to become effective.

To synchronize a group through the UI, in the Admin module, under Security | LDAP, select the group you want to synchronize, and search for
groups that have been defined under the corresponding group settings. Once groups have been found, select Import.

Once the groups are synchronized, you should see them in your list of groups (Admin module under Security | Groups) indicated as "External".

Using the REST API
You may also synchronize LDAP groups by using the Create Group REST API to create groups with the ‘ldap’ realm and full DN path to the group
object under your LDAP server.
Limitation
Make sure to use lower case only when creating LDAP groups through the REST API. Using upper or mixed case will prevent
synchronization of groups.
When using the REST API to synchronize LDAP groups, you need to specify the exact and full Group DN path to the group on your LDAP server.
The example below shows the JSON payload you would use to synchronize the "testgroup" group displayed in the below LDAP server:

Sample JSON:
{
"name": "testgroup",
"description" : "This groups already exists in ldap",
"autoJoin" : false,
"realm": "ldap",
"realmAttributes":
"ldapGroupName=testgroup;groupsStrategy=STATIC;groupDn=cn=testgroup,ou=sup
port,ou=UserGroups,dc=openstack,dc=org"
}

Watch the Screencast

License Control
Controlling Third Party Licenses
The License Control Add-on completes the Artifactory Build Integration Add-on allowing you full control over
the licenses of the dependencies used by your builds (and eventually in your software).
This Add-on is part of the Artifactory Pro Power Pack.
As part of the Build Server deployment to Artifactory, it analyzes the used dependencies and tries to match
them against a set of license management rules.
Notifications can be sent to a selected list of recipients about dependencies with unknown or unapproved
license information.
To support this feature Artifactory includes a new license management facility where rules about license

matching and approval status are defined. These rules are consulted as part of the license analysis.
How does license analysis work?
Automatic analysis is performed upon deployment by examining information found in artifact
module files. Currently Maven POM, Ivy Descriptor, NuGet, and RPM files are supported.
You can always override the automatic results and assign license information manually to
dependencies. You can also compare the current license status to the auto calculated one and
decide what results of the automatic analysis to accept.
License information is stored with the artifact and reused by the automatic license analysis on
subsequent builds.

Page Contents
Controlling Third Party Licenses
Central License Management
Editing License Information
Using Build Licenses
Build Server Configuration
Examining Build Licenses
Running Manual License Discovery
Setting License Information Manually
Licenses REST API

Central License Management
Licenses are managed in the Admin module under Configuration | Licenses.

You can add a new license by clicking New or edit the information for a license by selecting its License Key in the list.
Artifactory comes preconfigured with all the common OSI licenses and JFrog has already tuned these licenses against common project builds.
By selecting Export, you can also export the license list and import it later on to new Artifactory instances.
Editing License Information

A unique identifier for this license in Artifactory
License Key

A description of the license
Long Name

The URL that describes the terms of the license
URLs

Additional notes
Notes

The regular expression by which to match the license (by comparing it to license information in module files).
RegExp

If you leave the regexp field blank, Artifactory attempts an exact match against the license key.

When set, this license is approved which means you allow the use of components that come with this license.
Approved

Using Build Licenses
Build Server Configuration
When you run a build from your CI server (Hudson, TeamCity or Bamboo), configure the Artifactory Plugin to run license checks as part of the
build.

Below is a sample section from the Hudson configuration of the Artifactory Plugin:

You can configure whether or not you wish license checks to take place as part of deploying Build Info to Artifactory (the Build Info Bill of Materials
must be deployed to Artifactory for license checks to run).
You can also set a list of recipients to be notified about license violations as soon as they occur. This way whenever a dependency with an
unknown or unapproved license is added to the build recipients receive an immediate email notification and can tend to any potential license
violation.
Sending license violation notifications is performed through Artifactory and requires a valid mail server to be configured.

Not failing the build
Currently, Artifactory does not fail the build as a result of license violations.
This is an informed decision in the spirit of allowing technical development to continue, while alerting others about the advent of
unauthorized dependencies in near or real-time, so they can be addressed early on by the appropriate parties.

Examining Build Licenses

Once the build has finished on the build server and Build Info has deployed to Artifactory, license checks are run.
You can view detailed license information in the Licenses tab of the Build Browser. This tab displays information about all the dependencies
used in the build and the license they are associated with. To group the information by Scope or License click the corresponding column header.

The summary panel displays the overall count of licenses by status and inside the table itself, licenses are displayed in different colors according
to their status:
License Status

Description

Unapproved

The license found is not an approved license

Unknown

License information was found but cannot be related to any license managed in Artifactory

Not Found

No license information could be found for the artifact.

Neutral

The license found is unapproved, however another approved license was found for the artifact
(Only applicable for artifacts that are associated with multiple licenses)

Approved

The license found is an approved license

Inline License Editing

From the Build Browser, an Artifactory administrator can manually change the license information for any artifact displayed. Clicking the entry
under the License column for any artifact will display the Edit 'artifactory.licenses' Property dialog where the administrator can specify the
licenses for that artifact. For example, clicking the Public Domain license entry from the screenshot above will display the following dialog:

Running Manual License Discovery

You can manually run the license discovery rules after a build has already run. There are several reasons why you may want to do this:
1. License rules (configured licenses and regular expressions) have changed and you want to compare the existing build licenses with the
results of the new rules, or use them to complete missing license information.
2. To test the current rules against the dependencies and tweak the rules, if necessary.
3. To check which license information can come from rules and which license information must be set manually.
To trigger license discovery select the "Auto-find Licenses" button.

Any license conflicts are displayed to the right of the table. You can override the existing license information with the
discovered license by checking the corresponding checkbox (you must have annotate permissions for the artifacts fo
r which you want to override licenses).

Setting License Information Manually
To set license information for artifacts manually, when viewing an artifact's details in the Artifact Repository Browser, in the General tab Licens
es entry, click Add.
This will display the Add Artifactory Licenses Property dialog where you can specify the licenses for the selected artifact.

Multiple licenses
Note that an artifact may be associated with multiple licenses

Scanning artifact Maven/Ivy model for license

Another option for editing the license information is by scanning the Maven/Ivy model for licenses, that is, looking for an existing pom matching
the artifact.
Once you have the artifact selected in the tree browser go to the General tab and under the License label choose Scan and confirm licenses
found in the scan results, if any.
Yet another option would be to use the 'Search For Archive License File' link, which will scan the artifact archive for a 'License' or 'License.txt'
entry and ask for confirmation, if found.
License Information as Properties

Internally, license information is stored as regular properties, using the built-in artifactory.licenses property name.
Therefore, all operations with properties are available to license information (searches, recursive assignment, property-based deployment and
resolution etc.)

Licenses REST API
License-oriented searches and management operations are available through the REST API.
Refer to the REST API Documentation for usage information.

OAuth Integration
Overview
From version 4.2, Artifactory is integrated with OAuth allowing you to delegate authentication requests to
external providers and let users login to Artifactory using their accounts with those providers.
Currently, the provider types supported are Google, OpenID Connect, GitHub Enterprise, and Cloud
Foundry UAA. You may define as many providers of each type as you need.

Usage
When OAuth is enabled in Artifactory, users may choose to sign in through any of the supported OAuth
providers. To log in through a provider, simply click on the provider's button in the login screen.

You will be redirected to the login screen of the corresponding provider.
If you are already logged in to any of that provider's applications you will not need to log in again, but you
may have to authorize Artifactory to access your account information, depending on the provider type.
Page Contents
Overview
Usage
Configuring OAuth
Adding a New Provider
Using Query Params
Binding Existing User Accounts
Creating OAuth Provider Accounts
GitHub OAuth Setup
Google OAuth Provider Setup
Cloud Foundry UAA Setup
Using Secure OAuth
Using API Key with OAuth Users
Using OAuth on High Availability Setup

Configuring OAuth
To access OAuth integration settings, in the Admin module, select Security | OAuth SSO.

Enable OAuth

Auto Create Artifactory
Users

Default Provider

If checked, authentication with an OAuth provider is enabled and Artifactory will display all OAuth providers
configured. If not checked, authentication is by Artifactory user/password.
If checked, Artifactory will create an Artifactory user account for any new user logging in to Artifactory for the first
time.

Specifies the provider through which different clients (such as NPM, for example) should authenticate their login
to gain access to Artifactory.
Default provider
Currently, only a GitHub Enterprise OAuth provider may be defined as the Default Provider.

Allow Created Users
Access To Profile Page

When checked, users created after authenticating using OAuth, will be able to access their profile. This means
they are able to generate their API Key and set their password for future use.

Custom URL base
For your OAuth settings to work, make sure you have your Custom URL Base configured.

Adding a New Provider
The list of providers defined in Artifactory is displayed in the Providers section.

To add a new provider, click "New". Artifactory displays a dialog letting you enter the provider details. These may vary slightly depending on the
provider you are configuring.

The following table describes the settings required by each supported provider, and the corresponding values you should use (where available):

GitHub.com

GitHub Enterprise

Google

Enabled

Provider
Name

Provider
Type

Provider
ID

Secret

Domain

Docker
Login

Npm
Login
https://github.com/

https://github.com/login/oauth/authorize

/login/oaut
h/authorize

https://accounts.google.com/o/oauth2/auth

https://api.github.com/user

/api/v3/user

https://www.googleapis.com/oauth2/v1/userinfo

https://github.com/login/oauth/access_token

/login/oauth/access_token

https://www.googleapis.com/oauth2/v3/token

Basic
URL

Auth
URL

GitHub.com Accounts
Any GitHub.com account that has access to
the Artifactory URL will be allowed to login,
including accounts that are outside your
GitHub.com organization scope.

API URL

Token
URL

Using Query Params
You may pass query params along with the Authorization URL. For example,

https://github.com/login/oauth/authorize?realm=Employees

Multiple query params should be separated with an ampersand. For example,

https://github.com/login/oauth/authorize?realm=Employees?client_id=XXXXXXX
XXXX&scope=openid%20profile%20email

Binding Existing User Accounts
If you already have an internal (not external realms such as LDAP, SAML...) account in Artifactory, in order to be able to login using any of
your OAuth provider accounts, you need to bind your Artifactory account to the corresponding account.
To bind your account, go to your Profile page and enter your Artifactory password to unlock it.
Under OAuth User Binding, select Click to bind next to the OAuth provider you wish to bind to.

Creating OAuth Provider Accounts
In order to use OAuth authentication, you need to set up an account with each OAuth provider you wish to use in order to get the various
parameters (such as Provider ID and Secret) you will need to set up OAuth integration in Artifactory.

GitHub OAuth Setup
Caution: Access to GitHub.com Accounts
Any GitHub.com account that has access to the Artifactory URL will be allowed to login, including accounts that are outside your GitHub
.com organization scope. This does not apply to GitHub Enterprise.

To set up your OAuth account on GitHub, execute the following steps:
1. Login to your GitHub account. Under your personal profile settings, select Applications and click the Developer Applications tab.
2. Click Register new application.
3. Set the Application name. For example, Artifactory SaaS OAuth.
4. Set the Homepage Url. This is your Artifactory server host URL (https:///).
For example, https://mycompany.jfrog.io/mycompany/
5. Set the Authorization Callback Url as follows:
a. For Artifactory on-prem installation: http:///artifactory/api/oauth2/loginResponse
For example, http://mycompany.artifactory.com/artifactory/api/oauth2/loginResponse
b. For Artifactory SaaS: https://.jfrog.io//api/oauth2/loginResponse
For example, https://mycompany.jfrog.io/mycompany/api/oauth2/loginResponse
6. Click Register application to generate your Client ID and Client Secret.
Make a note of these; you will need them to configure OAuth authentication through GitHub on Artifactory.

Google OAuth Provider Setup
To set up your OAuth account on Google, execute the following steps:
1.
2.
3.
4.

Login to Google Developer Console.
Create a new project. For example, "Artifactory OAuth".
Once the project is created, in the left navigation bar, select APIs & auth | Credentials.
Select the OAuth consent screen tab and configure the consent screen end users will see when logging in with the Google credentials.

5. Back in the Credentials tab, Click Add Credential and select OAuth 2.0 client ID

6. Under Create client ID, select Web application.
7. Enter a Name and set the Authorized redirect URIs
For Artifactory on-prem: https:///artifactory/api/oauth2/loginResponse
For Artifactory SaaS: https://.jfrog.io//api/oauth2/loginResponse

8. Click Create to generate your Client ID and Client Secret.

Make a note of these; you will need them to configure OAuth authentication through Google on Artifactory.

Cloud Foundry UAA Setup
OAuth authentication with Cloud Foundry UAA is supported from Artifactory version 4.2.1.
To setup your OAuth authentication with Cloud Foundry UAA, fill in the fields as needed.

Using Secure OAuth
To use secure OAuth with a valid certificate from a CA trusted by Java, all you need to do us use a secure OAuth URL in your settings.
If you want to use OAuth with a non-trusted (self-signed) certificate, please follow the steps described in Using a Self-Signed Certificate.

Using API Key with OAuth Users
While OAuth provides access to Artifactory UI, it is also possible for OAuth users to generate an API key that can be used instead of a password
for basic authentication or in a dedicated REST API header, this is very useful when working with different clients, e.g. docker, npm, maven, etc.
or using Artifactory REST API.
In order to allow OAuth users access to an API key you will need to make sure that the "Auto Create Artifactory Users" and "Allow Created
Users Access To Profile Page" check boxes are checked. This means that OAuth users are also saved in Artifactory database and can access
their profile page in order to generate, retrieve and revoke their API key.

Using OAuth on High Availability Setup
The OAuth protocol requires the client to give permission to a specific application. Artifactory will redirect the user to the configured application
URL and one permission is granted user will be navigated back.
The limitation on this process when working in High Availability setup is that the user must return to the same node, otherwise the authentication
process will fail, in order to achieve this a sticky session configuration should include the /artifactory/api/oauth2/.
The example below shows NGINX configuration.

NGINX Reverse Proxy Configuration
location ~ (/artifactory/webapp/|/artifactory/ui/|/artifactory/api/oauth2/)
{
proxy_http_version
1.1;
proxy_pass
http://;
proxy_intercept_errors on;
proxy_pass_header
Server;
proxy_connect_timeout
75s;
proxy_send_timeout
2400s;
proxy_read_timeout
2400s;
proxy_set_header
Host $host;
proxy_set_header
X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header
X-Forwarded-Proto $http_x_forwarded_proto;
proxy_set_header
X-Real-IP $remote_addr;
proxy_set_header
X-Artifactory-Override-Base-Url
$http_x_forwarded_proto://$host/artifactory;
}

Properties
Overview
Artifactory allows you to place properties on both artifacts and folders. Setting (and deleting) properties is
supported by local repositories or local-cache repositories. While you cannot set or delete properties on
virtual repositories, you can retrieve them.
You can assign properties from the UI, via REST (see below), or on deployment, using Matrix Parameters.
Properties can also be used to Control Artifacts Resolution.
Properties are searchable and can be combined with Smart Searches to search for items based on their
properties and then manipulate all the items in the search result in one go.

Property Sets
You can define the collections of properties called 'Property Sets' in the user interface. In each property-set
you can define properties and for each property specify whether the property is open, single-value or
multi-value.
This impacts the user interface you see when setting a property value and when searching for property
values. Using searchable properties in artifact management is a very powerful feature.
Page Contents
Overview
Property Sets
Attaching Properties via the UI
Attaching and Reading Properties via REST API

Read More
Using Properties in Deployment and Resolution

Properties are for Guiding, not for Restricting
When you define a property-set with 'strongly-typed' property values, those values are used to provide an intuitive, guiding UI for
tagging and locating items.
The actual value does not force a strong relationship to the original property-set's predefined values. This is by design, to not slow-down
common repository operations and for keeping artifacts management simple by allowing properties to change and evolve freely over
time, without worrying about breaking older property rules.

Properties are therefore a helpful and non-restrictive feature.

Attaching Properties via the UI
When selecting any item in the tree browser, you can view its Properties tab to view or edit the properties attached to the item.

To add a property, simply enter its name and value and click "Add".
To add multi-value properties, enter the values separated with a semi-colon ( ; ). For example:

You can edit the value of any property by clicking on it

Attaching and Reading Properties via REST API
Properties are a special form of metadata and are stored on items just like any metadata - in XML form.
In fact, you can view properties not only from the Artifacts:Properties tab, but also from the Artifacts:Metadata tab, in which you can
examine properties as they are stored in XML form. The properties XML is using the properties root tag and has a very simple format.
You can set, retrieve and remove properties from repository items via REST API, as you would do with any other XML-based metadata.

Using Properties in Deployment and Resolution
Introducing Matrix Parameters
Matrix parameters key-value pairs parameters separated by a semicolon (;) that you can place anywhere on
a URI.
This is a standard method for specifying parameters in HTTP (in addition to querying parameters and path
parameters).
For example:
http://repo.jfrog.org/artifactory/libs-releases-local/org/libs-releases-local/or
g/jfrog/build-info-api/1.3.1/build-info-api-1.3.1.jar;status=DEV;rating=5
Artifactory makes use of matrix parameters for:
1. Adding properties to artifacts as part of deployment
2. Controlling artifact resolution using matrix parameters
Page Contents
Introducing Matrix Parameters
Dynamically Adding Properties to Artifacts on Deployment
Controlling Artifact Resolution with Matrix Parameters Queries
Non-mandatory Properties
Mandatory Properties
Multi-valued Properties Support

Dynamically Adding Properties to Artifacts on Deployment
You can add key-value matrix parameters to deploy (PUT) requests and those are automatically transformed to properties on the deployed

artifact.
Since matrix parameters can be added on any part of the URL, not just at the end, you can add them to the target deployment base URL. At the
time of deployment, the artifact path is added after the matrix parameters and the final deployed artifact will be assigned the defined properties.

You can even use dynamic properties, depending on our deployment framework.
When using Maven, for instance, you can add two parameters to the deployment URL: buildNumber and revision, which Maven replaces at
deployment time with dynamic values from the project properties (e.g. by using the Maven build-number plugin).
So, if you define the distribution URL as:

http://myserver:8081/artifactory/qa-releases;buildNumber=${buildNumber};re
vision=${revision}

And deploy to the qa-releases repository a jar with the following path:

/org/jfrog/build-info-api/1.3.1/build-info-api-1.3.1.jar

Upon deployment the URL is transformed to:

http://myserver:8081/artifactory/qa-releases;buildNumber=249;revision=1052
/org/jfrog/build-info-api/1.3.1/build-info-api-1.3.1.jar

And the deployed build-info-api-1.3.1.jar has two new properties:

buildNumber=249
revision=1052

Permissions to attach properties
You must have the 'Annotate' permission in order to add properties to deployed artifacts.

Controlling Artifact Resolution with Matrix Parameters Queries
Matrix parameters can also be used in artifact resolution, to control how artifacts are found and served.
There is currently support for two types of queries:
Non-conflicting values
Mandatory values.
Non-mandatory Properties

Resolved artifacts may either have no property with the key specified, or have the property with the key specified and the exact value specified
(i.e. the artifact is resolved if it has a property with a non-conflicting value).
Non-mandatory properties are identified by a simple key=value parameter.
For example:
Current Artifact Property

Matrix Parameter

Resolution Result

color=black

OK (200)

None or height=50

color=black

OK (200)

color=red

color=black

NOT_FOUND (404)

Mandatory Properties

Resolved artifacts must have a property with the key specified and the exact value specified.
Mandatory properties are identified with a plus sign (+) after the property key: key+=value.
For example:
Current Artifact Property

Matrix Parameter

Resolution Result

color=black

color+=black

OK (200)

None or height=50

color+=black

NOT_FOUND (404)

color=red

color+=black

NOT_FOUND (404)

Multiple properties in queries
Multiple key-value matrix parameters are additive, forming an AND query between each key-value subsection.

Multi-valued Properties Support
All matrix parameters can support multiple values by separating values with a comma (,). For example:

colors=red,gold,green

Repository Layouts
Overview
Together with the growing number of choices for build-tools and frameworks there are also many ways in
which modules can be stored within a repository.
Initially, Artifactory supported the Maven layout conventions for dealing with modules (and relying on
Maven-specific metadata). However, your build tool should be able to "talk" to the repository "naturally", so if
you are using Ivy or Gradle, there is no need to configure them to use the Maven conventions in order to "fit
in". Moreover, combining and chaining repositories that use different layouts should work out-of-the-box.
This is where the Repository Layouts Add-on comes into play!

The Freedom of Custom Layouts
With the Repository Layouts Add-on, Artifactory allows you to take full control over the layout used by each
repository and uses layout definitions to identify module artifacts and descriptors. By using repository layouts,
Artifactory offers these smart module management facilities for any build technology:
Automatic snapshot/integration versions cleanup
Deleting old versions
Conversions between remote and local layouts
Conversions between 2 local layouts when moving or copying
Resolution conversions from a virtual repository to its underlying repositories (where the virtual
repository has its own layout defined)
Page Contents
Overview
The Freedom of Custom Layouts
Bundled Layouts
Modules and Path Patterns used by Repository Layouts
Module Fields
Using Module Fields to Define Path Patterns
Path Pattern Tokens
Artifact Path Patterns
Descriptor Path Patterns
Configuration
Layout Configuration
Testing Layouts

Path Patterns
Regular Expressions for File and Folder Integration Revision
Repository Configuration
Local Repository Configuration
Remote Repository Configuration
Virtual Repository Configuration

Bundled Layouts
Artifactory comes out-of-the-box with a number of default, predefined layouts requiring no additional configuration:
Maven 2/3
Ivy (default layout)
Gradle (Wharf cache default layout)
Maven 1
Support for repository layouts in Artifactory OSS
Layout configuration for conversion and resolution is available only to Artifactory Power Pack users. Users of the OSS version can only
Configure their Repositories to use the default repository layouts bundled with Artifactory.
The OSS version only supports the automatic snapshot/integration version cleanup and deleting old version features.

Modules and Path Patterns used by Repository Layouts
Module Fields
To support smart module management, Artifactory must construct module information for stored files. Artifactory constructs this information based
on path pattern information defined as part of the Repository Layout configuration (detailed below).
A module is comprised of various sub-elements or fields, which are typically expressed in the path of a stored artifact.
The module-sub elements recognized by Artifactory are listed below. At a minimum, there are three mandatory fields required for module
identification:
Organization
Module
Base Revision.
Field

Description

Example

Organization

A sequence of literals that identifies the artifact's organization

"org.slf4j"

Module

A sequence of literals that identifies the artifact's module

"slf4j-api"

Base
Revision

A sequence of literals that identifies the base revision part of the
artifact version, excluding any integration information

"1.5.10", or in case of an integration revision "1.2-SNAP
SHOT" the base revision is "1.2"

Folder
Integration
Revision

A sequence of literals that identifies the integration revision part
used in folder names in the artifact's path, excluding the base
revision

in case of an integration revision "1.2-SNAPSHOT" the
folder integration revision is "SNAPSHOT"

File
Integration
Revision

A sequence of literals that identifies the integration revision part in
the artifact's file name, excluding the base revision

in case of an integration revision "1.2-20110202.14453
3-3" the file integration revision is "20110202.144533-3"

Classifier

A sequence of literals that identifies the artifact's classifier

"sources"

Extension

A sequence of literals that identifies the artifact's extension

"zip"

Type

A sequence of literals that identifies the artifact's type.
Typically used when the artifact's extension cannot be reused as
the artifact's type

"java-source"

Using Module Fields to Define Path Patterns

Mandatory

A path pattern is used in the configuration of a Repository Layout.
The pattern is similar to that of the Ivy pattern and is used to define a convention for artifact resolution and publication paths.
Artifactory uses path patterns to construct module information for stored files. This module information is then used to facilitate all the features
mentioned above (version cleanup, cross-repo path conversions, etc.).
Path Pattern Tokens

A path pattern is constructed of tokens (explained below), path separators ('/'), optional parentheses ('(' and ')') and literals ('.', '-', etc.). Tokens
are modeled after module fields, as presented above.
Path patterns can be defined for every artifact in the repository or you can define a separate path patterns for descriptor-type artifacts (such as, a
.pom or an ivy.xml file).
The following tokens are available:

[org]

Represents the Organization field where the levels are separated by dots ('.'), a-la Ivy. For
example: "org.slf4j"

[orgPath]

Represents the Organization field where the levels are separated by path separators ('/'), a la
Maven. For example: "org/slf4j"
Represents the Base Revision field

[baseRev]

Represents the Module field
[module]

Represents the Folder Integration Revision field
[folderItegRev]

Represents the File Integration Revision field
[fileItegRev]

Represents the Classifier field
[classifier]

Represents the Extension field
[ext]

Represents the Type field
[type]

[customTokenName]

A custom token. Can be used to create a new type of token when the provided defaults are
insufficient.
For example, [myIntegRev] creates a new custom token named myIn
tegRev that matches the word ITEG followed by a dash and a minimum of one digit.

Custom tokens
When using custom tokens in the repository layout, make sure that the layout begins with [orgPath]/[module]. If the [module] token is
missing in the layout, some REST API calls will not work.

Multiple Custom Tokens
Artifactory supports any number of custom tokens, but when provided with multiple custom tokens of the same key, Artifactory only
takes into account the regular expression of the first occurrence while substituting the rest with a repetition expression (even if each
occurrence has a different regular expression value.
For example:

[custom1<.+>]/[custom1<.*>]/[custom1<[0-9]+>]

Translates to:

.+/\1/\1

Optional parts
To specify tokens or a sequence of tokens and literals as optional in the path pattern, surround the sequence with the optional
parentheses '(' and ')' literals.
For example, the pattern "[module](-[classifier])" matches both "bobs-tools-sources" and "bobs-tools", and the pattern
"[baseRev](-[fileItegRev])" matches both "1.2-SNAPSHOT" and "1.2".

Artifact Path Patterns

An artifact path pattern represents the typical structure that all module artifacts are expected to be stored in.
For example,
To represent a normal Maven artifact path: "org/eclipse/jetty/jetty-ajp/7.0.2.v20100331/jetty-ajp-7.0.2.v2010033
1.jar"
Use the artifact path pattern:

[orgPath]/[module]/[baseRev](-[folderItegRev])/[module]-[baseRev](-[f
ileItegRev])(-[classifier]).[ext]

To represent a default Ivy artifact path: "org.eclipse.jetty/jetty-ajp/7.0.2.v20100331/jars/jetty-ajp-7.0.2.v20100
331.jar"
Use the artifact path pattern:

[org]/[module]/[baseRev](-[folderItegRev])/[type]s/[module]-[baseRev]
(-[fileItegRev])(-[classifier]).[ext]

Descriptor Path Patterns

A descriptor path pattern is used to recognize descriptor files (like .pom or ivy.xml files).

Using a specific descriptor path pattern is optional. When not used, Artifactory constructs module information for
descriptor files using the artifact path pattern.
Even though descriptor paths patterns are optional, usage of them is highly recommended in cases of distinctive descriptors, such as Ivy ivy_1.0.xml and Maven bobs-tools-1.0.pom.
For example,
To represent a normal Maven descriptor path: "org/eclipse/jetty/jetty-ajp/7.0.2.v20100331/jetty-ajp-7.0.2.v20100
331.pom"
Use the descriptor path pattern:

[orgPath]/[module]/[baseRev](-[folderItegRev])/[module]-[baseRev](-[f
ileItegRev])(-[classifier]).pom

To represent a default Gradle descriptor path: "org.eclipse.jetty/jetty-ajp/ivy-7.0.2.v20100331.xml"
Use the descriptor path pattern:

[org]/[module]/ivy-[baseRev](-[fileItegRev]).xml

Configuration
Repository layouts are configured on the global level of your Artifactory instance, so that any layout can be shared and reused across any number
of repositories.

Layout Configuration
Layout configuration is available to administrator users in the Admin module under Repositories | Layouts.

Additional layouts can be created from scratch by clicking "New" or by duplicating an existing layout.

Testing Layouts

Once you have finished configuring your layout, you can test it on an artifact path, and see how Artifactory would build module information from
the path, using the layout definitions.
Path Patterns

These are used to define the artifact path pattern and the descriptor path pattern (optional), as explained above.
Use patterns in the directory part of the path
To achieve best path matching results, it is highly recommended that artifact and descriptor patterns also contain the mandatory tokens
([org] or [orgPath], [module] and [baseRev]) within the directory structure itself.
For example, Gradle's artifact path pattern:

[org]/[module]/[baseRev](-[folderItegRev])/[module]-[baseRev](-[file
ItegRev])(-[classifier]).[ext]

Regular Expressions for File and Folder Integration Revision

These fields should contain regular expressions that exactly match and describe the integration revision (excluding the base revision) formats as
they are expected in the artifact's file name and path-structure folder name.
Avoid using capturing group syntax in regexp
Regular expressions entered in these fields are wrapped and treated as a single capturing group.

Refrain from introducing any capturing groups within the expressions. Failure

to do so may result in unexpected behavior

and compromise the accuracy of the matcher.
Folder integration revision regular expression examples:
Maven's folder integration revision is simply the constant -SNAPSHOTappended to the base revision ("1.2-SNAPSHOT"), so the regular
expression is

SNAPSHOT

Ivy's default folder integration revision is usually equal to the file integration revision and is normally a 14 digit timestamp
("5.1-20101202161531"), so the regular expression can be

\d{14}

File integration revision regular expression examples:
Maven's file integration revision can be either the -SNAPSHOTconstant ("1.2-SNAPSHOT") or a timestamp, where the date and time are
separated by a dot ('.'), with an addition of a dash ('-') and a build-number ("2.3-20110108.100922-2"), so the regular expression should
be able to fit them both

SNAPSHOT|(?:(?:\d{8}.\d{6})-(?:\d+))

Ivy's default file integration revision is is normally a 14 digit timestamp ("5.1-20101202161531") and usually equal to the folder integration
revision, so the regular expression may be the same as suggested in the file's example

\d{14}

Repository Configuration
Before custom layouts
Repositories created prior to the introduction of custom repository layouts are automatically configured with the default Maven 2 layout.

Local Repository Configuration

Layouts are mandatory for local repositories, since they define the structure with which artifact are stored.

When you create a new repository, Artifactory will recommend the best layout according to the Package Type selected for the repository.

Remote Repository Configuration

Layouts are mandatory only for the remote repository cache configuration, however, you can also specify the layout of the remote repository itself.
If the remote repository itself uses a different layout than the one chosen for the cache, all requests the to the remote target are translated from
the path of the cache layout to the path of the remote layout.

For example, the remote repository http://download.java.net/maven/1 stores its artifacts according to the
Maven 1 convention. You can configure the cache of this repository to use the Maven 2 layout, but set the Remote
Layout Mapping to Maven 1. This way, the repository cache handles Maven 2 requests and artifact storage, while
outgoing requests to the remote repository are translated to the Maven 1 convention.

Virtual Repository Configuration

You can also configure a layout for a virtual repository.

When configured, all resolution requests can be made according to the virtual repository layout. When trying to
resolve requests to the virtual repository Artifactory attempts to translate the request path to the layout of each
nested repository, according to the module information constructed from the virtual request.
In the following cases, the request path is not translated, and requests pass through to nested repositories with the original specified path:
Module information cannot be constructed
The virtual module information cannot be mapped to a nested repository (e.g., fields are missing on one of the sides)
The virtual repository or the nested repository are not configured with a layout

Repository Replication
Overview
Through the Replication Add-on in Artifactory Pro, Artifactory allows replication of repositories
between two Artifactory instances to support development by different teams distributed over
distant geographical sites. The benefits of replication are:
Ensuring developers all work with the same version of remote artifacts
Ensuring build artifacts are shared efficiently between the different development teams
Overcome connectivity issues such as network latency and stability when accessing
remote artifacts
Accessing specific versions of remote artifacts

Artifactory versions for replication
We strongly recommend that replication is only performed between servers running the

Page Contents
Overview
Push
Replication
Advant
ages
Multi-p
ush
Replica
tion
Pull Replication
Advant
ages
Scheduling and
Configuring Replication
Using the UI

same version of Artifactory Pro.
Two main methods of replication are supported:
Push replication
Both scheduled and event-based push replication are supported, and multi-push
replication is available with an Enterprise license
Pull replication
Both scheduled and event-based pull replication are supported; event-based pull requires
an Enterprise license.

Configu
ring
Push
Replica
tion
Adding
a push
replicati
on
target
Configu
ring
Pull
Replica
tion
Replicating with
REST API
Replication
Properties
Watch the Screencast

Push Replication
Push replication is used to synchronize Local Repositories, and is implemented by the Artifactory server on the near end invoking a
synchronization of artifacts to the far end.
There are two ways to invoke push replication:
Scheduled push: Pushes are scheduled asynchronously at regular intervals
Event-based push: Pushes occur in nearly in real-time since each create, copy, move or delete of an artifact is immediately
propagated to the far end.
Advantages

It is fast because it is asynchronous.
It minimizes the time that repositories are not synchronized.
It reduces traffic on the master node in case of a replication chain ("Server A" replicates to "Server B", "Server B" then replicates to
"Server C" etc.).

Avoid Replication Loops ("Cyclic Replication")
A replication loop occurs ("Cyclic" or "Bi-directional" replication) occurs when two
instances of Artifactory running on different servers are replicating content from one to
the other concurrently.
For example, "Server A" is configured to replicate its repositories to "Server B", while at
the same time, "Server B" is configured to replicate its repositories to "Server A".
Or "Server A" replicates to "Server B" which replicates to "Server C" which replicates
back to "Server A".

Replication loop to be strictly avoided

We strongly recommend avoiding cyclic replication since this can have disastrous effects
on your system causing loss of data, or conversely, exponential growth of disk-space
usage.

When to Use Push Replication
Event-based push replication is recommended when it is important for the repository at the far end to be updated in near-real-time
for any change (create, copy, move or delete of an artifact) in the repository at the near end.
Regular scheduled replications run on top of event-based replication to guarantee full copy consistency even in cases of server
downtime and network partitions.

Multi-push Replication

With an Enterprise license, Artifactory supports multi-push replication allowing you to replicate a local repository from a single source to
multiple enterprise target sites simultaneously.

Pull Replication
This provides a convenient way to proactively populate a remote cache, and is very useful when waiting for new artifacts to arrive on demand
(when first requested) is not desirable due to network latency.
There are two ways to invoke a pull replication:
Scheduled pull: Pull replication is invoked by a remote repository, and runs asynchronously according to a defined schedule to
synchronize repositories (local, remote or virtual) at regular intervals.
Event-based pull:

Pulls occur nearly in real-time since each create, copy, move or delete of an artifact is immediately propagated to the far end. As
soon as a file is uploaded it is replicated and immediately available to the target (pulling) instance without even having to wait for the
file upload to be completed at the source
Advantages

Many target servers can pull from the same source server efficiently implementing a one-to-many replication.
It is safer since each package only has one "hop".
It reduces traffic on target servers since they do not have to pass on artifacts in a replication chain.
When and when not to Use Pull Replication
Pull replication is recommended in the following cases:
When you need to replicate a repository to many targets.
When your source repository is located behind a proxy that prevents push replication (e.g. replicating a repository hosted
on Artifactory SaaS to a local repository at your site)
Pull replication cannot be used to replicate a remote resource that is not an Artifactory repository. Artifacts from third party
repositories can only be cached on-demand in the normal cache and proxy behavior of a remote repository.

Scheduling and Configuring Replication
Using the UI
Replication is configured via the user interface as a scheduled task. Local repositories can be configured for push replication, and remote
repositories can be configured for pull replication.
All replication messages are logged in the main Artifactory log file (artifactory.log).
The Replications column in your list of local repositories indicates if replication is configured for each repository in the list. If replication is
indeed configured for a repository, you can click the icon in the list to invoke it.

Configuring Push Replication

A push replication task for a Local Repository is configured in the Replication tab of the Edit Local Repository dialog.
First, in the Cron Expression field define the replication task schedule using a valid cron expression.
The Next Replication Time will indicate update accordingly.
Cron Expression VS Event Base Replication
Replication of this repository to all of its targets occurs simultaneously according to the Cron Expression you define.
The event base replication will attempt to replicate only the artifacts affected by the event while the Cron Expression will trigger a
sync of all artifacts in repository. This difference is important since in case one of the event sync has failed the next time the Cron
Expression will trigger a sync all changed will be synced.
Once you have configured the replication properties for each of your replication targets, the Replication tab for your repository displays them.

Field Name

Description
The replication targets you have defined

Push to

When set, enables replication of this repository to the target specified in Push to
Enabled

Enable Event
Replication

When set, each event will trigger replication of the artifacts changed in this event. This can be any type of event on
artifact, e.g. add, deleted or property change.

Number of replication targets
If you do not have an Enterprise license, you may only define one replication target. With an Enterprise license, Artifactory supports
multi-push replication and you may define as many targets as you need.

Adding a push replication target

To add a target site for this replication, click Add to display the Replication Properties dialog, and fill in the details as follows.

Field
Name

Enable
Active
Replication
of this
Repository

URL

Description

When set, this replication will be
enabled when saved

The URL of the target local repository
on a remote Artifactory server.

The HTTP authentication username.
Username

The HTTP authentication password.
Password

Proxy

A proxy configuration to use when
communicating with the remote
instance.

Socket
Timeout

Sync
Deleted
Artifacts

Sync
Artifact
Properties

Sync
Artifact
Statistics

Path Prefix
(optional)

The network timeout in milliseconds to
use for remote operations.

When set, items that were deleted
locally should also be deleted remotely
(also applies to properties metadata).

When set, the task also synchronizes
the properties of replicated artifacts.

When set, the task also synchronizes
artifact download statistics. Set to
avoid inadvertent cleanup at the target
instance when setting up replication for
disaster recovery.
Only artifacts that located in path that
matches the subpath within the
repository will be replicated.

Configuring Pull Replication
A pull replication task for a Remote Repository is configured in the Replication tab of the Edit Remote Repository dialog.
First, in the Cron Expression field define the replication task schedule using a valid cron expression.
The Next Replication Time will indicate update accordingly.

Field
Name

Description

Enable
Active
Replication
of this
Repository

When set, this replication will be
enabled when saved

The URL of the target local repository
on a remote Artifactory server.

URL

For some package types, you need to
prefix the repository key in the URL
with api/. For a list of package
types where this is required, see the no
te below.

Sync
Deleted
Artifacts

Sync
Artifact
Properties

Path Prefix
(optional)

Enable
Event
Replication

When set, items that were deleted
locally should also be deleted remotely
(also applies to properties metadata).

When set, the task also synchronizes
the properties of replicated artifacts.

Only artifacts that located in path that
matches the subpath within the remote
repository will be replicated.
When set, each event will trigger
replication of the artifacts changed in
this event. This can be any type of
event on artifact, e.g. added, deleted or
property change.

Regarding credentials of the remote repository configuration
The remote repository's file listing for replication is retrieved using the repository's credentials defined under the repository's Advanc
ed configuration section.
The remote files retrieved depend on the effective permissions of the configured user on the remote repository (on the other
Artifactory instance).

* Check for which package formats you need to prefix the repository path with api/
For some packaging formats, when using the corresponding client to access a repository through Artifactory, the repository key in
the URL needs to be prefixed with api/ in the path. For example, in the case of Npm repositories, the repository key should
be prefixed with api/npm.
Nevertheless, there are exceptions to this rule. For example, when replicating Maven repositories, you do not need to add a prefix
the remote repository path.
The considerations of whether to prefix the repository key with api/ or not are the same as those when configuring smart
remote repositories. For a detailed list of package formats that should be prefixed with api/, please refer to Configuration und
er Smart Remote Repositories.

Replicating with REST API
Both Push and Pull Replication are supported by Artifactory's REST API. For details please refer to the following:
Get Repository Replication Configuration
Set Repository Replication Configuration
Update Repository Replication Configuration
Delete Repository Replication Configuration
Scheduled Replication Status
Pull/Push Replication

Replication Properties
Once replication has been invoked, Artifactory annotates the source repository being replicated and annotates it with properties that indicate
the status of the replication. These can be viewed, along with other properties that may annotate the repository, in the Properties tab of the T
ree Browser.
For single push replication operations, the following properties are created/updated:
Key

Value

artifactory.replication..started

Indicates when the replication started

artifactory.replication..status

Indicates the status of the replication operation once complete. It can take the following
values:
ok: The replication succeeded
failure: The replication failed. You should check the log files for errors

artifactory.replication..finishe
d

Indicates when the replication finished

For multi-push replication operations (available to Enterprise customers only), the following properties are created/updated:
Key

Value

artifactory.replication._.started

Indicates when the replication started

artifactory.replication._.status

Indicates the status of the replication operation once complete. It
can take the following values:
ok: The replication succeeded
failure: The replication failed. You should check the log files for
errors

artifactory.replication._.finished

Indicates when the replication finished

Watch the Screencast
To see replication in action, watch the short screencast below.

S3 Object Storage
Overview
Artifactory fully supports S3 object storage for distributed file systems so your Artifactory filestore can reside
on the cloud. This presents several benefits:
1. Unlimited scalability

1.
Since your files are now stored on the cloud, this means that your Artifactory filestore is scalable and
effectively unlimited (to the extent offered by your storage provider). You may freely continue to
upload files without having to install or maintain any file storage devices. You can even upload files
larger than 5 GB using multi-part upload.
2. Security
Enjoy the same security and authentication mechanisms provided by your S3 provider.
3. Disaster recovery
Since your files are replicated and stored with redundancy, this offers the capability for disaster
recovery.
4. Support any S3 compatible distributed file system
Arifactory's support is based on the S3 protocol. Any provider that uses S3, such as Ceph, Swift (thr
ough the S3 API) and others , will also be supported by Artifactory. With support for AWS S3 version
4, you can sign AWS requests using Signature Version 4.
Support for S3 object storage is included with an Artifactory Enterprise license.
Backup your system. Your current filestore will be deleted.
Setting up Artifactory to use S3 will delete all files in your current filestore.
If you already have a running installation of Artifactory, then before you setup Artifactory to use S3
and migrate your filestore to the cloud, we strongly recommend that you do a complete system
backup.

Page Contents
Overview
Setting up Artifactory
to Use S3
Setting Your
License
Configuring
Artifactory to
Use S3
Migrating Your
Filestore from
local/mounted
storage to S3
Auto
matic
Filest
ore
Migrat
ion
(Reco
mmen
ded)
Manu
al
Filest
ore
Migrat
ion

Setting up Artifactory to Use S3
First time installation or upgrade
If you are moving your filestore to S3 in the context of upgrading Artifactory, or a first time installation, we recommend that you first do a
standard installation of Artifactory using the default settings, or a standard upgrade using your current settings.
In order to move your Artifactory filestore to the cloud, you need to execute the following steps:

Shut down Artifactory.
Set your enterprise license
Configure Artifactory to use your S3 object storage provider
Migrate your files to the cloud manually or automatically
Start up Artifactory

Setting Your License
To use an S3 object store, your Artifactory installation needs to be activated with an Enterprise license.

Configuring Artifactory to Use S3
From version 4.6, Artifactory's filestore is configured through the binarystore.xml file. For details, please refer to Configuring the Filestore.

Migrating Your Filestore from local/mounted storage to S3
For an Artifactory HA cluster running version 5.0 and above, to migrate your filestore to an S3 provider, please refer to Migrating Data
from NFS Wiki page.
Standalone installations: there are two ways to migrate your filestore over to your S3 provider.
Automatically (recommended)
Manually
Automatic Filestore Migration (Recommended)

To make sure your filestore migration completes successfully without corrupting files, we recommend configuring Artifactory to do this migration
for you automatically:
To do so, you need to create the following links in $ARTIFACTORY_HOME/data/eventual/ (create it if the eventual folder does not exist - it
is created automatically when the eventual binary provider is applied via an Artifactory restart with an updated binarystore.xml):
A link with the name _add that points to the $ARTIFACTORY_HOME/data/filestore directory
A link with the name _pre that points to the $ARTIFACTORY_HOME/data/_pre directory
With this setting, as soon as Artifactory starts up, it will automatically move your complete filestore over to your S3 provider.
Your current filestore will be deleted
The process of moving your filestore to your S3 provider will delete your current filestore. We strongly recommend you do a complete
system backup before doing this migration.

Once the migration is complete, you may delete the _pre link and the $ARTIFACTORY_HOME/data/_pre directory

Manual Filestore Migration

To migrate your filestore manually, you need to execute the following steps:
Stop Artifactory
Copy the $ARTIFACTORY_HOME/data/filestore directory to your S3 object storage to the bucket name and path specified when
you configured Artifactory to use S3.
Start Artifactory

SAML SSO Integration
SAML (Security Assertion Markup Language)
SAML is an XML standard that allows you to exchange user authentication and authorization information
between web domains.
Artifactory offers a SAML-based Single Sign-On service allowing federated Artifactory partners (identity
providers) full control over the authorization process.
Using SAML, Artifactory acts as service provider which receives users' authentication information from

external identity providers.
In this case, Artifactory is no longer responsible for authentication of the user although it still has to redirect
the login request to the identity provider and verify the integrity of the identity provider’s response.
Page Contents
SAML (Security Assertion Markup Language)
Artifactory’s SAML configuration
Understanding Artifactory's SAML-based SSO Login Process
Understanding the Artifactory's SAML-based SSO Logout Process
Artifactory Profiles and Bindings
After SAML Setup
Login Failure
Using API Key with SAML Users

Artifactory’s SAML configuration
SAML SSO integration is configured in the Admin module under Secuirty | SAML SSO.

When checked, SAML integration is enabled and users may be authenticated via a SAML server.
Enable SAML
Integration

The SAML login URL.
SAML Login URL

The SAML logout URL.
SAML Logout URL

SAML Service Provider
Name

Auto Associate Groups

The SAML service provider name. This should be a URI that is also known as the entityID, providerID, or entity
identity. For more details, see section 8.3.6 of the SAML v2 specification.

When set, in addition to the groups the user is already associated with, he will also be associated with the groups
returned in the SAML login response.
Note that the user’s association with the returned groups is not persistent. It is only valid for the current login
session in the browser (i.e. this will not work for logins using the SAML user id and API Key).
Also, the association will not be reflected in the UIs Groups settings page. Instead, you can see this by enabling
this SAML logger in your $ARTIFACTORY_HOME/etc/logback.xml file as follows:

Group Attribute

The group attribute in the SAML login XML response. Note that Artifactory will search for a case-sensitive match to
an existing group.

Email Attribute

If Auto Create Artifactory Users is enabled or an internal user exists, Artifactory will set the user’s email to the
value in this attribute that is returned by the SAML login XML response.
The X.509 certificate that contains the public key.

SAML Certificate

Auto Create Artifactory
Users

Allow Created Users
Access To Profile Page

When checked, for new users accessing Artifactory in for the first time via SAML, Artifactory will create a user that
will persist in the data base.

When checked, users created after authenticating using SAML, will be able to access their profile. This means they
are able to generate their API Key and set their password for future use.

When checked, clicking on the login link will direct the users to the configured SAML login URL.
Auto Redirect Login
Link to SAML Login

To use SAML-based SSO in Artifactory:
1.
2.
3.
4.
5.

Login to Artifactory with administrator privileges.
In the Admin module, go to Security | SAML SSO.
Enable the SAML integration by checking the Enable SAML Integration checkbox.
Enable or disable “Auto Create Artifactory users” (Using SAML login). If enabled, new users will persist in the database.
Enable or disable "Allow Users Access to Profile Page". If enabled users will be able to access their profile without having to provide a
password.
6. Provide the SAML Login URL and SAML Logut URL
SAML Logout URL
In order to simultaneously logout from your SAML provider and Artifactory, you need to correctly set your provider's logout
URL SAML Logout URL field. Setting this incorrectly will keep your users logged in with the SAML provider even after logging
out from Artifactory.
7. Provide the service provider name (Artifactory name in SAML federation)
8. Provide the X.509 certificate that contains the public key. The public key can use either the DSA or RSA algorithms. Artifactory uses this
key to verify SAML response origin and integrity. Make sure to match the embedded public key in the X.509 certificate with the private
key used to sign the SAML response.
Custom URL base
For your SAML SSO settings to work, make sure you have your Custom URL Base configured.

Signed and encrypted Assertions
1. Please make sure your SAML IdP (Identity Provider) provides a signed login Assertion - this is mandatory for the Assertion
verification by Artifactory.
2. Encrypted Assertion is currently unsupported by Artifactory.
3. Signed Logout is also currently unsupported by Artifactory.

Understanding Artifactory's SAML-based SSO Login Process
1.
2.
3.
4.
5.
6.
7.
8.
9.

The user attempts to reach a hosted Artifactory, Home Page.
Artifactory generates a SAML authentication request.
The SAML request is encoded and embedded into the identity provider URL.
Artifactory sends a redirect to the user's browser. The redirect URL includes the encoded SAML authentication request that should be
submitted to the identity provider.
The identity provider decodes the SAML message and authenticates the user. The authentication process can proceed by asking for
valid login credentials or by checking for valid session cookies.
The identity provider generates a SAML response that contains the authenticated user's username. In accordance with the SAML 2.0
specification, this response is digitally signed with the identity provider’s private DSA/RSA keys.
The identity provider encodes the SAML response and returns that information to the user's browser. The identity provider redirects back
to Artifactory with the signed response.
Artifactory’s ACS verifies the SAML response using the partner's public key. If the response is successfully verified, the ACS redirects the
user to the destination URL.
The user has been redirected to the destination URL and is logged in to Artifactory.

Figure (2) Artifactory’s SAML-based SSO login process.

Understanding the Artifactory's SAML-based SSO Logout Process
1.
2.
3.
4.
5.

The user attempts to reach a hosted Artifactory logout link.
Artifactory logs the client out and generates a SAML logout request.
Artifactory redirects to the identity provider with the encoded SAML logout request.
The identity provider decodes the SAML message and logs the user out.
The user is redirected to the configured URL in the identity provider.

Figure (3) Artifactory’s SAML-based SSO logout process.

Artifactory Profiles and Bindings
Artifactory currently supports the Web Browser SSO and Single Logout Profiles.
The Web Browser SSO Profile uses HTTP redirect binding to send the AuthnRequest from the service provider to the identity provider, and
HTTP POST to send the authentication response from the identity provider to the service provider.
Similar to the previous profile, the Single Logout Profile uses HTTP redirect binding to send the LogoutRequest from the service provider to
the identity provider and HTTP POST to send the logout response from the identity provider to the service provider.
If your IDP supports uploading service provider metadata, you can use the following metadata XML:
Figure (4) Artifactory’s service provider metadata XML.

Artifactory SP metadata XML

urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

NOTE! that to use the service provider metadata:
Do not forget to update the following fields in the service provider metadata XML:
entityID - Artifactory’s ID in the federation. Must match SAML Service Provider Name in Artifactory's SAML configuration page.
Location - Artifactory's home URL

After SAML Setup
Using SAML, Artifactory automatically redirects the request to IDP which Authenticates the user and after a successful login redirects back to
Artifactory.
If "Anonymous User" is enabled, Artifactory doesn’t have to authenticate the user therefore it doesn’t redirect to the IDP. If the user still wants to
sign in through SAML, they can do so by clicking the "SSO login" link in the login page.

Login Failure
In case of IDP failover or bad configuration, Artifactory allows you to bypass SAML login by using Artifactory login page:
http:///webapp/#/login
This URL can be used by internal users who need to log in directly to Artifactory.

Using API Key with SAML Users
While SAML provides access to Artifactory UI, it is also possible for SAML users to generate an API key that can be used instead of a password
for basic authentication or in a dedicated REST API header, this is very useful when working with different clients, e.g. docker, npm, maven, etc.
or using Artifactory REST API.
In order to allow SAML users access to an API key you will need to make sure that the "Auto Create Artifactory Users" and "Allow Created

Users Access To Profile Page" check boxes are checked. This means that SAML users are also saved in Artifactory database and can access
their profile page in order to generate, retrieve and revoke their API key.

Single Sign-on
Overview
The Single Sign-on (SSO) add-on allows you to reuse existing HTTP-based SSO infrastructures with
Artifactory, such as the SSO modules offered by Apache HTTPd.
You can have Artifactory's authentication work with commonly available SSO solutions, such as native
NTLM, Kerberos etc.
SSO works by letting Artifactory know what trusted information it should look for in the HTTP request,
assuming this request has already been authenticated by the SSO infrastructure that sits in front of
Artifactory.
Page Contents
Overview
Usage
Integrating Apache and Tomcat
Setting Up a Reverse SSL Proxy for SSO
Components and Versions
Modifying Your Webserver Configuration File
Using API Key with HTTP-SSO Users

Usage
To access the Single Sign-On (SSO) add-on, in the Admin module, select Security | HTTP SSO.
To enable SSO you must alert Artifactory that it is running behind a secure HTTP server that forwards trusted requests to it.
Then you must tell Artifactory in which variable to look for trusted authentication information.
The default is to look for a REMOTE_USER header or the request variable, which is set by Apache's AJP and JK connectors.
You can choose to use any request attribute (as defined by the Servlet specification) by providing a different variable name.
Adding Your Own SSO Integration
You can write a simple servlet filter to integrate with custom security systems and set a request attribute on the request to be trusted by
the SSO add-on.
Finally, you can instruct Artifactory to treat externally authenticated users as temporary users, so that Artifactory does not create them in its
security database.
In this case, permissions for such users are based on the permissions given to auto-join groups.

Field Name

Artifactory is
Proxied by a Secure
HTTP Server

Description
When checked, Artifactory trusts incoming requests and reuses the remote user originally set on the request by the
SSO of the HTTP server.
This is extremely useful if you want to use existing enterprise SSO integrations, such as the powerful authentication
schemes provided by Apache (mod_auth_ldap, mod_auth_ntlm, mod_auth_kerb, etc.).
When Artifactory is deployed as a webapp on Tomcat behind Apache:
If using mod_proxy_ajp, make sure to set tomcatAuthentication="false" on the AJP connector.
If using mod_jk, make sure to use the "JkEnvVar REMOTE_USER" directive in Apache's configuration.
The name of the HTTP request variable to use for extracting the user identity. Default is: REMOTE_USER.

Remote User
Request Variable

Auto Create
Artifactory Users

When not checked, authenticated users are not automatically created inside Artifactory. Instead, for every request from
a SSO user, the user is temporarily associated with default groups (if such groups are defined) and the permissions for
these groups apply.
Without auto user creation, you must manually create the user inside Artifactory to manage user permissions not
attached to its default groups.

Allow Created
Users Access To
Profile Page

When checked, users created after authenticating using HTTP SSO, will be able to access their profile. This means
they are able to generate their API Key and set their password for future use.

Custom URL base
For your HTTP SSO settings to work, make sure you have your Custom URL Base configured.

Integrating Apache and Tomcat

When Artifactory is deployed as a webapp on Tomcat behind Apache:
If using mod_proxy_ajp - Make sure to set tomcatAuthentication="false" on the AJP connector.
If using mod_jk - Make sure to use the JkEnvVar REMOTE_USER directive in Apache's configuration.
If using mod_proxy (requires mod_proxy_http, mod_headers and mod_rewrite - There are two known working methods that forward
the header:

RequestHeader set REMOTE_USER %{REMOTE_USER}e

RewriteEngine On
RewriteCond %{REMOTE_USER} (.+)
RewriteRule . - [E=RU:%1]
RequestHeader set REMOTE_USER %{RU}e

Setting Up a Reverse SSL Proxy for SSO
You may set up a reverse SSL proxy on your webserver in order to run Artifactory supporting SSO.
To do this, you need to have the right components installed, modify your webserver configuration file, and then configure Artifactory for SSO.
When correctly set up,you should be able to login to Artifactory with your Windows credentials and stay logged in between sessions.

Components and Versions
The instructions below have been tested to work with Kerberos/NTLM SSO working with Artifactory using the following components.
IBM Websphere 8.5.5 running on Windows 8 using the IBM Websphere Java 7 JDK Package.
Artifactory v3.3.0.1 or later must be installed on the Websphere instance. For details please refer to Running Artifactory on IBM
WebSphere.
The mod_auth_sspi Apache module.

Modifying Your Webserver Configuration File
Once you have the right components and versions installed, you need to add the following lines to your [HTTP_SERVER_HOME]/conf/httpd.c
onf file:

httpd.conf file

ServerName yourhostname
DocumentRoot "C:/IBM/Installation
Manager/eclipse/plugins/org.apache.ant_1.8.3.v20120321-1730"
ProxyPreserveHost on
ProxyPass /artifactory http://yourhostname:9080/artifactory
ProxyPassReverse /artifactory http://yourhostname:9080/artifactory

AuthName "Artifactory Realm"
AuthType SSPI
SSPIAuth On
SSPIAuthoritative On
require valid-user
RewriteEngine On
RewriteCond %{REMOTE_USER} (.+)
RewriteRule . - [E=RU:%1]
RequestHeader set REMOTE_USER %{RU}e

Then you need to enable the following modules in your httpd.conf file:

Modules to enable
LoadModule
LoadModule
LoadModule
LoadModule
LoadModule
LoadModule

sspi_auth_module modules/mod_auth_sspi.so
headers_module modules/mod_headers.so
proxy_module modules/mod_proxy.so
proxy_connect_module modules/mod_proxy_connect.so
proxy_http_module modules/mod_proxy_http.so
rewrite_module modules/mod_rewrite.so

Using API Key with HTTP-SSO Users
While HTTP-SSO provides access to Artifactory UI, it is also possible for HTTP-SSO users to generate an API key that can be used instead of a
password for basic authentication or in a dedicated REST API header, this is very useful when working with different clients, e.g. docker, npm,
maven, etc. or using Artifactory REST API.
In order to allow HTTP-SSO users access to an API key you will need to make sure that the "Auto Create Artifactory Users" and "Allow
Created Users Access To Profile Page" check boxes are checked. This means that SSO users are also saved in Artifactory database and can
access their profile page in order to generate, retrieve and revoke their API key.

Smart Searches
Overview
Smart search is a feature that allows you to assemble a custom set of artifacts returned by a series of

separate searches actions. This is done by saving search results in a Stash.
The Stash provides easy access to artifacts found without having to run the series of searches again, and
also provides a convenient way to perform bulk operations on the result set using the Stash Browser.
Using the Stash you can save a search result, then use additional searches to add, remove and intersect
new results with the original result. Effectively, you are assembling a 'shopping cart' of artifacts, which you
can then manipulate as one unit.
For example, you can search for all artifacts deployed by a certain build (by build number), remove all the
sources from the search results (by running another search) and promote the final result set to a public
repository. Or, you can search all POMs containing a specific license and move them to a repository of
approved artifacts, or attach an "approved" property to them.
Page Contents
Overview
Saving Search Results in the Stash
View
Clear
Actions
Stash Browser
From Staging to Promotion

Saving Search Results in the Stash
To save search results after running a search, click Stash Results. To save only a subset of the search results, first select the items you want to
save and then click Stash Results. If you don't select any items, the whole result set will be saved.

Once you have items stored in the stash, Artifactory displays the number of items stored and offers several actions you can perform.

This displays the Stash Browser showing all items currently stored in the stash
View

Remove all items from the stash
Clear

Add: Adds to the stash items found in the current result set that are not already stored in the stash
Actions

Subtract: Items found in the current search result set, that are also in the stash, are subtracted (i.e. removed) from the
stash
Intersect: Items that are in the intersection of the current search results and the current stash contents are kept in the
stash. All other items are removed.

Stash Browser
The stash browser displays all items that are in the stash. You can browse through the items and view relevant information corresponding to the
item type just like you would in the Tree Browser.

If you select one of the items in the stashed search results tree, the specific information panel relevant to the selected item is displayed. The Acti
ons available are:
Delete the item.
Delete

Remove the item from the stash without deleting it.
Discard from Stash

Display the item in the Artifact Tree Browser.
Show in Tree

View the contents of the file
View

Download the artifact or folder
Download

If you are on the root Stashed Search Results item, you can perform bulk actions on all the contents of the stash at once.

Copy Stash to Repository

Copies the entire stash contents to a repository

Move Stash to Repository

Move the entire stash contents from their current location to a repository

Discard search results

Removes all items from the stash without deleting them.

On the root Stashed Search Results item you can also perform an export of the entire stash in the same way you would export a repository.
To go back to the Artifacts Tree Browser, click Back to Repository Browser.

From Staging to Promotion
For more detailed information about using Smart Searches for powerful, yet simple, promotion support please see this blog entry.

SSH Integration
Overview
From version 4.4, Artifactory supports SSH authentication for Git LFS and the JFrog CLI using RSA public
and private keys. This allows these tools to exchange sensitive information with the Artifactory server that is
authenticated via SSH.
There are two main facets of SSH authentication:
Server authenticates itself to the client
The server must be authenticated before you send it any confidential data. For example, you should not
authenticate a user to the server with the user's password before the server has been authenticated. The
server is authenticated in the following manner.
When the SSH connection is established, the server sends its public key to the client, and the client matches
the key to a list of known public keys stored in a known_hosts file. (Before the first ever connection to the
server, you must obtain the server's public key by some other means and add it it to the known_hosts file
manually). This verifies that the server is indeed the owner of the stored public key, since only that server will
have the corresponding private key. It also verifies that the server is known (and not an imposter) since its
public key is stored in the known_hosts file.
User authenticates itself to the server
This process mirrors the process of the server being authenticated to the client. The user must first provide
his public key to the server which stores it in the user's account authorization list. Then, when the user tries to
log in, the server sends the user back his public key, and the user must show that he holds the corresponding
private key.
Limitation
SSH is not supported if using Artifactory Saas cloud service.

Page Contents
Overview
Configuring SSH
Configuring Server Authentication
Configuring User Authentication

Configuring the Client

Configuring SSH
To configure SSH authentication, you need to execute the following main steps:
1. Configure Server Authentication
2. Configure User Authentication
3. Configure the Git LFS or CLI Client

Configuring Server Authentication
In this step you will configure Artifactory's SSH authentication parameters. First you need to generate an SSH key pair for Artifactory. For
example, on a Linux-based system, you could execute the following command:

ssh-keygen -t rsa -C "server@domain.com"

Then, to configure Artifactory for SSH authentication, in the Admin module, select Security | SSH Server and fill in the required fields.

When checked, SSH authentication is enabled
Enable SSH
Authentication

The port that should be used for an SSH connection
Port

Custom URL
Base

The Custom URL Base that should be used for SSH connections. Note that this is the same Custom URL Base configured
in the Admin module under Configuration | General.

The key pair used for authentication
Public
key/Private key

Configuring User Authentication
In this step, you will configure Artifactory with your public key so that you may be authenticated when sending requests to Artifactory from the Git
LFS client or from the Artifactory CLI.
First, you need to generate a key pair. For example, on a Linux-based system, you could execute the following command:

ssh-keygen -t rsa -C "USER@domain.com"

Your public and private keys should be created under the ~/.ssh folder.
Don't forget to update your public key
Update your public key under the SSH section of your User Profile.

Configuring the Client
To configure your Git LFS client, please refer to Authenticating with SSH.
To configure the JFrog CLI, please refer to Authenticating with RSA Keys.

User Plugins
About Plugins
Artifactory Pro allows you to easily extend Artifactory's behavior with your own plugins written in Groovy.
User plugins are used for running user's code in Artifactory. Plugins allow you to perform the following tasks:
Add scheduled tasks
Extend Artifactory with your own security realms
Change resolution rules
Manipulate downloaded content
Respond to any storage events on items and properties
Deploy and query artifacts and metadata
Perform searches
Query security information
Invoke custom commands via REST
Execute custom promotion logic
Provide information and strategies for Artifactory's Build Servers Plugins.
During the development phase, you can change plugin source files and have your plugins redeployed

on-the-fly. You can even debug the plugin code using your favorite IDE.
Groovy Version
Groovy 2.4 is supported

Page Contents
About Plugins
Deploying Plugins
Reloading Plugins
Auto Reload
Reloading Plugins via REST API
Plugins Lib Directory
Removing Plugins
Retrieving Plugin Source Code
Writing Plugins
The Artifactory Public API (PAPI)
Globally Bound Variables
Plugin Execution Points
Execution Context
Including AQL Queries
Plugin Template Source
General Info
Download
Storage
Jobs
Executions
Realms
Build
Promotions
Staging
Replication
Controlling Plugin Log Level
Sample Plugin

Deploying Plugins
Place your plugin files under ${ARTIFACTORY_HOME}/etc/plugins.
Artifactory HA Plugins Directory
If you are working with a High Availability cluster your user plugins should be added to the primary node under:
${ARTIFACTORY_HOME}/etc/plugins
And they will be propagated to the entire cluster.
Any file name ending with .groovy is loaded on startup. You can have multiple plugin files which are loaded in alphabetical order. Callbacks
defined in plugins are called by the order they were loaded.

Reloading Plugins
By default, plugins are not reloaded after Artifactory has started-up. You can configure Artifactory to automatically detect plugin changes on disk
or new plugin files and automatically reload them in runtime (plugin removals are not detected), or reload plugins using the REST API.
Auto Reload

To automatically reload plugins that have changed, set the number of seconds to check for plugin updates to a number greater than 0, by
changing the following property in ${ARTIFACTORY_HOME}/etc/artifactory.system.properties, or by specifying the property with -D
to the JVM running Artifactory:

artifactory.plugin.scripts.refreshIntervalSecs=0

NOTE! that deleting or renaming plugin files while auto-reloading is active is not fully supported and requires an Artifactory restart.

Disabling Plugin Reloading for Production
Ensure plugin auto-reloading is disabled in a production environment.

Reloading Plugins via REST API

You can reload plugins using the Reload Plugins REST API endpoint.

Plugins Lib Directory
If your plugin requires any external dependencies, you can place them under the ${ARTIFACTORY_HOME}/etc/plugins/lib directory.

Removing Plugins
To remove a plugin, simply delete it from the ${ARTIFACTORY_HOME}/etc/plugins directory.
Removing Plugins from an Artifactory HA Cluster
To remove a plugin from a High Availability cluster you only need to delete the plugin file from the master node.
The deletion event is then propagated to all other nodes in the cluster and Artifactory will delete the respective file from each cluster
node automatically.

Retrieving Plugin Source Code
You can retrieve the Groovy source code of a user plugin using the Retrieve Plugin Code REST API endpoint

Writing Plugins
Artifactory plugins are written as Groovy scripts in regular files and have a simple DSL to wrap users code in closures inside well-known extension
points.
Scripts have a couple of helper objects that are globally bound (see the plugin script template).
Naming conventions
Note that Groovy scripts must follow the same naming conventions as those specified for Java.

The Artifactory Public API (PAPI)
Scripts have access to the full classpath of Artifactory, however, the only API supported for plugins is the
the artifactory-papi.jar.

Artifactory Public API, defined in

The artifactory-papi.jar can be found under WEB-INF/lib folder inside the artifactory.war.
Please see the Plugin Code Template and Sample Plugin below for more details.
IDE code completion
All major IDEs have good Groovy editing and debugging capabilities.
In order to make your developing experience complete, we provide support for our own DSL for IntelliJ IDEA. IntelliJ IDEA's Groovy
DSL script for Artifactory User Plugins can be found in our GitHub repo.
Eclipse DSLD file is also available courtesy of James Carnegie.

Globally Bound Variables
Variable Name

Variable Type

Comments

org.slf4j.Logger

Writes to Artifactory log
logger name is the name of the script file

org.artifactory.repo.Repositories

Allows queries and operations on repositories
and artifacts

org.artifactory.security.Security

Provides information about current security context,
(e.g. current user and her permissions)

org.artifactory.search.Searches

API for searching for artifacts and builds
Since 2.3.4

org.artifactory.build.Builds

Allows CRUD operations on builds
Since 2.6

log

repositories

security

searches

builds

Closure Variables
Note! Declaring your own closure variables using the Groovy 'def ' keyword is considered best practice. Avoiding the "def" keyword is
risky in terms of variable scoping, and will result in the variable being scoped globally, making it accessible from other closure
executions.

Plugins Repository
Enhancing Artifactory with user plugins is community-driven effort.
If you are looking to go beyond Artifactory's out-of-the-box functionality take a look at already contributed plugins on GitHub, you might
find what you are thinking about. If not, your contribution is very welcome!

Plugin Execution Points
The following table summarizes the available execution points. For more details about specific plugin look follow the section links.

Plugin Type

Code block name

When executed

Description

Download
Event
Callback (with
return values)

Event
Callback
(without
return value)

Storage

altResponse

On any download

Provide an alternative response, by setting a success/error status code value and an
optional error message or by setting new values for the inputStream and size context
variables (For succeeded resolutions).

altRemotePath

When reaching out to
remote repositories

Provides an alternative download path under the same remote repository, by setting a
new value to the path variable.

altRemoteContent

After fetching content
from remote
repositories

Provide an alternative download content, by setting new values for the inputStream
and size context variables.

afterDownloadError

After failing during
content fetching from
remote repositories

beforeRemoteDownload

Before fetching content
from remote
repositories

Handle before remote download events.

afterRemoteDownload

After fetching content
from remote
repositories

Handle after remote download events.

beforeDownload

On any download

Handle before download events.

afterDownload

On any download

Handle after download events

beforeDownloadRequest

On any download

Handle before download requset events, executed before Artifactory starts to handle
the original client request, useful for intercepting expirable resources (other than the
default ones like maven-metadata.xml).

Event
Callback
(without
return value)

before/after
Create, Delete,
Move, Copy,
PropertyCreate,
PropertyDelete

Before / After selected
storage operation

Handle events before and after Create, Delete, Move and Copy operations

any valid Groovy (Java)
literal as execution name

According to provided
interval/delay or cron e
xpression

Job runs are controlled by the provided interval or cron expression, which are
mutually exclusive. The actual code to run as part of the job should be part of the job's
closure.

any valid Groovy (Java)
literal as execution name

By REST call

External executions are invoked via REST requests.

any valid Groovy (Java)
literal as realm name with
nested blocks:

During user
authentication

Newly added realms are added before any built-in realms (Artifactory internal realm,
LDAP, Crowd etc.). User authentication will be attempted against these realms first,
by the order they are defined.

beforeSave

Before the build info is
saved in Artifactory

Handle before build info save events

afterSave

After the build info is
saved in Artifactory

Handle after build info save events

any valid Groovy (Java)
literal as promotion name

By REST call

Promotes integration (a.k.a. snapshot) build to be a release invoking any code
associated with it.

any valid Groovy (Java)
literal as staging strategy
name

During build server
driven staging build
configuration

The strategy provides the build server with the following information:

beforeFileReplication

Before file is replicated

Handle before file replication events. File replication can be skipped.

beforeDirectoryReplication

Before directory is
replicated

Handle before directory replication events. Directory replication can be skipped.

beforeDeleteReplication

Before file/directory is
deleted

Handle before file or directory are deleted.

beforePropertyReplication

Before properties are
replicated

Handle properties replication.

Jobs
Scheduled
execution
Executions
User-driven
execution
Realms
Event
Callback
(without
return value)

authenticate
userExists
Build
Event
Callback
(without
return value)
Promotions
User or build
server driven
execution
Staging
Strategy
build server
driven
execution

How the artifacts in the staged build should be versioned;
How the artifacts in the next integration build should be versioned;
Should the build server create a release branch/tag/stream in VCS and how it
should be called;
To which repository in Artifactory the built artifacts should be submitted.

Replication
Event
callback (with
return value)

Execution Context

The Download, Storage, Execution and Build plugin types are executed under the identity of the user request that triggered them.
It is possible to force a block of plugin code to execute under the "system" role, which is not bound to any authorization rules and
can therefore perform actions that are otherwise forbidden for the original user.
To run under the "system" role wrap your code with the asSystem closure:

... someCode ...
asSystem {
//This code runs as the system role
}
... someOtherCode ...

The Realm and Job plugin types already execute under the "system" role. This cannot be changed.

Including AQL Queries
User plugins may include AQL queries opening up the full set of search capabilities that AQL has to offer. AQL queries are implemented within the
Searches object as shown in the example below.

import org.artifactory.repo.RepoPathFactory
import org.artifactory.search.Searches
import org.artifactory.search.aql.AqlResult
executions {
gemPropsPopulator() {
def repoKey = "gem-local"
((Searches) searches).aql(
"items.find({" +
"\"repo\": \"" + repoKey + "\"," +
"\"\$or\":[" +
"{\"property.key\":{\"\$ne\":\"gem.name\"}}," +
"{\"property.key\":{\"\$ne\":\"gem.version\"}}" +
"]})" +
".include(\"path\", \"name\")") {
AqlResult result ->
result.each {
...
...
...
}
}
}
}

Plugin Template Source
General Info
General info....

/*
* Copyright (C) 2011 JFrog Ltd.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
/**
*
* Globally bound variables:
*
* log (org.slf4j.Logger)
* repositories (org.artifactory.repo.Repositories)
* security (org.artifactory.security.Security)
* searches (org.artifactory.search.Searches) [since: 2.3.4]
* builds (org.artifactory.build.Builds) [since 2.5.2]
*
* ctx (org.artifactory.spring.InternalArtifactoryContext) - NOT A
PUBLIC API - FOR INTERNAL USE ONLY!
*/

Download
Handling and manipulating "download" events...

download {
/**
* Provide an alternative response, by one of the following methods:
* (1) Setting a success/error status code value and an optional error
message.
* (2) Provide an alternative download content, by setting new values
for the inputStream and size context variables.
*
* Note that, unless specifically handled, checksum requests for
altered responses will return the checksum of the
* original resource, which may not match the checksum of the
alternate response.
*
* Will not be called if the response is already committed (e.g. a
previous error occurred).
* Currently called only for GET requests where the resource was

found.
*
* Context variables:
* status (int) - a response status code. Defaults to -1 (unset).
* message (java.lang.String) - a text message to return in the
response body, replacing the response content.
*
Defaults to null.
* inputStream (java.io.InputStream) - a new stream that provides the
response content. Defaults to null.
* size (long) - the size of the new content (helpful for clients
processing the response). Defaults to -1.
* headers (java.util.Map) - Map containing the extra
headers to override or add if not exists to the response.
*
* Usage example:
* headers = ["ExtraHeader":"SpecialHeader"]
*
*
*
* Closure parameters:
* request (org.artifactory.request.Request) - a read-only parameter
of the request.
* responseRepoPath (org.artifactory.repo.RepoPath) - a read-only
parameter of the response RepoPath (containing the
*
physical
repository the resource was found in).
*/
altResponse { request, responseRepoPath ->
}
/**
* Provides an alternative download path under the same remote
repository, by setting a new value to the path
* variable.
*
* Context variables:
* path (java.lang.String) - the new path value. Defaults to the
originalRepoPath's path.
*
* Closure parameters:
* repoPath (org.artifactory.repo.RepoPath) - a read-only parameter of
the original request RepoPath.
*/
altRemotePath { repoPath ->
}
/**
* Provide an alternative download content, by setting new values for
the inputStream and size context variables.
*
* Context variables:
* inputStream (java.io.InputStream) - a new stream that provides the
response content. Defaults to null.

* size (long) - the size of the new content (helpful for clients
processing the response). Defaults to -1.
*
* Closure parameters:
* repoPath (org.artifactory.repo.RepoPath) - a read-only parameter of
the original request RepoPath.
*/
altRemoteContent { repoPath ->
}
/**
* In case of resolution error provide an alternative response, by
setting a success/error status code value and an optional error message.
* Will not be called if the response is already committed (e.g. a
previous error occurred).
* As opposite to altResponse, called only for GET requests during
which error occurred (e.g. 404 - not found, or 409 - conflict).
*
* Context variables:
* status (int) - a response error status code (may be overridden in
the plugin).
* message (java.lang.String) - a response error message (may be
overridden in the plugin).
* inputStream (java.io.InputStream) - a new stream that provides the
response content. Defaults to null.
* size (long) - the size of the new content (helpful for clients
processing the response). Defaults to -1.
*
* Closure parameters:
* request (org.artifactory.request.Request) - a read-only parameter
of the request.
*/
afterDownloadError { request ->
}
/**
* Handle before remote download events.
*
* Context variables:
* headers (java.util.Map) - Map containing the extra
headers to insert into the remote server request
*
* Usage example:
* headers = ["ExtraHeader":"SpecialHeader"]
*
* Note: The following cannot be used as extra headers and Artifactory
will always override them:
* "X-Artifactory-Originated". "Origin-Artifactory", "Accept-Encoding"
*
* Closure parameters:
* request (org.artifactory.request.Request) - a read-only parameter
of the request. [since: 2.3.4]
* repoPath (org.artifactory.repo.RepoPath) - a read-only parameter of

the original request RepoPath.
*/
beforeRemoteDownload { request, repoPath ->
}
/**
* Handle after remote download events.
*
* Closure parameters:
* request (org.artifactory.request.Request) - a read-only parameter
of the request. [since: 2.3.4]
* repoPath (org.artifactory.repo.RepoPath) - a read-only parameter of
the original request RepoPath.
*/
afterRemoteDownload { request, repoPath ->
}
/**
* Handle before local download events.
*
* Closure parameters:
* request (org.artifactory.request.Request) - a read-only parameter
of the request.
* responseRepoPath (org.artifactory.repo.RepoPath) - a read-only
parameter of the response RepoPath (containing the
*
physical
repository the resource was found in).
*/
beforeDownload { request, responseRepoPath ->
}
/**
* Handle before any download events, at this point the request passed
all of Artifactory's filters (authentication etc) and is about to reach
the repositories.
*
* Context variables:
* expired (boolean) - Mark the requested resource as expired.
Defaults to false (unset).
*
An expired resource is one that it's (now() (last updated time)) time is higher than the repository retrieval cache
period milliseconds.
*
Setting this option to true should be treated
with caution, as it means both another database hit (for updating the
last updated time)
*
as well as network overhead since if the resource is expired,
a remote download will occur to re-download it to the cache.
*
A common implementation of this extension point is to check if
the resource comply with a certain pattern (for example: a *.json file)
*
AND the original request was to the remote repository (and not
directly to it's cache)
*
AND a certain amount of time has passed since the last expiry
check (to minimize DB hits).

*
See our public GitHub for an example here:
https://github.com/JFrogDev/artifactory-user-plugins/blob/master/downloa
d/beforeDownloadRequest/beforeDownloadRequest.groovy
*
* modifiedRepoPath (org.artifactory.repo.RepoPath)
*
Forces Artifactory to store the file at the specified
repository path in the remote cache.
*
See our public GitHub for an example here:
https://github.com/JFrogDev/artifactory-user-plugins/blob/master/downloa
d/modifyMD5File/ModifyMD5FileTest.groovy
* Closure parameters:
* request (org.artifactory.request.Request) - a read-only parameter
of the request.
* repoPath (org.artifactory.repo.RepoPath) - a read-only parameter
of the response RepoPath (containing the
*
physical
repository the resource was found in).
*/

beforeDownloadRequest { request, repoPath ->
}
}

Storage
Handling and manipulating "storage" events...
If you want to abort an action, you can do that in 'before' methods by throwing a runtime org.artifactory.exception.CancelException with an
error message and a proper http error code.

storage {
/**
* Handle before create events.
*
* Closure parameters:
* item (org.artifactory.fs.ItemInfo) - the original item being created.
*/
beforeCreate { item ->
}
/**
* Handle after create events.
*
* Closure parameters:
* item (org.artifactory.fs.ItemInfo) - the original item being created.
*/
afterCreate { item ->
}
/**
* Handle before delete events.
*
* Closure parameters:
* item (org.artifactory.fs.ItemInfo) - the original item being being
deleted.
*/
beforeDelete { item ->
}
/**
* Handle after delete events.
*
* Closure parameters:
* item (org.artifactory.fs.ItemInfo) - the original item deleted.
*/
afterDelete { item ->
}
/**

* Handle before move events.
*
* Closure parameters:
* item (org.artifactory.fs.ItemInfo) - the source item being moved.
* targetRepoPath (org.artifactory.repo.RepoPath) - the target repoPath
for the move.
*/
beforeMove { item, targetRepoPath, properties ->
}
/**
* Handle after move events.
*
* Closure parameters:
* item (org.artifactory.fs.ItemInfo) - the source item moved.
* targetRepoPath (org.artifactory.repo.RepoPath) - the target repoPath
for the move.
*/
afterMove { item, targetRepoPath, properties ->
}
/**
* Handle before copy events.
*
* Closure parameters:
* item (org.artifactory.fs.ItemInfo) - the source item being copied.
* targetRepoPath (org.artifactory.repo.RepoPath) - the target repoPath
for the copy.
*/
beforeCopy { item, targetRepoPath, properties ->
}
/**
* Handle after copy events.
*
* Closure parameters:
* item (org.artifactory.fs.ItemInfo) - the source item copied.
* targetRepoPath (org.artifactory.repo.RepoPath) - the target repoPath
for the copy.
*/
afterCopy { item, targetRepoPath, properties ->
}
/**
* Handle before property create events.
*
* Closure parameters:
* item (org.artifactory.fs.ItemInfo) - the item on which the property
is being set.
* name (java.lang.String) - the name of the property being set.
* values (java.lang.String[]) - A string array of values being assigned
to the property.

*/
beforePropertyCreate { item, name, values ->
}
/**
* Handle after property create events.
*
* Closure parameters:
* item (org.artifactory.fs.ItemInfo) - the item on which the property
has been set.
* name (java.lang.String) - the name of the property that has been set.
* values (java.lang.String[]) - A string array of values assigned to
the property.
*/
afterPropertyCreate { item, name, values ->
}
/**
* Handle before property delete events.
*
* Closure parameters:
* item (org.artifactory.fs.ItemInfo) - the item from which the property
is being deleted.
* name (java.lang.String) - the name of the property being deleted.
*/
beforePropertyDelete { item, name ->
}
/**
* Handle after property delete events.
*
* Closure parameters:
* item (org.artifactory.fs.ItemInfo) - the item from which the property
has been deleted.
* name (java.lang.String) - the name of the property that has been
deleted.
*/

afterPropertyDelete { item, name ->
}
}

Jobs
Defining scheduled jobs...

jobs {
/**
* A job definition.
* The first value is a unique name for the job.
* Job runs are controlled by the provided interval or cron
expression, which are mutually exclusive.
* The actual code to run as part of the job should be part of the
job's closure.
*
* Parameters:
* delay (long) - An initial delay in milliseconds before the job
starts running (not applicable for a cron job).
* interval (long) - An interval in milliseconds between job runs.
* cron (java.lang.String) - A valid cron expression used to schedule
job runs (see:
http://www.quartz-scheduler.org/docs/tutorial/TutorialLesson06.html)
*/
myJob(interval: 1000, delay: 100) {
}
mySecondJob(cron: "0/1 * * * * ?") {
}
}

Executions
Defining external executions...

curl -X GET -v -u admin:password
"http://localhost:8080/artifactory/api/plugins/execute/myExecution?param
s=msg=And+the+result+is:|no1=10|no2=15&async=0"

executions {
/**
* An execution definition.
* The first value is a unique name for the execution.
*
* Context variables:
* status (int) - a response status code. Defaults to -1 (unset). Not
applicable for an async execution.
* message (java.lang.String) - a text message to return in the
response body, replacing the response content.
*
Defaults to null. Not applicable for
an async execution.
*
* Plugin info annotation parameters:
* version (java.lang.String) - Closure version. Optional.
* description (java.lang.String) - Closure description. Optional.
* httpMethod (java.lang.String, values are GET|PUT|DELETE|POST) HTTP method this closure is going
*
to be invoked with. Optional (defaults to POST).
* params (java.util.Map) Closure default parameters. Optional.
* users (java.util.Set) - Users permitted to query
this plugin for information or invoke it.
* groups (java.util.Set) - Groups permitted to
query this plugin for information or invoke it.
*
* Closure parameters:
* params (java.util.Map) - An execution takes a read-only key-value
map that corresponds to the REST request
*
parameter 'params'. Each entry in the map contains an array of
values. This is the default closure parameter,
*
and so if not named it will be "it" in groovy.
* ResourceStreamHandle body - Enables you to access the full input
stream of the request body.
*
This will be considered only if the type ResourceStreamHandle is
declared in the closure.
*/
myExecution(version:version, description:description, httpMethod:
'GET', users:[], groups:[], params:[:]) { params ->
}
execWithBody(version:version, description:description, httpMethod:
'GET', users:[], groups:[], params:[:]) { params, ResourceStreamHandle
body ->
}
}

Realms
Management of security realms...
Realms defined here are added before any built-in realms (Artifactory internal realm, LDAP, Crowd etc.). User authentication will be
attempted against these realms first, by the order they are defined.

realms {
/**
* A security realm definition.
* The first value is a unique name for the realm.
*
* Closure parameters:
* autoCreateUsers (boolean) - Whether to automatically create users
in Artifactory upon successful login. Defaults to
* true. When false, the user will be transient and his privileges
will be managed according to permissions defined for auto-join groups.
* realmPolicy (org.artifactory.security.RealmPolicy): (Optional) - If
included with value RealmPolicy.ADDITIVE, plugin will be executed only
if the user has previously been authenticated, and allows enrichment of
the authenticated
* user with additional data.
* See our public GitHub for an example here:
https://github.com/JFrogDev/artifactory-user-plugins/blob/master/securit
y/synchronizeLdapGroups/synchronizeLdapGroups.groovy
*/
myRealm(autoCreateUsers: true, realmPolicy: RealmPolicy.ADDITIVE) {
/**
* Implementation should return true/false as the result of the
authentication.
*
* Context variables:
* groups (java.lang.String[]) - An array of groups that the
authenticated user should be associated with (since 3.0.2).
* user (org.artifactory.security.User) - The authenticated user.
*
* Closure parameters:
* username (java.lang.String) - The username
* credentials (java.lang.String) - The password
*/
authenticate { username, credentials ->
}
/**
* Implementation should return true if the user is found in the
realm.
* Closure parameters:
* username (java.lang.String) - The username
*/
userExists { username ->
}
}
}

Build

Handling "Build Info" events...

build {
/**
* Handle before build info save events
*
* Closure parameters:
* buildRun (org.artifactory.build.DetailedBuildRun) - Build Info
model to be saved. Partially mutable.
*/
beforeSave { buildRun ->
}
/**
* Handle after build info save events
*
* Closure parameters:
* buildRun (org.artifactory.build.DetailedBuildRun) - Build Info that
was saved. Partially mutable.
*/
afterSave { buildRun ->
}
}

Promotions
Defining REST executable build promotion operations...

promotions {
/**
* A REST executable build promotion definition.
*
* Context variables:
* status (int) - a response status code. Defaults to -1 (unset).
* message (java.lang.String) - a text message to return in the
response body, replacing the response content. Defaults to null.
*
* Plugin info annotation parameters:
* version (java.lang.String) - Closure version. Optional.
* description (java.lang.String - Closure description. Optional.
* params (java.util.Map) Closure parameters. Optional.
* users (java.util.Set) - Users permitted to query
this plugin for information or invoke it.
* groups (java.util.Set) - Groups permitted to
query this plugin for information or invoke it.
*
* Closure parameters:
* buildName (java.lang.String) - The build name specified in the REST
request.
* buildNumber (java.lang.String) - The build number specified in the
REST request.
* params (java.util.Map>) - The parameters specified in the
REST request.
*/
promotionName(version, description, users, groups, params) {
buildName, buildNumber, params ->
}
}

Staging
Defining REST retrievable build staging strategy construction...

/**
* Set of staging strategy definitions to be used by the build server
during staging process.
* The strategy provides the build server with the following
information:
* 1. How the artifacts in the staged build should be versioned;
* 2. How the artifacts in the next integration build should be
versioned;
* 3. Should the build server create a release branch/tag/stream in VCS
and how it should be called;
* 4. To which repository in Artifactory the built artifacts should be
submitted.
*
* This user plugin is called by the build server using REST call.
*/
staging {
/**
* A build staging strategy definition.
*
* Closure delegate:
* org.artifactory.build.staging.BuildStagingStrategy - The strategy
that's to be returned.
*
* Plugin info annotation parameters:
* version (java.lang.String) - Closure version. Optional.
* description (java.lang.String - Closure description. Optional.
* params (java.util.Map) - Closure
parameters. Optional.
* users (java.util.Set) - Users permitted to query
this plugin for information or invoke it.
* groups (java.util.Set) - Groups permitted to query
this plugin for information or invoke it.
*
* Closure parameters:
* buildName (java.lang.String) - The build name specified in the REST
request.
* params (java.util.Map>) - The parameters specified in the
REST request.
*/
strategyName(version, description, users, groups, params) { buildName,
params ->
}
}

Replication
Handling and filtering replication events (since version 3.0.4)...

replication {
/**

* Handle before file replication events.
*
* Context variables:
* skip (boolean) - whether to skip replication for the current
item. Defaults to false. Set to true to skip replication.
* targetInfo (org.artifactory.addon.replication.ReplicationTargetInfo)
- contains information about the replication target server
*
* Closure parameters:
* localRepoPath (org.artifactory.repo.RepoPath) - the repoPath of
the item on the local Artifactory server.
*/
beforeFileReplication { localRepoPath ->
}
/**
* Handle before directory replication events.
*
* Context variables:
* skip (boolean) - whether to skip replication for the current
item. Defaults to false. Set to true to skip replication.
* targetInfo (org.artifactory.addon.replication.ReplicationTargetInfo)
- contains information about the replication target server
*
* Closure parameters:
* localRepoPath (org.artifactory.repo.RepoPath) - the repoPath of
the item on the local Artifactory server.
*/
beforeDirectoryReplication { localRepoPath ->
}
/**
* Handle before delete replication events.
*
* Context variables:
* skip (boolean) - whether to skip replication for the current
item. Defaults to false. Set to true to skip replication.
* targetInfo (org.artifactory.addon.replication.ReplicationTargetInfo)
- contains information about the replication target server
*
* Closure parameters:
* localRepoPath (org.artifactory.repo.RepoPath) - the repoPath of
the item on the local Artifactory server.
*/
beforeDeleteReplication { localRepoPath ->
}
/**
* Handle before property replication events.
*
* Context variables:
* skip (boolean) - whether to skip replication for the current
item. Defaults to false. Set to true to skip replication.
* targetInfo (org.artifactory.addon.replication.ReplicationTargetInfo)
- contains information about the replication target server
*

* Closure parameters:
* localRepoPath (org.artifactory.repo.RepoPath) - the repoPath of
the item on the local Artifactory server.
*/
beforePropertyReplication { localRepoPath ->
}
/**
* Handle before statistics replication events.
*
* Context variables:
* skip (boolean) - whether to skip replication for the current
item. Defaults to false. Set to true to skip replication.
* targetInfo (org.artifactory.addon.replication.ReplicationTargetInfo)
- contains information about the replication target server
*
* Closure parameters:
* localRepoPath (org.artifactory.repo.RepoPath) - the repoPath of
the item on the local Artifactory server.
*/

beforeStatisticsReplication { localRepoPath ->
}
}

Controlling Plugin Log Level
The default log level for user plugins is "warn". To change a plugin log level, add the following to ${ARTIFACTORY_HOME}/etc/logback.xml:

The logger name is the name of the plugin file without the ".groovy" extension (in the example above the plugin file name is my-plugin.groov
y). The logging levels can be either error, warn, info, debug or trace.

Sample Plugin
Sample plugin is available to download.

Watches
Overview
The Watches feature allows you to monitor selected artifacts, folders or repositories for storage events (create/delete/modify) and receive detailed
email notifications on repository changes that are of interest to you.
You can add and remove Watches from the 'General' tab in the tree browser. Watches or folders intercept changes on all children. An admin can
view and manage watches via the 'Watches' tab in the tree browser.
Watch notifications are aggregated at around 1 minute intervals and sent in a single email message.

All notifications respect the read permissions of the watcher on the watched item(s).

WebStart and Jar Signing
Overview
Java Web Start is a technology developed by Sun Microsystems (now Oracle) to allow you to download and
run Java applications directly from your browser with one-click activation.
Java Web Start requires that any JAR downloaded is signed by the software vendor. To support this
requirement, Artifactory lets you manage a set of signing keys that are used to automatically sign JAR files
downloaded from a virtual repository.
For more information, please refer to the Oracle documentation for Java Web Start.

Managing Signing Keys
Signing keys are managed in the Admin module under Security | Signing Keys.
Debian Signing Key
Debian signing keys are also managed on this page, however these are not related to JAR signing.
For details, please refer to Debian Signing Keys.

Generating JAR Signing Keys

In order to sign JAR files, you first need to create a keystore, and generate and add key pairs to it. These can
be created with Oracle's keytool utility, that comes built into your Java Runtime Environment (JRE), by
executing the following command:

keytool -keystore -keypass
-storepass -alias
\
-genkeypair -dname "cn=, ou=,
o=, S=, c=" -validity

For details, please refer to the Oracle keytool - Key and Certificate Management Tool documentation.
Page Contents
Overview
Managing Signing Keys
Generating JAR Signing Keys
Setting Your Keystore and Keys
Removing a Key Pair
Configuring Virtual Repositories to Sign JARs

Setting Your Keystore and Keys
Before you can add a keystore, you must set the password that will be needed to make any later changes to the keystore. You will need this
password to remove or update the keystore.
Set the password and click "Create". This will unlock the rest of the keystore management fields.

Once your keystore password is set and you have created a keystore and a set of signing keys, you can add them to Artifactory.
First upload your keystore file under Add Key-Store and enter the keystore password. Click "Unlock"

Once your keystore is set in Artifactory you may add key pairs under Add Key-Pair.

Removing a Key Pair
To remove a key pair, simply select the key pair and click "Remove".

Configuring Virtual Repositories to Sign JARs
Once Artifactory has a keystore and key pairs, you can configure a virtual repository with the key pair you wish to use for JAR signing. This is
done in the Advanced settings of the virtual repository configuration screen.

Package Management
Overview
Artifactory Pro brings the universal nature of Artifactory to full force with advanced package management for
all major packaging formats in use today. As the only repository with a unique architecture that includes a
filestore layer and a separate database layer, Artifactory is the only repository manager that can natively

support current package formats as well as any new format that may arise from time to time. With a paradigm
of single-type-repositories, all repositories are assigned a type upon creation allowing efficient indexing to
allow any client or dependency manager to work directly with Artifactory transparently as its natural
repository.
Artifactory Pro currently supports the following package formats with new formats added regularly as the
need arises.

Bower

Boost your front end development by hosting your own Bower components and proxying
the Bower registry in Artifactory.

Chef

Enhance your capabilities for configuration management with Chef using all the benefits of
a repository manager.

CocoaPods

Speed up development with Xcode and CocoaPods with fully fledged CocoaPods
repositories.

Conan

Artifactory is the only secure, private repository for C/C++ packages with fine-grained
access control.
Host and provision Debian packages complete with GPG signatures.

Debian

Docker

Host your own secure private Docker registries and proxy external Docker registries such
as Docker Hub.
Optimize your workflow when working with large media files and other binary resources.

Git LFS

Maven

Artifactory is both a source for Maven artifacts needed for a build, and a target to deploy
artifacts generated in the build process.

npm

Host your own node.js packages, and proxy remote npm repositories like npmjs.org through
Artifactory.

NuGet

Host and proxy NuGet packages in Artifactory, and pull libraries from Artifactory into your
various Visual Studio .NET applications.

Opkg

Optimize your work with OpenWrt using Opkg repositories. Proxy the official OpenWrt
repository and cache remote .ipk files.

Proxy and host all your Eclipse plugins via an Artifactory P2 repository, allowing users to
have a single-access-point for all Eclipse updates.

PHP
Composer

Puppet

Provision Composer packages from Artifactory to the Composer command line tool, and
access Packagist and other remote Composer metadata repositories.

Configuration management meets repository management with Puppet repositories in
Artifactory.
Host and proxy PyPI distributions with full supportforpip.

PyPI

RPM

Distribute RPMs directly from your Artifactory server, acting as fully-featured YUM
repository.

RubyGems

Use Artifactory to host your own gems and proxy remote gem repositories like rubygems.or
g.

SBT

Resolve dependencies from and deploy build output to SBT repositories when running SBT
builds.
Securely host your Vagrant boxes in local repositories.

Vagrant

Consume source files packaged as binaries.
VCS

Page Contents
Overview

Read more
Bower Repositories
Chef Cookbook Repositories
CocoaPods Repositories
Conan Repositories
Debian Repositories
Docker Registry
Git LFS Repositories
Npm Registry
NuGet Repositories
Opkg Repositories
P2 Repositories
PHP Composer Repositories
Puppet Repositories
PyPI Repositories
RPM Repositories
RubyGems Repositories
SBT Repositories
Vagrant Repositories
VCS Repositories

Bower Repositories
Overview
Artifactory supports bower repositories on top its existing support for advanced artifact management.
Artifactory support for Bower provides:
1. The ability to provision Bower packages from Artifactory to the Bower command line tool from all
repository types.
2. Calculation of Metadata for Bower packages hosted in Artifactory's local repositories.
3. Access to remote Bower registries (such as http://bower.herokuapp.com) through Remote
Repositories which provide the usual proxy and caching functionality.
4. The ability to access multiple Bower registries from a single URL by aggregating them under a Virtua
l Repository.
5. Assign access privileges according to projects or development teams.

Configuration
Local Repositories
To enable calculation of Bower package metadata set Bower to be the Package Type when you create your
local Bower repository.

Page Contents
Overview
Configuration
Local
Repositories
Deplo
ying
Bowe
r
Packa
ges
Remote
Repositories
Virtual
Repositories
Adva
nced
Confi
gurati
on
Using the Bower
Command Line
Using Bower
Version 1.5
and above
Using Older
Versions of
Bower
Working with
Artifactory without
Anonymous Access
Cleaning Up the Local
Bower Cache
Automatically
Rewriting External
Dependencies
Rewriting
Workflow
Using the
Bower Shorth
and Resolver
Registering Bower
Packages
Viewing Individual
Bower Package
Information

Deploying Bower Packages

The Bower client does not provide a way to deploy packages and relies on a Git repository to host the Bower package code.
To deploy a Bower package into Artifactory, you need to use Artifactory's REST API or the Web UI.

A Bower package is a simple tar.gz file which contains your project code as well as a bower.json file describing the package name and
version.
Usually, you will use a custom Grunt/ Gulp task to pack your project into an archive file and deploy it to Artifactory.
Version property
Make sure to include a version property in your bower.json file. You can add the property manually or by using the bower
version command.

Remote Repositories
The public bower registry does not contain any actual binary packages; it is a simple key-value store pointing from a package name to its
equivalent Git repository.
Since most of the packages are hosted in GitHub, you will want to create a Remote Repository which serves as a caching proxy for github.com. If
necessary, you can do the same for bitbucket.org or any other remote repository you want to access.
Working with Bitbucket?
If your packages are hosted on Bitbucket (formerly Stash), you need to ensure that the Bitbucket Archive Plugin is installed on your
Bitbucket server.
Artifacts (such as tar.gz files) requested from a remote repository are cached on demand. You can remove downloaded artifacts from the remote
repository cache, however you can not manually deploy artifacts to a remote repository.
To define a remote repository to proxy github.com as well as the public Bower registry follow the steps below:
1. Create a new remote repository and set Bower to be its Package Type
2. Set the Repository Key value, and enter https://github.com in the URL field as displayed below

3. In the Bower Settings section, select GitHub as the Git Provider.
Finally, click "Save & Finish"

Bower Registry URL
Usually, you will point the Bower Registry URL field at the public registry as displayed above.
However, if you are using a private bower registry or a remote Artifactory instance, simply set the same URL as configured in URL field.

Bower have changed their regitry URL from the default configured in Artifactory. In order to resolve from the public registry, set the
Registry URL to https://registry.bower.io.

Virtual Repositories
A Virtual Repository defined in Artifactory aggregates packages from both local and remote repositories.
This allows you to access both locally hosted Bower packages and remote proxied Bower registries from a single URL defined for the virtual
repository.
To create a virtual Bower repository set Bower to be its Package Type, and select the underlying local and remote bower repositories to include
under the Repositories section.

Advanced Configuration

The fields under External Dependency Rewrite are connected to automatically rewriting external dependencies for Bower packages that need
them.

When checked, automatically rewriting external dependencies is enabled.
Enable
Dependency
Rewrite

The remote repository aggregated by this virtual repository in which the external dependency will be cached.
Remote
Repository For
Cache

Patterns
Whitelist

A white list of Ant-style path expressions that specify where external dependencies may be downloaded from. By default,
this is set to ** which means that dependencies may be downloaded from any external source.
For example, if you wish to limit external dependencies to only be downloaded from github.com, you should add **/git
hub.com/** (and remove the default ** expression).

Using the Bower Command Line
Bower repositories must be prefixed with api/bower in the path
When accessing a Bower repository through Artifactory, the repository URL must be prefixed with api/bower in the path. This applies to
all Bower commands including bower install and bower info.
For example, if you are using Artifactory standalone or as a local service, you would access your Bower repositories using the following
URL:
http://localhost:8081/artifactory/api/bower/
Or, if you are using Artifactory SaaS, the URL would be:
https://.jfrog.io//api/bower/

Artifactory has been updated to work seamlessly with the latest version of the Bower client from version 1.5, and also supports older versions of
Bower.
Older versions of Bower
If your version of Bower is below 1.5, please refer to Using Older Versions of Bower.

Using Bower Version 1.5 and above
In order to use Bower with Artifactory you need 2 components (npm packages):
1. bower-art-resolver - A custom, pluggable Bower resolver which is dedicated to integrate with Artifactory.
2. bower - Bower version 1.5.0 and above.
Once Bower is installed, add the Artifactory Bower resolver by editing your ~/.bowerrc configuration file

Adding a Pluggable Resolver
{
"resolvers": [
"bower-art-resolver"
]
}

Bower Documentation
For more information, please refer to the Bower documentation on Pluggable Resolvers.

Replace the default registry with a URL pointing to a Bower repository in Artifactory by editing your ~/.bowerrc configuration file (the example
below uses a repository with the key bower-repo):

Replacing the default registry
{
"registry": "http://localhost:8081/artifactory/api/bower/bower-repo"
}

Using the Bower Shorthand Resolver
If you want to configure the Bower Shorthand Resolver to work with Artifactory, please refer to Bower Shorthand Resolver below.

.bowerrc file location
Windows: %userprofile%\.bowerrc
Linux: ~/.bowerrc

We recommend referencing a Virtual Repository URL as a registry. This gives you the flexibility to reconfigure and aggregate other
external sources and local repositories of Bower packages you deployed.
Once the Bower command line tool is configured, every bower install command will fetch packages from the bower repository specified
above. For example:

$ bower install bootstrap
bower bootstrap#*
bower bootstrap#*
bower bootstrap#*
bower bootstrap#*

not-cached art://twbs/bootstrap#*
resolve art://twbs/bootstrap#*
extract archive.tar.gz
resolved art://twbs/bootstrap#e-tag:0b9cb774e1

Using Older Versions of Bower
Using Bower below version 1.5...
Version support
Older versions of Bower are only supported by Artifactory up to version 4.2.0.
In order to use Bower below version 1.5 with Artifactory you need 2 components (npm packages):
1. bower-art-resolver - A custom Bower resolver dedicated to integrate with Artifactory.
2. bower-art - A temporary custom Bower CLI with the pluggable resolvers mechanism currently in pending pull request.
The bower-art package is a peer dependency of bower-art-resolver. Therefore, both can be easily installed with:

npm install -g bower-art-resolver

Use bower-art instead of bower
While Artifactory support for Bower is in Beta, after installing the required components, you need to execute bower-art instead of
each bower command.
For example, use bower-art install instead of bower install

Updating Resolver
In order to update Artifactory resolver, please uninstall the "bower-art" npm package first, and then install the resolver. This step is
necessary because npm doesn`t update peer dependencies.

Once bower-art is installed, replace the default registry with a URL pointing to a Bower repository in Artifactory by editing your ~/.bowerr
c configuration file (the example below uses a repository with the key bower-repo):

Replacing the default registry
{
"registry": "http://localhost:8081/artifactory/api/bower/bower-repo"
}

.bowerrc file location
Windows: %userprofile%\.bowerrc
Linux: ~/.bowerrc

We recommend referencing a Virtual Repository URL as a registry. This gives you the flexibility to reconfigure and aggregate other
external sources and local repositories of Bower packages you deployed.
Once the Bower command line tool is configured, every bower-art install command will fetch packages from the bower repository
specified above. For example:

$ bower install bootstrap
bower bootstrap#*
not-cached art://twbs/bootstrap#*
bower bootstrap#*
resolve art://twbs/bootstrap#*
bower bootstrap#*
extract archive.tar.gz
bower bootstrap#*
resolved
art://twbs/bootstrap#e-tag:0b9cb774e1

Working with Artifactory without Anonymous Access
By default, Artifactory allows anonymous access to Bower repositories. This is defined under Security | General Configuration. For details
please refer to Allow Anonymous Access.
If you want to be able to trace how users interact with your repositories you need to uncheck the Allow Anonymous Access setting. This means
that users will be required to enter their username and password.
Unfortunately, the Bower command line tool does not support authentication and you will need to add your credentials to the URL of the bower
registry configured in ~/.bowerrc:

Replacing the default registry with credentials
{
"registry":
"http://admin:password@localhost:8081/artifactory/api/bower/bower-repo"
}

Use an encrypted password
Use an encrypted password instead of clear-text; see Centrally Secure Passwords.

Cleaning Up the Local Bower Cache
The Bower client saves caches of packages that were downloaded, as well as metadata responses.
We recommend removing the Bower caches (both packages and metadata responses) before using Artifactory for the first time. This is to ensure
that your caches only contain elements that are due to requests from Artifactory and not directly from http://bower.herokuapp.com.
To clear the bower cache use:

Clean Bower Cache
bower cache clean

Automatically Rewriting External Dependencies
Packages requested by the Bower client frequently use external dependencies as defined in the packages' bower.json file. These
dependencies may, in turn, need additional dependencies. Therefore, when download an Bower package, you may not have full visibility into the
full set of dependencies that your original package needs (whether directly or transitively). As a result, you are at risk of downloading malicious
dependencies from unknown external resources. To manage this risk, and maintain the best practice of consuming external packages through
Artifactory, you may specify a "safe" whitelist from which dependencies may be downloaded, cached in Artifactory and configure to rewrite the
dependencies so that the Bower client accesses dependencies through a virtual repository as follows:
Check Enable Dependency Rewrite in the Bower virtual repository advanced configuration.
Specify a whitelist patterns of external resources from which dependencies may be downloaded.
Specify the remote repository in which those dependencies should be cached.

It is preferable to configure a dedicated remote repository for that purpose so it is easier to maintain.
In the example below the external dependencies will be cached in "bower" remote repository and only package from https://github.com/jf
rogdev are allowed to be cached.

Rewriting Workflow
1. When downloading a Bower package, Artifactory analyzes the list of dependencies needed by the package.
2. If any of the dependencies are hosted on external resources (e.g. on github.com), and those resources are specified in the white list,
a. Artifactory will download the dependency from the external resource.
b. Artifactory will cache the dependency in the remote repository configured to cache the external dependency.
c. Artifactory will then modify the dependency's entry in the package's package.json file indicating its new location in the Artifactory
remote repository cache before returning it to the Bower client.
3. Consequently, every time the Bower client needs to access the dependency, it will be provisioned from its new location in the Artifactory
remote repository cache.

Using the Bower Shorthand Resolver
When running bower install on a bower.json file that is hosted on your local machine, you need to define a custom template in .bowerrc fi
le by adding the following line.

shorthand-resolver": "art://{{owner}}/{{package}}"

From version v4.11, for bower packages downloaded from remote repositories, Artifactory supports resolving dependencies that are specified
using the Bower shorthand resolver for dependencies hosted on GitHub. Use of the shorthand resolver is reflected in the Bower install output,
in the shorthand resolver dependencies, which are prefixed with $$$art-shorthand-resolver$$$. For example:

bower
mypackagetest#$$$art-shorthand-resolver$$$--mypackagetest-master
.tar.gz
not-cachedart:///mypackagetest#$$$art-shorthand-resolver$$$--mypackagetest-master.tar.gz
bower
mypackagetest#$$$art-shorthand-resolver$$$--mypackagetest-master
.tar.gz
resolveart:///mypackagetest#$$$art-shorthand-resolver$$$--mypackagetest-master.tar.gz
bower
mypackagetest#$$$art-shorthand-resolver$$$--mypackagetest-master
.tar.gz
resolvedart:///mypackagetest#$$$art-shorthand-resolver$$$--mypackagetest-master.tar.gz

Registering Bower Packages
From version 4.6, Artifactory is a Bower registry and lets you register bower packages through remote and virtual repositories. This means you
can retrieve bower packages directly from your private Git repositories.
When creating private remote repositories, the Registry URL is redundant and can be left as is.
For example, a private Stash server hosted at http://stash.mycompany.com:7990 with a project named "artifactory" will be registered as follows:

bower register artifactory
ssh://git@stash.mycompany.com:7999/artifactory/artifactory.git

Once the server is registered, to download a Bower package from the stash server and cache it in the remote Bower repository in Artifactory
(ready for access by users) you can simply run

bower install artifactory

Viewing Individual Bower Package Information
Artifactory lets you view selected metadata of a Bower package directly from the UI.
In the Artifacts tab, select Tree Browser and drill down to select the zip/tar.gz file you want to inspect. The metadata is displayed in the Bow
er Info tab.

Chef Cookbook Repositories
Overview
Artifactory supports Chef Cookbook repositories on top of its existing support for advanced artifact
management.
Artifactory support for Chef Cookbook provides:
1. The ability to provision Cookbook packages from Artifactory to the Knife and Berkshelf
command line tool from all repository types.
2. Calculation of metadata for Cookbook packages hosted in Artifactory local repositories.
3. Access to remote Cookbook repositories (in particular the Chef supermarket public
repository) through remote repositories which provide proxy and caching functionality.
4. The ability to access multiple Cookbook repositories from a single URL by aggregating
them under a Virtual Repository. This overcomes the limitation of the Knife client which

4.
can only access a single repository at a time.
5. Compatibility with the Knife command line tool to list, show and install Cookbooks.
Compatibility with the Berkshelf command line to resolve Cookbook dependencies.
6. The ability to assign access privileges according to projects or development teams.
Chef Repository
Chef uses the concept of a Chef repository, to represent storing their own data objects
on a workstation. This is different from the use of "repository" in Artifactory.
Chef provides an official "supermarket" for cookbook packages, so Chef repositories in
Artifactory are actually Chef supermarkets in Chef terminology. This page refers to Chef
Cookbook repositories and Chef supermarkets interchangeably.

Page contents
Overview
Configuration
Local
Chef
Super
market
Reposi
tory
Layout
Remot
e Chef
Super
market
Virtual
Chef
Super
market
Using the Knife
Command Line
Working with
Artifactory
without
Anonymous
Access
Publishing
Cookbooks
Using
the Berkshelf
Command Line
Viewing
Individual Chef
Cookbook
Information
Searching Chef
Cookbooks

Configuration
Local Chef Supermarket
To enable calculation of Chef package metadata in local repositories so they are, in effect, Chef supermarkets, set the Package Type to Che
f when you create the repository:

Repository Layout
Artifactory allows you to define any layout for your Chef Cookbook repositories. In order to upload packages according to your custom layout,

you need to package your Chef Cookbook files with Knife or Berkshelf and archive the files as tar.gz. Then you can upload to any path within
your local Chef supermarket, see publishing Cookbooks.

Remote Chef Supermarket
A Remote Repository defined in Artifactory serves as a caching proxy for a supermarket managed at a remote URL such as https://supe
rmarket.chef.io.
Artifacts (such as tgz files) requested from a remote repository are cached on demand. You can remove downloaded artifacts from the
remote repository cache, however, you can not manually deploy artifacts to a remote Chef repository.
To define a remote repository to proxy a remote Chef Cookbook, repository follow the steps below:
1. In the Admin module, under Repositories | Remote, click "New".
2. In the New Repository dialog, set the Package Type to Chef, set the Repository Key value, and specify the URL to the remote
repository in the URL field as displayed below.

3. Click "Save & FInish".

Virtual Chef Supermarket
A Virtual Repository defined in Artifactory aggregates packages from both local and remote repositories.
This allows you to access both locally hosted Chef Cookbook packages and remote proxied Chef Cookbook repositories from a single URL
defined for the virtual repository.
To define a virtual Chef Cookbook repository, create a virtual repository, set the Package Type to be Chef, and select the underlying local
and remote Chef repositories to include in the Basic settings tab.

Using the Knife Command Line
Chef repositories must be prefixed with api/chef in the path
When accessing a Chef supermarket through Artifactory, the repository URL must be prefixed with api/chef in the path. This
applies to all Knife commands.
For example, if you are using Artifactory standalone or as a local service, you would access your Chef supermarket using the
following URL:
http://localhost:8081/artifactory/api/chef/
Or, if you are using Artifactory SaaS the URL would be:
https://.jfrog.io//api/chef/

To use the Knife command line you need to make sure it's installed. It's part of ChefDK, that can be installed in various ways.
Once you have created your Chef supermarket, you can select it in the Tree Browser and click Set Me Up to get code snippets you can use
to change your Chef supermarket URL, and deploy and resolve packages using the knife command line tool.

Set the default Chef supermarket with a URL pointing to a Chef supermarket in Artifactory by editing your ~/.chef/knife.rb configuration
file (the example below uses a repository with the key chef-virtual):

Setting the default Chef supermarket for Knife
knife[:supermarket_site] =
'http://localhost:8081/artifactory/api/chef/chef-virtual'

knife.rb file location
The knife.rb file doesn't exist by default. It can be created with the knife configure command. Refer to the knife documentation
for possible knife.rb locations.
The location of this file can be overidden with the --config parameter when running a knife command

Working with Artifactory without Anonymous Access
By default, Artifactory allows Anonymous Access for Chef repositories. This is defined under Security | General Configuration. For details
please refer to Allow Anonymous Access.
If you want to be able to trace how users interact with your repositories you need to uncheck the Allow Anonymous Access setting. This
means that users will be required to enter their username and password.
The Knife command line tool does not support basic authentication (it only supports authentication with RSA keys).
To enable basic authentication, you will need to install the knife-art.gem plugin.

Install knife-art plugin
chef gem install knife-art

If properly installed you should see the following specific Artifactory commands:

Knife Artifactory plugin commands
** ARTIFACTORY COMMANDS **
knife artifactory download COOKBOOK [VERSION] (options)
knife artifactory install COOKBOOK [VERSION] (options)
knife artifactory list (options)
knife artifactory search QUERY (options)
knife artifactory share COOKBOOK [CATEGORY] (options)
knife artifactory show COOKBOOK [VERSION] (options)
knife artifactory unshare COOKBOOK VERSION

These commands are a wrapper around the standard Knife supermarket commands, that enable basic authentication. To add these
credentials, pre-pend them to the URL of the Chef supermarket configured in your knife.rb file:

Setting the default Chef supermarket for Knife with credentials
knife[:supermarket_site] =
'http://admin:password@localhost:8081/artifactory/api/chef/chef-virtual'

Use an encrypted password
Use an encrypted password instead of clear-text; see Centrally Secure Passwords.

Publishing Cookbooks
You can use the UI or a simple REST API call to upload the tgz/tar.gz containing the Cookbook to a Chef repository.
Artifactory will automatically extract the relevant information from the metadata.json to later serve the index and respond properly to client
calls. This metadata.json file is mandatory. If it does not exist in your cookbook, you can use a Knife command to generate it and then
publish it to Artifactory. For example:

Publishing a new Cookbook
$ chef generate cookbook myapp
$ knife artifactory share myapp tool

Using the Berkshelf Command Line
Currently, using Berkshelf with Artifactory only supports Anonymous access. A plugin to enable authenticated access with
Berkshelf will be provided in a forthcoming release of Artifactory.
Berkshelf is a dependency manager for Chef Cookbooks, and is a part of the ChefDK.
To resolve dependencies from a Chef supermarket in Artifactory, set the default supermarket in your Berksfile's Cookbook:

Setting the default Chef supermarket for Berkshelf
source 'http://localhost:8081/artifactory/api/chef/chef-virtual'

Then you can execute the berks command to download the required dependencies from Artifactory:

Resolving dependencies with Berkshelf
vagrant@default-ubuntu-1404:~/chef-zero/mycookbook$ berks
Resolving cookbook dependencies...
Fetching 'mycookbook' from source at .
Fetching cookbook index from
http://localhost:8081/artifactory/api/chef/chef-virtual...
Installing apt (5.0.0) from
http://localhost:8081/artifactory/api/chef/chef-virtual ([opscode]
http://localhost:8081/artifactory/api/chef/chef-virtual/api/v1)
Installing chef-apt-docker (1.0.0) from
http://localhost:8081/artifactory/api/chef/chef-virtual ([opscode]
http://localhost:8081/artifactory/api/chef/chef-virtual/api/v1)
Installing chef-yum-docker (1.0.1) from
http://localhost:8081/artifactory/api/chef/chef-virtual ([opscode]
http://localhost:8081/artifactory/api/chef/chef-virtual/api/v1)
Installing compat_resource (12.16.2) from
http://localhost:8081/artifactory/api/chef/chef-virtual ([opscode]
http://localhost:8081/artifactory/api/chef/chef-virtual/api/v1)
Using mycookbook (0.1.0) from source at .
Installing yum (4.1.0) from
http://localhost:8081/artifactory/api/chef/chef-virtual ([opscode]
http://localhost:8081/artifactory/api/chef/chef-virtual/api/v1)

Viewing Individual Chef Cookbook Information
Artifactory lets you view selected metadata of a Chef Cookbook directly from the UI.
In the Artifacts tab, select Tree Browser and drill down to select the tgz/tar.gz file you want to inspect. The metadata is displayed in the
Chef Info tab.

Searching Chef Cookbooks
Artifactory supports a variety of ways to search for artifacts.
Artifactory also supports knife search [search terms ...]:
For local repositories, it will look for the given terms in the name, description and maintainer fields.
For remote repositories, the search will be done on the local cache, then the search query will be forwarded to the external repository
and the results merged before returned to the client.
For virtual repositories, the search will be done on local repositories and then on remote repositories, the results merged before
returning to the client.

Properties
Artifactory annotates each deployed or cached Chef Cookbook package with at least 3 properties: chef.name, chef.version an
d chef.maintainer. If available, it will also add chef.dependencies, chef.platforms multi-valued properties.
You can use Property Search to search for Chef Cookbook according to their name, version, maintainer, dependencies or platforms
requirements.

CocoaPods Repositories
Overview
Artifactory supports CocoaPods repositories on top its existing support for advanced artifact management.

Artifactory support for CocoaPods provides:
1. The ability to provision CocoaPods packages from Artifactory to the pod command line tool from
local and remote repositories.
2. Calculation of Metadata for pods hosted in Artifactory's local repositories.
3. Access to remote CocoaPods Specs repositories (such as https://github.com/CocoaPods/Sp
ecs) through Remote Repositories which provide the usual proxy and caching functionality.
4. The ability to assign access privileges according to projects or development teams.
Page Contents
Overview
Configuration
Local
Repositories
Deplo
ying
Pods
Remote
Repositories
Using the Pod
Command Line
Using
cocoapods-art
Synchronizing
the
cocoapods-art
Plugin's
repositories
with Artifactory
Working with
Artifactory without
Anonymous Access
Cleaning Up the Local
Pod Cache
Watch the Screencast

Configuration
Local Repositories
To enable calculation of CocoaPods package metadata set CocoaPods to be the Package Type when you create your local
CocoaPods repository.

Deploying Pods

The CocoaPods client does not provide a way to deploy packages and mostly (though not only) relies on a Git repository to host the pod's code.
To deploy a pod into Artifactory, you need to use Artifactory's REST API or the Web UI.
A pod is a simple tar.gz file which contains your project code as well as a .podspec or .podspec.json file describing the package
metadata.

Pod filetypes
Although more extensions are supported by the client, the Artifactory CocoaPods local repositories currently only support pods that are
archived as tar.gz

Remote Repositories
The public CocoaPods Specs repo does not contain any actual binary packages; it is a git repository containing podspec.json files pointing
from a package name and version to its storage endpoint.
Since the majority of the packages are hosted on GitHub, you need to create a Remote Repository which serves as a caching proxy for github.co
m. If necessary, you can do the same for bitbucket.org or any other remote repository you want to access.
Working with Stash?
If your packages are hosted on Bitbucket (formerly Stash), you need to ensure that the Stash Archive Plugin is installed on your
Bitbucket server.
Artifacts (such as tar.gz files) requested from a remote repository are cached on demand. You can remove downloaded artifacts from the remote
repository cache, however you can not manually deploy artifacts to a remote repository.
To define a remote repository to proxy github.com as well as the public Specs repo follow the steps below:
1. Create a new remote repository and set CocoaPods to be its Package Type
2. Set the Repository Key value, and enter https://github.com in the URL field as displayed below

3. In the CocoaPods Settings section, select GitHub as the Git Provider, and leave the leave the default Registry URL (https://github.co
m/CocoaPods/Specs).
Finally, click "Save & Finish"

Specs Repo URL
Usually, you will point the Specs Repo URL field at the public Specs repo as displayed above.
However, if you are using a private Specs repo - set the URL to be the same as the the one configured in the URL field.
If the remote URL is an Artifactory instance you need to append it's url with /api/pods/ i.e.
http://art-prod.company.com/artifactory/api/pods/pods-local

Private Bitbucket server
Working with a private Bitbucket server? set the "Git Provider" to be Stash, and not Bitbucket. The public Bitbucket endpoint answers
some API calls that a private Bitbucket server doesn't, hence, it is important to set the Git Provider to be Stash when working with a
private Bitbucket server. In this case, the URL field should be the root of your Bitbucket server, and the Specs Repo URL should be the
full URL to the Specs repo in Bitbucket.

Using the Pod Command Line
CocoaPods repositories must be prefixed with api/pods in the path
When accessing a CocoaPods repository through Artifactory, the repository URL must be prefixed with api/pods in the path. This
applies to the pod repo-art add command.
For example, if you are using Artifactory standalone or as a local service, you would access your CocoaPods repositories using the
following URL:
http://localhost:8081/artifactory/api/pods/
Or, if you are using Artifactory SaaS, the URL would be:
https://.jfrog.io//api/pods/
Artifactory has been updated to work seamlessly with the latest version of the CocoaPods client from version 0.39.0

Using cocoapods-art
In order to use CocoaPods with Artifactory, you need the cocoapods-art plugin which presents Artifactory repositories as Specs repos and pod
sources.
You can download the cocoapods-art plugin as a Gem, and its sources can be found on GitHub.
To use Artifactory with CocoaPods, execute the following steps:
1. Install the cocoapods-art plugin:

gem install cocoapods-art

Using Hombrew?
We recommend installing both the CocoaPods client and the cocoapod-art plugin as gems. Installing with Homebrew may
cause issues with the CocoaPods hooks mechanism that the plugin relies on.
2. The next step is to add an Artifactory repository by using the pod 'repo-art add' command:

pod repo-art add
http://localhost:8081/artifactory/api/pods/

3. Once the repository is added, add the following in your Podfile:

Adding an Artifactory source in the Podfile
plugin 'cocoapods-art', :sources => [
''
]

Working without the Master repository?
If you have removed the CocoaPods Master repository from your system, due to a known issue with the CocoaPods stats plugin, you
need to add the following to your Podfile, or add the corresponding variable to your environment:
ENV['COCOAPODS_DISABLE_STATS'] = 'true'
For details, please refer to JFrog Jira
Where the local repo name is the name you gave the specs repo locally when adding it.
pod repo-art commands
The cocoapods-art plugin exposes most commands that are normally invoked with pod repo (i.e. add, update, list etc.). Use pod
repo-art instead of pod repo whenever dealing with Artifactory-backed Specs repositories.

CocoaPods local Specs repos location
~/.cocoapods/repos
Once the pod command line tool is configured, every pod install command will fetch pods from the CocoaPods repository specified above.

Synchronizing the cocoapods-art Plugin's repositories with Artifactory
As opposed to the cocoapods client's default behavior, the cocoapods-art plugin does not automatically update its index whenever you run client
commands (such as install). To keep your plugin's index synchronized with your CocoaPods repository, you need to update it by executing the
following command:

pod repo-art update

Working with Artifactory without Anonymous Access
By default, Artifactory allows anonymous access to CocoaPods repositories. This is defined under Security | General Configuration. For details
please refer to Allow Anonymous Access.
If you want to be able to trace how users interact with your repositories you need to uncheck the Allow Anonymous Access setting. This means
that users will be required to enter their username and password.
Unfortunately, the pod command line tool does not support authentication against http endpoints. The cocoapods-art plugin solves this by forcing
curl (which pod uses for all http requests) to use the .netrc file:

.netrc file example
machine art-prod.company.com
login admin
password password

Since Artifactory also supports basic authentication using your API key, you could use that instead of your password:

.netrc file using your API key
machine art-prod.company.com
login admin
password
AKCp2TfQM58F8FTkXo8qSJ8NymwJivmagefBqoJeEBQLSHCZusEH6Z2dmhS1siSxZTHoPPyUW

Use an encrypted password
We recommend using an encrypted password instead of clear-text. For details, please refer to Centrally Secure Passwords.

Cleaning Up the Local Pod Cache
The pod client saves caches of pods that were downloaded, as well as metadata.
We recommend removing the CocoaPods caches (both packages and metadata responses) before using Artifactory for the first time. This is to
ensure that your caches only contain elements that are due to requests from Artifactory and not directly from other Specs repos.
To clear the pod cache use:

Clean Pod Cache
pod cache clean

Watch the Screencast
Watch this short screencast to learn how easy it is to host RPMs in Artifactory.

Conan Repositories
Overview
Artifactory introduces advanced artifact management to the world of C/C++ through support for
local repositories that work directly with the Conan client to manage Conan packages and
dependencies. As a repository to which builds can be uploaded, and from which dependencies can
be downloaded, Artifactory offers many benefits to C/C++ developers using Conan:
1. Secure, private repositories for C/C++ packages with fine-grained access control
according to projects or development teams
2. Automatic layout and storage of C/C++ packages for all platforms configured in the Conan
client
3. The ability to provision C/C++ dependencies from Artifactory to the Conan command line
tool from local repositories.
4. Enterprise features such as high availability, repository replication for multi-site
development, different options for massively scalable storage
...and much more.
For more details on building Conan packages and working with the Conan client, please refer to
the Conan documentation.

Configuration
Local Repositories
To enable calculation of C/C++ package metadata, set Conan to be the Package Type when you
create your local repository.

Page Contents
Overview
Configuration
Local
Repositories
Using Conan with
Artifactory
Adding Your
Repository
Authenticating
the Conan
Client
Installing
Dependencies
Uploading
Packages
Viewing Individual
Conan Package
Information

Make sure to also select conan-default as the repository layout.

Using Conan with Artifactory
Once the Conan client is installed, you can access Conan repositories in Artifactory through its command line interface. You can only install
packages from or export packages to your Artifactory local Conan repository using the Conan client.
Local vs. Remote
Don't let Conan terminology confuse you. For the purposes of this integration, the Conan "Remote" is actually the Artifactory local
repository you have created for Conan packages.
Once you have created your Conan repository, select it in the Tree Browser and click Set Me Up, to see the code snippets you will need in
order to use your repository as a source to install packages and as a target for export.

In the sections below, is used to denote the logical name you set with which the Conan client can identify the Conan local

repository in Artifactory.

Adding Your Repository
To use your local repository with Conan, you first need to add it as a Conan "Remote" to the client as follows:

conan remote add http:///api/conan/

Where:
is the repository key.
Conan repositories must be prefixed with api/conan in the path
When accessing a Conan repository through Artifactory, the repository URL must be prefixed with api/conan in the path. This
applies to all Conan commands including conan install.
For example, if you are using Artifactory standalone or as a local service, you would access your Conan repositories using the
following URL:
http://localhost:8081/artifactory/api/conan/
Or, if you are using Artifactory SaaS, the URL would be:
https://.jfrog.io//api/conan/

Authenticating the Conan Client
To authenticate the Conan client to Artifactory you need to log in using:

conan user -p -r

Accessing Artifactory anonymously
If Artifactory is configured for anonymous access, you may skip authenticating the Conan client.

Installing Dependencies
To install dependencies from Artifactory as defined in your conanfile.txt file use:

conan install . -r

Uploading Packages
To upload packages to your Artifactory local Conan repository use:

conan upload -r --all

Where specifies your Conan recipe reference formatted /@/

Viewing Individual Conan Package Information
Artifactory lets you view selected metadata of a Conan package directly from the UI.
In the Artifacts tab, select Tree Browser and drill down to select the package file you want to inspect. The metadata is displayed in the Cona
n Info tab. The specific information displayed depends on the tree item you have selected. Selecting the root item of a package displays
details of the Conan recipe used to upload the package.

If you select one of the packages, you get detailed Conan Package info including Settings, Options and dependencies ("Requires")

Debian Repositories

Overview
From version 3.3, Artifactory supports Debian repositories whether they use the current Automatic

Debia

n architecture or the deprecated Trivial architecture. As a fully-fledged Debian
repository, Artifactory generates index files that are fully compliant with Debian
clients.
Artifactory support for Debian provides:
1. The ability to provision Debian packages from Artifactory to a Debian client from local and remote
repositories.
2. Calculation of Metadata for Debian packages hosted in Artiafctory's local repositories.
3. Access to remote Debian resources (such as us.archive.ubuntu.com) through Remote
Repositories which provide the usual proxy and caching functionality.
4. Providing GPG signatures that can be used by Debian clients to verify packages.
5. Complete management of GPG signatures using the Artifactory UI and the REST API.

Configuration
You can only deploy Debian packages to a local repository that has been created with the Debian Package
Type.
You can download packages from a local or a remote Debian repository.
Page Contents
Overview
Configuration
Local Repositories
Deploying a package using the UI
Deploying a package using Matrix Parameters
Setting the Target Path
Specifying multiple layouts
Artifact Metadata
Metadata Validation
Remote Repositories
Signing Debian Packages
Adding MD5 Checksum to the Packages file
Authenticated Access to Servers
Compression Formats
Acquiring Packages by Hash
REST API Support
Watch the Screencast

Local Repositories
To create

a new local repository that supports Debian, under the Basic settings, set the Package Type to be D

ebian.
If you are using Debian with a Trivial layout, in the Debian Settings section, set the Trivial Layout checkbox.

Deploying a package using the UI

To deploy a Debian package to Artifactory, in the Artifactory Repository Browser, click Deploy.
Select your Debian repository as the Target Repository, upload the file you want to deploy.

Check the Deploy as Debian Artifact checkbox and fill in the Distribution, Component and Architecture fields in the Debian Artifact section.
Notice that the Target Path is automatically updated to reflect your input.

Setting the target path manually? Be careful with spaces
We recommend using the fields in the Debian Artifact section to set your Target Path. Nevertheless, if you choose to specify the Targ
et Path manually, make sure you don't enter any superfluous spaces.
For example to upload package planckdb-08-2015.deb, and specify that its layout is from the trusty distribution, in the main compone
nt and the i386 architecture, you would enter:
pool/planckdb-08-2015.deb;deb.distribution=trusty;deb.component=main;deb.architecture=i386

You can also deploy Debian packages to Artifactory with an explicit URL using Matrix Parameters.
After you deploy the artifact, you need to wait about one minute for Artifactory to recalculate the repository index and display your
upload in the Repository Browser.
Once you have deployed your Debian package, and Artifactory has recalculated the repository index, your repository should be organized as
displayed below:

Deploying a package using Matrix Parameters

The URL is built similarly to the Target Path format as follows:

Deploying a package using Matrix Parameters
PUT
"http://$ARTIFACTORY_HOME/{debianRepoKey}/pool/{debianPackageName};deb.dis
tribution={distribution};deb.component={component};deb.architecture={archi
tecture}"

For example, to upload package libatk1.0_i386.deb, and specify that its layout is from the wheezy distribution, in the main component and the i3
86 architecture, you would enter:

Example
PUT
"http://localhost:8080/artifactory/debian-local/pool/libatk1.0_i386.deb;de
b.distribution=wheezy;deb.component=main;deb.architecture=i386"

Setting the Target Path

The Target Path needs to be entered in a strict and specific format that uses system properties to define where the artifact will be stored and its
specific layout as follows:

Target Path Format
[path];deb.distribution=[distribution];deb.component=[component];deb.archi
tecture=[architecture]

The repository path where the package should be stored.
path

Artifactory supports storing Debian packages anywhere within the repository. The examples on
this page show Debian packages stored under the pool folder in accordance with the Debian
convention.
The value to assign to the deb.distribution property used to specify the Debian package distribution
distribution

The value to assign to the deb.component property used to specify the Debian package component name
component

The value to assign to the deb.architecture property used to specify the Debian package architecture
architecture

Adding Architecture Independent Packages
Uploading a Debian package with deb.architecture=all will cause it to appear in the Packages index of all the other architectures
under the same Distribution and Component, as well as under a new index branch called binary-all which holds all Debian
packages that are marked as "all'.
Removing an "all" Debian package will also remove it from all other indexes under the same Distribution and Component.
When the last Debian package in an architecture is removed but the Packages index still contains an "all" Debian package, it is
preserved in the index.
If you want such an architecture index removed you may do so via the UI or using Calculate Debian Repository Metadata in the REST
API, which cleans up orphaned package files from the index.

Specifying multiple layouts

Whether uploading a package using the UI or Matrix Parameters, you can specify multiple layouts for any Debian package you upload, by
including additional values for the distribution, component or architecture separated by a comma,
For example, to upload package libatk1.0_i386.deb

to both wheezy and trusty distributions, in both main and contri
b components and both i386 and 64bit-arm architectures you would specify the following Target Path to
upload using the UI:
Target path for multiple layouts
pool/libatk1.0_i386.deb;deb.distribution=wheezy;deb.distribution=trusty;de
b.component=main;deb.component=contrib;deb.architecture=i386;deb.architect
ure=64bit-arm

Correspondingly, to upload the file using Matrix Parameters, you would use the following:

Multiple layouts using Matrix Parameters
PUT
"http://localhost:8080/artifactory/debian-local/pool/libatk1.0_i386.deb;de
b.distribution=wheezy;deb.distribution=trusty;deb.component=main;deb.compo
nent=contrib;deb.architecture=i386;deb.architecture=64bit-arm"

Artifact Metadata

From version 4.4, Artifactory writes several entries from the Debian package's metadata as properties on all of the artifacts (based on the control
file's content).
These properties can be used to search for Debian packages more efficiently using Arifactory's Package Search.
Metadata properties are written for each new Artifact that is deployed to Artifactory.

To have these properties written to Debian artifacts that already exist in your repositories you need to call the Calculate Debian Repository
Metadata REST API which writes the properties to all of the artifacts by default.
Metadata Validation

To ensure that Debian repositories are not corrupted by malformed packages, Artifactory first validates parts of the Debian metadata to make sure
that none of the relevant metadata fields are empty. If the validation process indicates a malformed package, Artifactory provides several
indications:
The package is not indexed
The package is annotated with the following property:
key: deb.index.status
value: the reason the package failed the validation process
If the package is selected in the Tree Browser, the Debian Info tab will display a message indicating that it was not indexed and why it
failed the validation process

A message is logged in the Artifactory log file indicating that the package was not indexed and why it failed the validation process.

Disable validation
Debian package validation is controlled by the debian.metadata.validation system property. Package validation is enabled by
default. To disable Debian package validation set:
debian.metadata.validation=false

Finding malformed packages
To easily find all malformed packages in your Debian repositories, you can use Property Search or run an AQL query with Properties
Criteria on the deb.index.status property described above.

Remote Repositories
You can download Debian packages from Local Debian Repositories as described above, or from Remote Repositories specified as supporting
Debian packages.
To specify that a Remote Repository supports Debian packages, you need to set its Package Type to Debian when it is created.

Note that the index files for remote Debian repositories (including the sources index) are stored and renewed according to the Retrieval Cache
Period setting.

Signing Debian Packages
Artifactory supports signing Debian packages using a GPG key. This process will create a signed Release file named Release.gpg that will be
shipped alongside the Release file. Artifactory will store and manage public and private keys that are used to sign and verify Debian packages.
To generate a pair of GPG keys and upload them to Artifactory, please refer to GPG Signing.

Adding MD5 Checksum to the Packages file
To support tools (e.g. Aptly) that require Debian packages to include their MD5 checksum in their Packages metadata file for validation, you can
configure Artifactory to add this value by setting the following system property in the artifactory.system.properties file:

## Add package MD5 checksum to Debian Packages file
#artifactory.debian.metadata.calculateMd5InPackagesFiles=true

Artifactory needs to be restarted for this change to take efffect.

Authenticated Access to Servers
If you need to access a secured Artifactory server that requires a username and password, you can specify these in your Debian source.list fi
le by prefixing the artifactory host name with the required credentials as follows:

Accessing Artifactory with credentials
http://user:password@$ARTIFACTORY_HOME/{repoKey} {distribution}
{components}
For example:
http://admin:password@localhost:8081/artifactory/debian-local wheezy main
restricted

Encrypting your password
You can use your encrypted password as described in Using Your Secure Password.

Compression Formats
Artifactory supports the following compression formats for Debian indices:

Gzip (.gz file extension)
Bzip2 (.bz2 file extension)

Acquiring Packages by Hash
From version 5.5.2, Artifactory supports the acquire-by-hash functionality of APT clients for Debian repositories laid out using the Automatic
architecture (Trivial architecture is not supported for acquiring packages by hash). This feature is supported by two system properties:
debian.use.acquire.byhash

[default: true]
When true, the value of acquire-by-hash in Debian release files is set to true allowing APT
clients to access Debian packages by their checksums (MD5, SHA1, SHA256). To allow this,
Artifactory will add the "by-hash" layout to all Debian repositories

debian.packages.byhash.history.cycles.to.Keep

[default: 3]
Specifies the number of cycles of package file history to save when acquire-by-hash is
enabled

REST API Support
The Artifactory REST API provides extensive support for Debian signing keys and recalculating the repository index as follows:
Set the public key
Get the public key
Set the private key
Set the pass phrase
Recalculate the index

Watch the Screencast

Docker Registry
Set up a secure private Docker registry in minutes to manage all your Docker images while exercising
fine-grained access control. Artifactory places no limitations and lets you set up any number of Docker
registries, through the use of local, remote and virtual Docker repositories, and works transparently with the
Docker client to manage all your Docker images, whether created internally or downloaded from remote
Docker resources such as Docker Hub.
Multiple Docker Registries
Artifactory lets you define as many Docker registries as you wish. This enables you to manage each project
in a distinct registry and exercise better access control to your Docker images.
Use Docker Naturally
Artifactory supports the relevant calls of the Docker Registry API so that you can transparently use the
Docker client to access images through Artifactory.
Secure private Docker Registry with Fine-grained Access Control
Local Docker repositories are where you store internal Docker images for distribution across your
organization. With the fine-grained access control provided by built-in security features, Artifactory offers
secure Docker push and pull with local Docker repositories as fully functional, secure, private Docker
registries.
Consistent and reliable access to remote images
Remote Docker repositories in Artifactory proxy external resources such as Docker Hub, or a remote Docker
repository in another Artifactory instance, and cache downloaded images. As a result, overall networking is
reduced, and access to images on these remote resources is faster, consistent and reliable.
Confidently Promoting Images to Production

Artifactory lets you promote Docker images, as immutable, stable binaries, through the quality gates all the
way to production.
Smart Search
Using Artifactory's Package Search, find your images in the most natural way for Docker using the image
name, tag or digest.
JFrog End-to-End Platform
Through Artifactory's tight integration with JFrog Bintray, you can manage your Docker images from
development, through your pipeline, all the way to distribution.

Registries and Repositories
Both Artifactory and Docker use the term "repository", but each uses it in a different way.
A Docker repository is a hosted collection of tagged images that, together, create the file system for a
container
A Docker registry is a host that stores Docker repositories
An Artifactory repository is a hosted collection of Docker repositories, effectively, a Docker registry in every
way, and one that you can access transparently with the Docker client.
Since Artifactory places no limitation on the number of repositories you may create, you can manage any
number of Docker registries in Artifactory.
Page Contents
Registries and
Repositories
Getting Started With
Artifactory as a Docker
Registry
Configuring Docker
Repositories
Local Docker
Repositories
Remote
Docker
Repositories
Dock
er
Repo
sitory
Path
and
Doma
in
Virtual Docker
Repositories
Reverse Proxy
Settings
Promoting Docker
Images
Pushing and Pulling
Images
Set Me Up
Browsing Docker
Repositories
Tag Info
Docker Tag
Visualization
Labels
Searching for Docker
Images
Listing Docker Images
Pushing Images to
Bintray
Deletion and Cleanup
Limiting
Unique Tags
Migrating from Docker

V1 to Docker V2
Support Matrix

Read More
Getting Started with
Artifactory as a Docker
Registry
Advanced Topics
Working with Docker
Content Trust
Using Docker V1

Getting Started With Artifactory as a Docker Registry
There are three main ways to get started using Docker with Artifactory:
1. Artifactory SaaS account
2. Using Docker Compose (1-minute setup)
3. Artifactory On-Prem
For more details, please refer to Getting Started with Artifactory as a Docker Registry.

Configuring Docker Repositories
Artifactory supports three types of repositories when working with Docker:
Local repositories are a place for your internal Docker images. Through Artifactory's security capabilities, these are secure private Docker
registries.
Remote repositories are used to proxy remote Docker resources such as Docker Hub.
Virtual repositories can aggregate multiple Docker registries thus enabling a single endpoint you can use for both pushing and pulling Docker
images. This enables the admin to manage the different Docker registries without his users knowing, and continue to work with the same end
point.
**Make sure to go to the Advanced tab of each repository and set the Registry Port if you are using the Port method for Docker. Then, the reverse
proxy generator should add a new section in for the specified port.

Local Docker Repositories
A local Docker repository is where you can deploy and host your internal Docker images. It is, in effect, a Docker registry able to host collections
of tagged Docker images which are your Docker Repositories. Once your images are hosted, you can exercise fine-grained access control, and
share them across your organization through replication or by being proxied by repositories in other Artifactory instances.
To define a local Docker repository, follow the steps below:
1. Create a new Local Repository and set Docker as the Package Type.
2. Set the Repository Key, and in the Docker Settings section, select V2 as the Docker API version.
3. Set Max Unique Tags. This specifies the maximum number of unique tags, per repository, that should be stored for a Docker image.
Once the number of tags for an image exceeds this number, older tags will be removed. Leaving the field blank (default) means all tags
will be stored.

Remote Docker Repositories
With Docker, you can proxy a remote Docker registry through remote repositories. A Remote Repository defined in Artifactory serves as a caching
proxy for a registry managed at a remote URL such as https://registry-1.docker.io/ (which is the Docker Hub), or even a Docker repository
managed at a remote site by another instance of Artifactory.
Docker images requested from a remote repository are cached on demand. You can remove downloaded images from the remote repository
cache, however, you can not manually push Docker images to a remote Docker repository.
To define a remote repository to proxy a remote Docker registry follow the steps below:
1. Create a new Remote Repository and set Docker as the Package Type.
2. Set the Repository Key value, and specify the URL to the remote registry in the URL field

If you are proxying the Docker Hub, use https://registry-1.docker.io/ as the URL, and make sure the Enable Token Authentication check
box is checked (these are the default settings).
Docker Repository Path and Domain

When accessing a remote Docker repository through Artifactory, the repository URL must be prefixed with api/docker in the path.
For Example:
http://my-remote-site:8081/artifactory/api/docker/

Virtual Docker Repositories
From version 4.1, Artifactory supports virtual Docker Repositories. A Virtual Repository defined in Artifactory aggregates images from both local
and remote repositories that are included in the virtual repositories.
This allows you to access images that are hosted locally on local Docker repositories, as well as remote images that are proxied by remote
Docker repositories, and access all of them from a single URL defined for the virtual repository. Using virtual repositories can be very useful since
users will continue to work with the virtual repository while the admin can manage the included repositories, replace the default deployment target
and those changes will be transparent to the users.
To define a virtual Docker repository follow the steps below:
1. Create a new Virtual Repository and set Docker as the Package Type.
2. Set the Repository Key value.
3. Select the underlying local and remote Docker repositories to include under the Repositories section.
4. You can optionally also configure your Default Deployment Repository. This is the repository to which Docker images uploaded to this
virtual repository will be routed, and once this is configured, your virtual Docker repository is a fully-fledged Docker registry. Using the
default deployment repository, you can set up your virtual repository to wrap a series of repositories that represent the stages of your
pipeline, and then promote images from the default deployment repository through the pipeline to production. Any repository that
represents a stage in your pipeline within this virtual repository can be configured with permissions for authenticated or unauthenticated
(anonymous) access according to your needs.

Reverse Proxy Settings
A reverse proxy is required for Docker. In case you are using the Artifactory Reverse Proxy configuration generator you can configure Docker
repository's reverse proxy settings under the Advanced settings tab.
For details, please refer to Docker Reverse Proxy Settings.

Promoting Docker Images
Artifactory supports promoting Docker images from one Docker repository in Artifactory to another.
Promoting is useful when you need to move Docker images through different acceptance and testing stages, for example, from a development
repository, through the different gateways all the way to production. Instead of rebuilding the image multiple times using promotion will ensure the
image you will have in your production environment is the one built by your CI server and passed all the relevant tests.
Promotion can be triggered using the following endpoint with cURL:the following endpoint with cURL:

POST api/docker//v2/promote
{
"targetRepo" : "",
"dockerRepository" : "",
"tag" : "",
"targetTag" : "",
"copy":
}

where:
repoKey

Source repository key

targetRepo

The target repository to move or copy

dockerRepository

The docker repository name to promote

tag

An optional tag name to promote, if null - the entire docker repository will be promoted. Default: "latest"

targetTag

The new tag that the image should have after being promoted if you want to

copy

When true, a copy of the image is promoted. When false, the image is moved to the target repository

An example for promoting the docker image "jfrog/ubuntu" with all of it's tags from docker-local to docker-prod using cURL would be:

curl -i -uadmin:password -X POST "https://artprod.company.com/v2/promote"
-H "Content-Type: application/json" -d
'{"tagetRepo":"docker-prod","dockerRepository":"jfrog/ubuntu"}'

Notice that the above example is executed through your reverse proxy. To go directly through Artifactory, you would execute this command as
follows:

curl -i -uadmin:password -X POST
"http://localhost:8080/artifactory/api/docker/docker-local/v2/promote" -H
"Content-Type: application/json" -d
'{"targetRepo":"docker-prod","dockerRepository":"jfrog/ubuntu"}'

The following example adds retagging with a specific version of the "jfrog/ubuntu" image (4.9.0) being retagged to "latest" as it gets promoted:

curl -i -uadmin:password -X POST "https://artprod.company.com/v2/promote"
-H "Content-Type: application/json" -d
'{"targetRepo":"docker-prod","dockerRepository":"jfrog/ubuntu", "tag" :
"4.9.0", "targetTag" : "latest"}'

Pushing and Pulling Images
Set Me Up
To get the corresponding docker push and docker pull commands for any repository, select it in the Tree Browser and click Set Me Up butt
on.

Browsing Docker Repositories
For general information on how to browse repositories, please refer to Browsing Artifactory.
The Docker Info tab presents three sections: Tag Info, Docker Tag Visualization, and Labels.
Tag Info

Presents basic details about the selected tag.

Title

The Docker tag name.

Digest

The tag's SHA 256 digest.

Total Size

The total size of the image

Label Count

The number of labels attached to this tag.
Click the label count to view the attached labels at the bottom of the screen.

Docker Tag Visualization

This section maps the entire set of commands used to generate the selected tag along with the digest of the corresponding layer. Essentially, you
would see the same series of commands using docker history.
You can select any layer of the image to view the following properties:
Symbol

Property
The layer
ID
The layer
size
The
timestamp
when the
layer was
created

The
command
that
created
the layer

Labels

This section displays the labels attached to the image.

Note also, that from version 4.4.0, Artifactory extracts any labels associated with a Docker image and creates corresponding properties on the ma
nifest.json file which you can use to specify search parameters, this can be used to easily add additional metadata to any image.

Searching for Docker Images
You can search for Docker images by their name, tag or image digest using Artifactory's Package Search or through the REST API.

Listing Docker Images
From version 4.4.3, Artifactory supports the following REST API endpoints related to Docker registries:
List Docker Images provides a list of Docker images in the specified Artifactory Docker registry. This endpoint mimics the Docker _catalo
g REST API.
List Docker Tags provides a list of tags for the specified Docker image.

From version 5.4.6, Artifactory also supports pagination for this endpoint.

Pushing Images to Bintray
Through Artifactory's close integration with JFrog Bintray, you can push Docker images from your Artifactory Docker Registries directly to Bintray.
To enable this, make sure your Bintray credentials are properly configured in your User Profile page.
To push an image to Bintray, use the Distribution Repository.

Deletion and Cleanup
Artifactory natively supports removing tags and repositories and complies with the Docker Hub spec.
Deletion of Docker tags and repositories automatically cleans up any orphan layers that are left (layers not used by any other tag/repository).
Currently, the Docker client does not support DELETE commands, but deletion can be triggered manually. To delete an entire Docker repository
using cURL, execute the following command:

curl -u -X DELETE "//"

Or for a specific tag version:

curl -u -X DELETE "///"

For example, to remove the latest tag of an Ubuntu repository:

//Removing the latest tag from the "jfrog/ubuntu" repository
curl -uadmin:password -X DELETE
"https://artprod.company.com/dockerv2-local/jfrog/ubuntu/latest"

Empty Directories
Any empty directories that are left following removal of a repository or tag will automatically be removed during the next folder pruning
job (which occurs every 5 minutes by default).

Limiting Unique Tags
To avoid clutter and bloat in your Docker registries caused by many snapshots being uploaded for an image, set the Max Unique Tags field in the
Local Docker Repository configuration to limit the number of unique tags.

Migrating from Docker V1 to Docker V2
If you are still using Docker V1, we strongly recommend upgrading to Docker V2. This requires that you migrate any Docker repositories that were
created for Docker V1, and is done with a simple cURL endpoint.
For details, please refer to Migrating a V1 repository to V2 under the Using Docker V1 documentation.
Using Docker V1?
This document shows how to use Artifactory with the Docker V2 . If you are using the Docker V1, please refer to Using Docker V1.

Support Matrix
This matrix provides information on features supported as the versions of Artifactory progress.
Artifactory Version

Docker Client Version

4.9+

1.12

4.8+

1.11

4.4.3+

1.10

4.1+

1.8+

4.0.2+

1.8

4.0.0+

1.6+

4.0.0+

<1.6

Docker V1 API

Docker V2 API

Remote Repositories*

Virtual Repositories*

* Supported for Docker V2 API only

Getting Started with Artifactory as a Docker Registry
Overview
There are three main ways you can use Docker with Artifactory and this document describes how to get
started with each way.
Please review the brief summary below to decide which is the best way for you to use Docker with Artifactory.
Artifactory SaaS
The easiest way to start using Docker with Artifactory is through an Artifactory SaaS account.
In this mode, since Artifactory is a hosted service, you do not need to set up a reverse proxy and can create
your Docker repositories and start pushing and pulling Docker images.
For more details, please refer to Getting Started with Artifactory SaaS.
Using Docker Compose - 1 Minute Setup
Artifactory can be run in a Docker container preconfigered as a Docker registry.
For more details, please refer to Using Docker Compose - 1 Minute Setup.
Artifactory On-Prem
You can setup your on-prem installation of Artifactory Pro to work with Docker.
Since the Docker client requires a different hostname for each registry you will need to configure a reverse
proxy when using this method.
For more details, please refer to Getting Started with Artifactory Pro On-Prem.
Page Contents
Overview
Getting Started with Artifactory SaaS
Using Docker Client with Artifactory SaaS
Test Your Setup
Using Docker Compose - 1 Minute Setup
Complete the Setup

Test Your Setup
Getting Started with Artifactory Pro On-Prem
The Subdomain Method
Configuring Artifactory and Your Reverse Proxy
Test Your Setup
The Ports Method
Configuring Artifactory and Your Reverse Proxy
Configuring Your Docker Client
Test Your Setup

Getting Started with Artifactory SaaS
Using Docker repositories with Artifactory SaaS is quick and easy to use.
Since, with Artifactory SaaS, you are using Artifactory as a hosted service, there is no need to configure Artifactory with a reverse proxy.
The example at the end of this section shows a complete process of creating a Docker repository, logging in, pulling an image and pushing an
image.
Using Docker Client with Artifactory SaaS

To use the Docker client with one of your Artifactory SaaS Docker repositories, you can use the native Docker client to login to each Docker
repository, pull, and push images as shown in the following example:
Login to your repository use the following command with your Artifactory SaaS credentials

docker login ${server-name}-{repo-name}.jfrog.io

Pull an image using the following command

docker pull ${server-name}-{repo-name}.jfrog.io/

To push an image, first tag it and then use the push command

docker tag ${server-name}-{repo-name}.jfrog.io/
docker push ${server-name}-{repo-name}.jfrog.io/

Test Your Setup

You can test your setup with this example that assumes you are using an Artifactory SaaS server named "acme".
The scenario it demonstrates is:
Pulling the "hello-world" Docker image
Logging into your local Docker repository
Retagging the "hello-world" image, and the pushing it into your local Docker repository
Start by creating a local Docker repository called dockerv2-local.
Pull the "hello-world" image

docker pull hello-world

docker login acme-dockerv2-local.jfrog.io

Tag the "hello-world" image

docker tag hello-world acme-dockerv2-local.jfrog.io/hello-world

Push the tagged "hello-world" image to dockerv2-local

docker push acme-dockerv2-local.jfrog.io/hello-world

Using Docker Compose - 1 Minute Setup
Artifactory may easily be installed as a Docker registry running in Docker. This is the easiest way to use Artifactory as a Docker registry
on-premises. The installation spins up the following three containers:
Artifactory Pro
NGINX proxy that uses a self-signed certificate and is configured for access using the sub-domain method
A Postgres database
To spin up this installation run the following command:

curl -L
'https://bintray.com/api/v1/content/jfrog/run/art-compose/$latest/art-comp
ose?bt_package=art-compose' | sudo bash

Complete the Setup

To complete the setup, invoke the onboarding wizard by running Artifactory in your browser at http:///artifactory.
Activate Artifactory with your license key. If you do not have a license you can get a free 30 day Trial license.
You may set the Admin password or skip to accept the default
If necessary, configure your network proxy or just skip this step (you may configure a proxy server at any time later)
At Create Repositories, select Docker and continue to complete the wizard
Sub-domains method
We use this method so you will not need to change the reverse proxy configuration for each new Docker repository created.
Finally, follow the steps below:
1. You need to add the following to your DNS or /etc/hosts file:

docker-local.artifactory docker-remote.artifactory
docker.artifactory artifactory

2. Since the certificate is self-signed, you need to import it to your Docker certificate trust store as described in the Docker documentation.
Alternatively, you can configure the Docker client to work with an insecure registry by adding the following line to your /etc/default/d
ocker file (you may need to create the file if it does not already exist):

DOCKER_OPTS="$DOCKER_OPTS --insecure-registry docker-local.artifactory
--insecure-registry docker-remote.artifactory --insecure-registry
docker.artifactory"

3. Restart your Docker daemon/engine to apply the insecure registry flag (if self-signed certificate is imported, you do not need to restart the
Docker daemon/engine).
Test Your Setup

You can test your setup with this example .
The scenario it demonstrates is:
Pulling the "hello-world" Docker image
Logging into your virtual Docker repository
Retagging the "hello-world" image, and the pushing it into your virtual Docker repository
The Artifactory Docker registry is already configured with a virtual repository called docker.artifactory.
Pull the "hello-world" image

docker pull hello-world

docker login docker.artifactory

Tag the "hello-world" image

docker tag hello-world docker.artifactory/hello-world

Push the tagged "hello-world" image to docker.artifactory

docker push docker.artifactory/hello-world

Getting Started with Artifactory Pro On-Prem
Using Artifactory Pro On-Prem with Docker requires a reverse proxy due to the following limitations of the Docker client:
1. You cannot use a context path when providing the registry path (e.g localhost:8081/artifactory is not valid)
2. Docker will only send basic HTTP authentication when working against an HTTPS host
Therefore, you need a reverse proxy to map Docker commands to Docker registries in Artifactory using either the subdomain method or the port
s method.
Testing or evaluating?
If you are currently only testing or evaluating using Artifactory with Docker, we recommend running Artifactory as a Docker container w
hich is easily installed and comes with a proxy server and Docker registries pre-configured out-of-the-box. You can be up and running in
minutes.

With the ports method, a port number mapped to each Artifactory Docker registry. While this is an easy way to get started, you will need to modify
your reverse proxy configuration and add a new mapping for each new Docker registry you define in Artifactory. In addition, firewalls and other
restrictions by your IT department may restrict port numbers making the ports method not feasible.
With the subdomain method, you only need to configure your reverse proxy once, and from then on, the mapping from Docker commands to
Docker registries in Artifactory is dynamic and requires no further modification of your reverse proxy configuration.
We recommend to use the subdomain method since it will require one time effort.
The Subdomain Method

Getting started with Docker and your on-prem Artifactory Pro installation using the subdomain method involves two basic steps:
1. Configuring Artifactory and your reverse proxy.
2. Configuring your Docker client.
Configuring Artifactory and Your Reverse Proxy

To configure Artifactory and your reverse proxy using the subdomain method, carry out the following steps:
1.

Make sure Artifactory is up and running, and is activated with a valid license.

2. Create your local Docker repository. In our example below we will use a repository named docker-local.
3. Make sure you have a reverse proxy server up and running.
4. Obtain a wildcard SSL certificate or use a wildcard self-signed certificate.
Make sure your certificate matches the Artifactory hostname used in your reverse proxy configuration. In our example below
we will use art.local.
5. Configure your reverse proxy. Artifactory's Reverse Proxy Configuration Generator can generate your complete reverse proxy
configuration file for supported servers. All you need to do is fill in the fields in according to how your reverse proxy is set up while making
sure to:
a. Use the correct Artifactory hostname in the Public Server Name field (in our example this will be art.local)
b. Select Subdomain as the Reverse Proxy Method under Docker Reverse Proxy Settings
NGINX
Copy the code snippet generated by the configuration generator into your artifactory-nginx.conf file, and place it in your /etc/n

ginx/sites-available directory.
Create the following symbolic link.

sudo ln -s /etc/nginx/sites-available/artifactory-nginx.conf
/etc/nginx/sites-enabled/artifactory-nginx.conf

Apache HTTPD
Copy the code snippet generated by the configuration generator into your artifactory-apache.conf file and place it in you /etc/a
pache2/sites-available directory.
Create the following symbolic link:

sudo ln -s /etc/apache2/sites-available/artifactory-apache.conf
/etc/apache2/sites-enabled/artifactory-apache.conf

Configuring Your Docker Client
To configure your Docker client, carry out the following steps
1.

Add the following to your DNS or to the client's /etc/hosts file:
docker-local.art.local

DOCKER_OPTS="$DOCKER_OPTS --insecure-registry docker-local.art.local"

3. Restart your Docker daemon/engine to apply the insecure registry flag (if self-signed certificate is imported, you do not need to restart the
Docker daemon/engine).

Test Your Setup
To verify your reverse proxy is configured correctly, run the following command making sure that the return code is 200:

curl -I -k -v https://

Run the following commands to ensure your proxy configuration is functional and can communicate with Artifactory:
Pull the "hello-world" image

docker pull hello-world

docker login docker-local.art.local

Tag the "hello-world" image

docker tag hello-world docker-local.art.local/hello-world

Push the tagged "hello-world" image to docker-local

docker push docker-local.art.local/hello-world

The Ports Method
Getting started with Docker and your on-prem Artifactory Pro installation using the ports method involves two basic steps:
1. Configuring Artifactory and your reverse proxy.
2. Configuring your Docker client.
Configuring Artifactory and Your Reverse Proxy

To configure Artifactory and your reverse proxy using the ports method, carry out the following steps:
1.
2.
3.
4.

Make sure Artifactory is up and running, and is activated with a valid license.
Create your local Docker repository. In our example below we will use a repository named docker-local.
Make sure you have a reverse proxy server up and running.
Obtain an SSL certificate or use a Self-Signed certificate that can be generated following this example.
Make sure your certificate matches the Artifactory hostname used in your reverse proxy configuration. In our example below
we will use art.local.

5. Configure your reverse proxy. Artifactory's Reverse Proxy Configuration Generator can generate your complete reverse proxy
configuration file for supported servers. All you need to do is fill in the fields in according to how your reverse proxy is set up while making
sure to:
a. Use the correct Artifactory hostname in the Public Server Name field
b. Select Ports as the Reverse Proxy Method under Docker Reverse Proxy Settings. In the example below, we will use port 500
1 to bind repository docker-local.
NGINX
For Artifactory to work with Docker, the preferred web server is NGINX v1.3.9 and above.
First, you need to create a self-signed certificate for NGINX as described here for Ubuntu.
Then use Artifactory's Reverse Proxy Configuration Generator to generate the configuration code snippet for you.
Copy the code snippet into your artifactory-nginx.conf file and place it in your /etc/nginx/sites-available directory.
Finally, create the following symbolic link:

sudo ln -s /etc/nginx/sites-available/artifactory-nginx.conf
/etc/nginx/sites-enabled/artifactory-nginx.conf

Apache HTTPD
Install Apache HTTP server as a reverse proxy and then install the required modules.
Create the following symbolic link:

sudo ln -s /etc/apache2/mods-available/slotmem_shm.load
/etc/apache2/mods-enabled/slotmem_shm.load

Similarly, create corresponding symbolic links for:
headers
proxy_balancer
proxy_load
proxy_http

proxy_connect
proxy_html
rewrite.load
ssl.load
lbmethod_byrequests.load
Then use Artifactory's Reverse Proxy Configuration Generator to generate the configuration code snippet for you.
Copy the code snippet into your artifactory.conf file and place it in your /etc/apache2/sites-available directory.
HAProxy
First, you need to create a self-signed certificate for HAProxy as described here for Ubuntu.
Then, copy the code snippet below into your /etc/haproxy/haproxy.cfg file. After editing the file as described in the snippet, you
can test your configuration using the following command:

haproxy -f /etc/haproxy/haproxy.cfg -c

HAProxy v1.5 Configuration
# haproxy server configuration
# version 1.0
# History
#
-------------------------------------------------------------------------# Features enabled by this configuration
# HA configuration
# port 80, 443 Artifactory GUI/API
#
# This uses ports to distinguish artifactory docker repositories
# port 443 docker-virtual (v2) docker v1 is redirected to
docker-dev-local.
# port 5001 docker-prod-local (v1); docker-prod-local2 (v2)
# port 5002 docker-dev-local (v1); docker-dev-local2 (v2)
#
# Edit this file with required information enclosed in <...>
# 1. certificate and key
# 2. artifactory-host
# 3 replace the port numbers if needed
#
--------------------------------------------------------------------------global
log 127.0.0.1
local0
chroot /var/lib/haproxy
maxconn 4096
user haproxy
group haproxy
daemon
tune.ssl.default-dh-param 2048
stats socket /run/haproxy/admin.sock mode 660 level admin
defaults
log
global
mode
http
option httplog
option dontlognull

option redispatch
option forwardfor
option http-server-close
maxconn 4000
timeout connect 5000
timeout client 50000
timeout server 50000
errorfile 400 /etc/haproxy/errors/400.http
errorfile 403 /etc/haproxy/errors/403.http
errorfile 408 /etc/haproxy/errors/408.http
errorfile 500 /etc/haproxy/errors/500.http
errorfile 502 /etc/haproxy/errors/502.http
errorfile 503 /etc/haproxy/errors/503.http
errorfile 504 /etc/haproxy/errors/504.http
frontend normal
bind *:80
bind *:443 ssl crt
mode http
option forwardfor
reqirep ^([^\ :]*)\ /v2(.*$) \1\
/artifactory/api/docker/docker-virtual/v2\2
reqadd X-Forwarded-Proto:\ https if { ssl_fc }
option forwardfor header X-Real-IP
default_backend normal
# if only need to access the docker-dev-local2 then skip this section.
Docker-virtual can be configured to deploy to docker-dev-local2
frontend dockerhub
bind *:5000 ssl crt
mode http
option forwardfor
option forwardfor header X-Real-IP
reqirep ^([^\ :]*)\ /v2(.*$) \1\
/artifactory/api/docker/docker-remote/v2\2
reqadd X-Forwarded-Proto:\ https if { ssl_fc }
default_backend normal
# if only need to access the docker-dev-local2 then skip this section.
Docker-virtual can be configured to deploy to docker-dev-local2
frontend dockerprod
bind *:5001 ssl crt
mode http
option forwardfor
option forwardfor header X-Real-IP
reqirep ^([^\ :]*)\ /v1(.*$) \1\
/artifactory/api/docker/docker-prod-local/v1\2
reqirep ^([^\ :]*)\ /v2(.*$) \1\
/artifactory/api/docker/docker-prod-local2/v2\2
reqadd X-Forwarded-Proto:\ https if { ssl_fc }
default_backend normal
# if only need to access the docker-dev-local2 then skip this section.
Docker-virtual can be configured to deploy to docker-dev-local2

frontend dockerdev
bind *:5002 ssl crt
mode http
option forwardfor
option forwardfor header X-Real-IP
reqirep ^([^\ :]*)\ /v1(.*$) \1\
/artifactory/api/docker/docker-dev-local/v1\2
reqirep ^([^\ :]*)\ /v2(.*$) \1\
/artifactory/api/docker/docker-dev-local2/v2\2
reqadd X-Forwarded-Proto:\ https if { ssl_fc }
default_backend normal
# Artifactory Non HA Configuration
# i.e server artifactory 198.168.1.206:8081
#
backend normal
mode http
server :
#
# Artifactory HA Configuration
# Using default failover interval - rise = 2; fall =3 3; interval - 2
seconds
# backend normal
#
mode http
#
balance roundrobin
#
option httpchk OPTIONS /
#
option forwardfor
#
option http-server-close
#
appsession JSESSIONID len 52 timeout 3h
#
server :
#
server :

Configuring Your Docker Client

To configure your Docker client, carry out the following steps
1. Add the following to your DNS or to the client's /etc/hosts file:

art.local

DOCKER_OPTS="$DOCKER_OPTS --insecure-registry art.local:5001"

3. Restart your Docker engine.
Test Your Setup

To verify your reverse proxy is configured correctly, run the following command:

// Make sure the following results in return code 200
curl -I -k -v https://

Run the following commands to ensure your proxy configuration is functional and can communicate with Artifactory. In this example, we will pull
down a Docker image, tag it and then deploy it to our our docker-local repository that is bound to port 5001:

// Pull the "hello-world" image
docker pull hello-world
// Login to repository docker-local
docker login art-local:5001
// Tag the "hello-world" image
docker tag hello-world art-local:5001/hello-world
// Push the tagged "hello-world" image to docker-local
docker push art-local:5001/hello-world

Testing With a Self-signed Certificate
1. Since the certificate is self-signed, you need to import it to your Docker certificate trust store as described in the Docker documentation. A
lternatively, you can configure the Docker client to work with an insecure registry by adding the following line to your /etc/default/do
cker file (you may need to create the file if it does not already exist).

DOCKER_OPTS="$DOCKER_OPTS --insecure-registry docker-local.art.local"

2. Restart your Docker daemon/engine to apply the insecure registry flag (if self-signed certificate is imported, you do not need to restart the
Docker daemon/engine).
3. Use the steps above to interact with the Artifactory Docker Registry

Advanced Topics
Overview
This page provides some advanced topics for using Docker with Artifactory.
Page Contents
Overview
Using a Self-signed SSL Certificate
Using Your Own Certificate
Setting Your Credentials Manually
Authenticating via OAuth

Using a Self-signed SSL Certificate
You can use self-signed SSL certificates with docker push/pull commands, however for this to work, you need to specify the --insecure-r
egistry daemon flag for each insecure registry.
For full details please refer to the Docker documentation.
For example, if you are running Docker as a service, edit the /etc/default/docker file, and append the --insecure-registry flag with
your registry URL to the DOCKER_OPTS variable as in the following example:

Edit the DOCKER_OPTS variable
DOCKER_OPTS="-H unix:///var/run/docker.sock --insecure-registry
artprod.company.com"

For this to take effect, you need to restart the Docker service.
If you are using Boot2Docker, please refer to the Boot2Docker documentation for Insecure Registry.
If you do not make the required modifications to the --insecure-registry daemon flag, you should get the following error:

Error message
v2 ping attempt failed with error: Get https://artprod.company.com/v2/:
x509: cannot validate certificate for artprod.company.com because it
doesn't contain any IP SANs

Using Your Own Certificate
The NGINX configuration provided with Artifactory out-of-the-box references the internally bundled certificate and key which you may replace with
your own certificate and key.
For details, please refer to Using Your Own Certificate.

Setting Your Credentials Manually
If you are unable to log in to Docker, you may need to set your credentials manually.
Manually setting your Docker credentials
The Docker command line tool supports authenticating sensitive operations, such as push, with the server using basic HTTP authentication.
To enforce authenticated access to docker repositories you need to provide the following parameters to the Docker configuration file.
The Docker endpoint URL (must use HTTPS for basic authentication to work)

Your Artifactory username and password (formatted username:password) as Base64 encoded strings
Your email address
You can use the following command to get these strings directly from Artifactory and copy/paste them into your ~/.dockercfg file:
sudo
If you are using Docker commands with "sudo" or as a root user (for example after installing the Docker client), note that the Docker
configuration file should be placed under/root/.dockercfg

Getting .dockercfg entries directly from Artifactory
$ curl -uadmin:password "https://artprod.company.com//auth"
{
"https://artprod.company.com" : {
"auth" : "YWRtaW46QVA1N05OaHZTMnM5Qk02RkR5RjNBVmF4TVFl",
"email" : "admin@email.com"
}
}

The Docker configuration file may contain a separate authentication block for each registry that you wish to access.
Below is an example with two URL endpoints:

{
"https://artprod.company.com": {
"auth":"YWRtaW46cGFzc3dvcmQ=",
"email":"myemail@email.com"
},
"https://artprod2.company.com": {
"auth":"YWRtaW46cGFzc3dvcmQ=",
"email":"myemail@email.com"
}
}

Authenticating via OAuth
From version 4.4, Artifactory supports authentication of the Docker client using OAuth through the default GitHub OAuth provider. When
authenticating using OAuth you will not need to provide additional credentials to execute docker login with Artifactory.
To set up OAuth authentication for your Docker client, execute the following steps:
Under General OAuth Settings, make sure Auto Create Artifactory Users is checked to make sure a user record is created for you
first time you log in to Artifactory with OAuth.
Log in to Artifactory with OAuth using your Git Enterprise account
Once you are logged in to Artifactory through your Git Enterprise OAuth account, your Docker client will automatically detect this and use OAuth
for authentication, so you do not need to provide additional credentials.

Working with Docker Content Trust
Overview
Notary is Docker's platform to provide trusted delivery of content by signing images that are published. A
content publisher can then provide the corresponding signing keys that allow users to verify that content
when it is consumed. Artifactory fully supports working with Docker Notary to ensure that Docker images
uploaded to Artifactory can be signed, and then verified when downloaded for consumption. When the
Docker client is configured to work with Docker Notary, after pushing an image to Artifactory, the client
notifies the Notary to sign the image before assigning it a tag.
Artifactory supports hosting signed images without the need for any additional configuration.

Page Contents
Overview
Configuring Docker Notary and Docker Client
Configuring Your Hosts File
Configuring the Notary Server
Configuring the Docker Client
Test Your Setup

Configuring Docker Notary and Docker Client
There is no configuration needed in Artifactory in order to work with trusted Docker images. However, in the setup instructions below, we do
recommend testing your configuration by signing Artifactory and running it in a container.
To configure the Docker Notary and client to work with Artifactory, execute the following main steps:
Configure your hosts file
Configure the Notary server and run it as a container
Configure the Docker client
Configuring Your Hosts File

If you are not working with a DNS, add the following entries to your /etc/hosts file:

sudo sh -c 'echo " " >> /etc/hosts'
sudo sh -c 'echo " " >> /etc/hosts'

Configuring the Notary Server

Create a directory for your Notary server. In the code snippets below we will use notarybox.
Create a dockerfile with the following content:

FROM debian:jessie
ADD https://get.docker.com/builds/Linux/x86_64/docker-1.9.1 /usr/bin/docker
RUN chmod +x /usr/bin/docker \
&& apt-get update \
&& apt-get install -y \
tree \
vim \
git \
ca-certificates \
--no-install-recommends
WORKDIR /root
RUN git clone https://github.com/docker/notary.git && \
cp /root/notary/fixtures/root-ca.crt
/usr/local/share/ca-certificates/root-ca.crt && \
update-ca-certificates
ENTRYPOINT ["bash"]

Use a private certificate
This configuration runs with a public certificate. Any Docker client running with the same public certificate may be able to access your

Notary server.
For a secure setup, we recommend replacing it with your organization's private certificate by replacing the public root-ca.crt certific
ate file with your private certificate under /root/notary/fixtures on your Notary server, and under /usr/local/share/ca-ce
rtificates on the machine running your Docker client.

Build the test image:

docker build -t [image name] [path to dockerfile]

If you are running the build in your dockerfile directory, you can just use "." as the path to the dockerfile
Start the Notary server:
To start the Notary server, you first need to have Docker Compose installed.
Then execute the following steps:

cd notarybox
git clone -b trust-sandbox https://github.com/docker/notary.git
cd notary
docker-compose build
docker-compose up -d

Configuring the Docker Client

To connect the Notary server to the Docker client you need to enable the Docker content trust flag and add the Notary server URL as follows:

export DOCKER_CONTENT_TRUST=1
export DOCKER_CONTENT_TRUST_SERVER=https://notaryserver:4443

Test Your Setup
The example below demonstrates setting up the Notary server and Docker client, signing an image and the pushing it to Artifactory, with the
following assumptions:
Notary server and Artifactory run on localhost (127.0.0.1)
Notary server is in directory notarybox
Working without a DNS (so we need to configure the hosts file)
Notary server name is notaryserver
Artifactory server name is artifactory-registry
Docker Compose is installed
Set up the IP mappings

sudo sh -c 'echo "127.0.0.1 notaryserver" >> /etc/hosts'
sudo sh -c 'echo "127.0.0.1 artifactory-registry" >> /etc/hosts'

Create the Dockerfile

FROM debian:jessie
ADD https://get.docker.com/builds/Linux/x86_64/docker-1.9.1 /usr/bin/docker
RUN chmod +x /usr/bin/docker \
&& apt-get update \
&& apt-get install -y \
tree \
vim \
git \
ca-certificates \
--no-install-recommends
WORKDIR /root
RUN git clone -b trust-sandbox https://github.com/docker/notary.git && \
cp /root/notary/fixtures/root-ca.crt
/usr/local/share/ca-certificates/root-ca.crt && \
update-ca-certificates
ENTRYPOINT ["bash"]

Note that this example uses the public root-ca.crt certificate.
Navigate to the Dockerfile location and build the test image

docker build -t notarybox .

Run Artifactory as a container

docker pull
jfrog-docker-reg2.bintray.io/jfrog/artifactory-registry:
docker run -d --name artifactory-registry -p 80:80 -p 8081:8081 -p 443:443
-p 5000-5002:5000-5002
jfrog-docker-reg2.bintray.io/jfrog/artifactory-registry:

Access your Artifactory instance (at http:/localhost:8081/artifactory) and activate it with an Artifactory Pro license.
For more details on running Artifactory as a Docker container, please refer to TEMP - Installing with Docker.
Start your container
In this step you will start the container with the dockerfile you created earlier, and link it to your Notary server and Artifactory.

docker run -it -v /var/run/docker.sock:/var/run/docker.sock --link
notary_server_1:notaryserver --link
artifactory-registry:artifactory-registry notarybox

Pull an image for testing

docker pull docker/trusttest

After you have pulled the image, you need to docker login to artifactory-registry:5002/v2
Configure the Docker client

export DOCKER_CONTENT_TRUST=1
export DOCKER_CONTENT_TRUST_SERVER=https://notaryserver:4443

Tag the image you pulled for testing and push it to Artifactory

docker tag docker/trusttest artifactory-registry:5002/test/trusttest:latest
docker push artifactory-registry:5002/test/trusttest:latest

You will be asked to enter the root key passphrase. This will be needed every time you push a new image while the
DOCKER_CONTENT_TRUST flag is set.
The root key is generated at: /root/.docker/trust/private/root_keys
You will also be asked to enter a new passphrase for the image. This is generated at /root/.docker/trust/private/tuf_keys/[regist
ry name] /[imagepath]

Using Docker V1
Overview
This page describes how to use Artifactory with the Docker V1 Registry API. If you are using the Docker V2
Registry API, please refer to Docker Registry.
For general information on using Artifactory with Docker, please refer to Artifactory as a Docker Registry.

Getting Started with Artifactory and Docker
Artifactory supports Docker transparently, meaning you can point the Docker client at Artifactory and issue
push, pull and other commands in exactly the same way that you are used to when working directly with a
private registry or Docker Hub.
To get started using Docker with Artifactory you need to execute the following steps:

1.
2.
3.
4.

Set up a web server as a reverse proxy
Create a local repository
Set up authentication
Push and pull images

The screencast at the end of this section provides a demonstration.
1. Setting up NGINX as a Reverse Proxy

Artifactory can only be used with Docker through a reverse proxy due to the following limitations of the
Docker client:
1. You cannot provide a context path when providing the registry path (e.g localhost:8081/artifa
ctory is not valid)
2. Docker will only send basic HTTP authentication when working against an HTTPS host
For Artifactory to work with Docker, the preferred web server is NGINX v1.3.9 and above configured as a
reverse proxy.
For other supported web servers, please refer to Alternative Proxy Servers.
Below is a sample configuration for NGINX which configures SSL on port 443 to a specific local repository in
Artifactory (named docker-local) on a server called artprod.company.com.
Using Docker v1, Docker client v1.10 and Artifactory 4.4.3 known issue.
To avoid incompatibility when using Docker V1 with Docker 1.10, use the NGINX configuration
displayed below and not the NGINX configuration generated by Artifactory v4.4.3.
NGINX Configuration for Docker V1
This code requires NGINX to support chunked transfer encoding which is available from NGINX v1.3.9.

[...]
http {
##
# Basic Settings
##
[...]
server {
listen 443;
server_name artprod.company.com;
ssl on;
ssl_certificate
/etc/ssl/certs/artprod.company.com.crt;
ssl_certificate_key
/etc/ssl/private/artprod.company.com.key;
access_log
/var/log/nginx/artprod.company.com.access.log;
error_log
/var/log/nginx/artprod.company.com.error.log;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For
$proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Original-URI
$request_uri;
proxy_read_timeout 900;
client_max_body_size 0; # disable any
limits to avoid HTTP 413 for large image uploads
# required to avoid HTTP 411: see Issue
#1486
(https://github.com/docker/docker/issues/1486)
chunked_transfer_encoding on;
location /v1 {
proxy_pass
http://artprod.company.com:8081/artifactory/api/do
cker/docker-local/v1;
}
}
}

Multiple Docker repositories and port bindings

If you want to use multiple Docker repositories, you need to copy this configuration and bind
different ports to each local repository in Artifactory. For details, please refer to Port Bindings.

Repository URL prefix
When accessing a Docker repository through Artifactory, the repository URL must be prefixed with
api/docker in the path. For details, please refer to Docker Repository Path and Domain.

2. Creating a Local Docker Repository

This is done in the same way as when configuring a local repository to work with Docker V2, however, in the
Docker Settings section, you should make sure to select V1 as the Docker API version.

Page Contents
Overview
Getting Started with Artifactory and Docker
1. Setting up NGINX as a Reverse Proxy
2. Creating a Local Docker Repository
Working with Artifactory SaaS
3. Setting Up Authentication
4. Pushing and Pulling Images
Watch the Screencast
Browsing Docker Repositories
Viewing the Docker Images Tree
Viewing Individual Docker image Information
Searching for Docker Images
Promoting Docker Images with V1
Migrating a V1 repository to V2
Deletion and Cleanup
Advanced Topics
Using a Self-signed SSL Certificate
Alternative Proxy Servers
Apache Configuration
Port Bindings
Docker Repository Path and Domain
Support Matrix

Working with Artifactory SaaS

Click here to expand...
Due to limitations of the Docker client, in Artifactory SaaS there is a special configuration for each server with a sub-domain.
You need to create a new Docker enabled local repository named docker-local.
Then, use the following address when working with the Docker client: "${account_name}.jfrog.io"
3. Setting Up Authentication

When using Artifactory with Docker V1, you need to set your credentials manually by adding the following section to your ~/.docker/config.j
son file.

~/.docker/config.json
{
"auths" :{
"https://artprod.company.com" : {
"auth": ": (converted to base 64)",
"email": "youremail@email.com"
},
"https://artdev.company.com" : {
"auth": ": (converted to base 64)",
"email": "youremail@email.com"
}
}
}

4. Pushing and Pulling Images

Pushing and pulling images when using Docker V1 is done in the same way as when using Docker V2. Please refer to Pushing and
Pulling Images under the Docker Repositories page.
Watch the Screencast

Once you have completed the above setup you should beableuse the Docker client to transparently push images to and pull them from Docker
repositories in Artifactory. You can see this in action in the screencast below.

Browsing Docker Repositories
Artifactory stores docker images in a layout that is made up of 2 main directories:
.images: Stores all the flat docker images.
repositories: Stores all the repository information with tags (similar to how repositories are stored in the Docker Hub).
In addition, Artifactory annotates each deployed docker image with two properties:
docker.imageId: The image id
docker.size: The size of the image in bits
Deployed tags are also annotated with two properties:
docker.tag.name: The tag name
docker.tag.content: The id of the image that this tag points to

Viewing the Docker Images Tree

Artifactory lets you view the complete images tree for a specific image directly from the UI in a similar way to what you would get from the docker
images --tree command.
In the Artifacts module Tree Browser, drill down to select the image you want to inspect. The metadata is displayed in the Docker Ancestry tab.

Viewing Individual Docker image Information

In the Artifacts module Tree Browser, drill down to select image you want to inspect. The metadata is displayed in the Docker Info tab.

Searching for Docker Images

In addition to other properties related to Docker repositories, you can also search for repositories using a property called docker.repoName, whi
ch represents the repository name (e.g., "library/ubuntu").

Promoting Docker Images with V1

Promoting Docker images with Docker V1 is done in exactly the same way as when Promoting Images with Docker V2.

Migrating a V1 repository to V2
We recommend using Docker V2 repositories when possible (provided your Docker client is version 1.6 and above).
If you have an existing Docker V1 repository, you can migrate its content into a V2 repository using the following endpoint with cURL:

POST api/docker//v1/migrate
{
"targetRepo" : "",
"dockerRepository" : "",
"tag" : ""
}

where:

Source repository key (For example, docker-local as used in this page)

The target Docker V2 repository to migrate to (For example, docker-local2 as used in this page). The repository should
be created before running the migrate endpoint.

An optional docker repository name to migrate, if null - the entire source repository will be migrated. Default: ""

An optional tag name to promote, if null - the entire docker repository will be promoted. Default: ""

An example for migrating the docker image "jfrog/ubuntu" with all of it's tags from docker-local to docker-local2 using cURL would
be:

curl -i -uadmin:password -X POST
"http://localhost:8081/artifactory/api/docker/docker-local/v1/migrate" -H
"Content-Type: application/json" -d
'{"targetRepo":"docker-local2","dockerRepository":"jfrog/ubuntu"}'

Deletion and Cleanup
Artifactory natively supports removing tags and repositories and complies with the Docker Hub Spec.
Deletion of Docker tags and repositories automatically cleans up any orphan layers that are left (layers not used by any other tag/repository).
Currently, the Docker client does not support DELETE commands, but deletion can be triggered manually using cURL. Here are some examples:

Removing repositories and tags
//Removing the "jfrog/ubuntu" repository
curl -uadmin:password -X DELETE
"https://artprod.company.com/v1/repositories/jfrog/ubuntu"
//Removing the "12.04" tag from the "jfrog/ubuntu" repository
curl -uadmin:password -X DELETE
"https://artprod.company.com/v1/repositories/jfrog/ubuntu/tags/12.04"

Advanced Topics
Using a Self-signed SSL Certificate

From Docker version 1.3.1, you can use self-signed SSL certificates with docker push/pull commands, however for this to work, you need to
specify the --insecure-registry daemon flag for each insecure registry.
For full details please refer to the Docker documentation.
For example, if you are running Docker as a service, edit the /etc/default/docker file, and append the --insecure-registry flag with
your registry URL to the DOCKER_OPTS variable as in the following example:

Edit the DOCKER_OPTS variable
DOCKER_OPTS="-H unix:///var/run/docker.sock --insecure-registry
artprod.company.com"

Error message
Error: Invalid registry endpoint https://artprod.company.com/v1/: Get
https://artprod.company.com/v1/_ping: x509: certificate signed by unknown
authority.

Using previous versions of Docker
In order to use self-signed SSL certificates with previous versions of Docker, you need to manually install the certificate into the OS of
each machine running the Docker client (see Issue 2687).

Alternative Proxy Servers

In addition to NGINX, you can setup Artifactory to work with Docker using Apache.
Apache Configuration

The sample configuration below configures SSL on port 443 and a server name of artprod.company.com.
Apache config for docker V1

ServerName artprod.company.com
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
SSLEngine on
SSLCertificateFile/etc/ssl/certs/artprod.company.com.pem
SSLCertificateKeyFile
/etc/ssl/private/artprod.company.com.key
ProxyRequests off
ProxyPreserveHost on
ProxyPass
/
http://artprod.company.com:8080/artifactory/api/docker/docker-local/
ProxyPassReverse /
http://artprod.company.com:8080/artifactory/api/docker/docker-local/

Port Bindings

If you want to use multiple repositories, you need to copy the NGINX configuration and bind different ports to each local repository in Artifactory.
When binding a port other than 443, note that the configuration for the proxy header must be appended with the port number on the proxy_set_
header line.
For example, for a server running on port 444 you should write proxy_set_header Host $host:444.
Docker Repository Path and Domain

When accessing a Docker repository through Artifactory, the repository URL must be prefixed with api/docker in the path.
You can copy the full URL from the UI using Set Me Up when the repository is selected in the Tree Browser.
For example, if you are using Artifactory standalone or as a local service, you would access your Docker repositories using the following URL:
http://localhost:8081/artifactory/api/docker/
Also, the domain of your Docker repository must be expressed as an explicit IP address. The only exception is when working locally, you can use
the localhost domain name as the proxy pass.

Support Matrix
Please refer to the support matrix under Docker Repositories.

Git LFS Repositories
Overview
From version 3.9, Artifactory supports Git Large File Storage (LFS) repositories on top of Artifactory's existing
support for advanced artifact management.
Artifactory support for Git LFS provides you with a fully functional LFS server that works with the Git LFS
client.
LFS blobs from your Git repository can be pushed and maintained in Artifactory offering the following
benefits:
Performance:
With Artifactory’s file storage on your local or corporate network, file download times may be
significantly reduced. When considering the number of files that may be needed for a build, this can
drastically reduce your build time and streamline your workflow.
Reliable and consistent access to binaries:
With Artifactory as your LFS repository, all the resources you need for development and build are
stored on your own local or corporate network and storage. This keeps you independent of the
external network or any 3rd party services.
Share binary assets with remote Git LFS repositories
Share your video, audio, image files and any other binary asset between teams across your
organization by proxying Git LFS repositories on other Artifactory instances or on GitHub.
Upload and download binary assets using a single URL
Use a virtual Git LFS repository as both a source and a target for binary assets. By wrapping local
and remote repositories, and defining a deploy target in a virtual Git LFS repository, your Git LFS
client only needs to be exposed to that single virtual repository for all your work with binary assets.
Security and access control:
Artifactory lets you define which users or groups of users can access your LFS repositories with a full
set of permissions you can configure. You can control where developers can deploy binary assets to,
whether they can delete assets and more. And if it’s access to your servers that you’re concerned
about, Artifactory provides full integration with the most common access protocols such as LDAP,
SAML, Crowd and others.
One solution for all binaries:
Once you are using Artifactory to store media assets there is no need to use a 3rd party LFS
provider. Artifactory can now handle those along with all the other binaries it already manages for
you.
Page Contents
Overview
Configuration
Local
Repositories
Remote
Repositories
Virtual
Repositories
Setting Up the
Git LFS Client
to Point to
Artifactory
Working with
Artifactory without
Anonymous Access
Authenticating
with SSH
Metadata
Storage
5-Minute Setup

Configuration

Local Repositories
To create a Git LFS local repository and enable calculation of LFS package metadata set GitLfs as the Package Type.

Remote Repositories
You can create a Git LFS remote repository to proxy LFS repositories on GitHub, or Git LFS local repositories on other Artifactory instances. If
you are proxying a Git LFS local repository on another instance of Artifactory, you can enjoy all the features of a smart remote repository.
To define a Git LFS remote repository, create a new remote repository, set its Package Type to be Git LFS, and set the URL of the repository you
want to proxy.

Virtual Repositories
A Virtual Repository defined in Artifactory aggregates packages from both local and remote repositories.
This allows you to access both locally hosted binary assets and remote proxied git LFS repositories from a single URL defined for the virtual
repository.
To create a Git LFS virtual repository set Git LFS to be its Package Type, and select the underlying local and remote Git LFS repositories to
include under the Repositories section.
Make sure you also set the Default Deployment Repository so you can both download from and upload to this repository.

Setting Up the Git LFS Client to Point to Artifactory
In order for your client to upload and download LFS blobs from artifactory the [lfs] clause should be added to the .lfsconfig file of your Git
repository in the following format.

.lfsconfig
[lfs]
url = "https:///api/lfs/"
For example:
[lfs]
url = "https://localhost:8080/artifactory/api/lfs/lfs-local"

You can also set different LFS endpoints for different remotes on your repo (as supported by the Git LFS client), for example:

.git/config different lfs url for remotes
[remote "origin"]
url = https://...
fetch = +refs/heads/*:refs/remotes/origin/*
lfsurl = "http://localhost:8081/artifactory/api/lfs/lfs-local"

Copy these clauses using Set Me Up
If you select your GitLFS repository in the Tree Browser and click Set Me Up, Artifactory will display these clauses in a dialog from
which you can simply copy and paste them.

Working with Proxies and HTTPS
When using HTTPS (i.e. behind a proxy) with a self signed certificate your configuration might also require you to add the following:

.gitconfig http section
[http]
sslverify = false

Always consult your System Administrator before bypassing secure protocols in this way.

When running Artifactory behind a proxy, defining a base url is usually required (depending on configuration) due to the operation of
the
Git LFS client which expects to receive redirect urls to the exact upload \ download location of blobs.

LFS repositories must be prefixed with api/lfs in the path
When accessing a Git LFS repository through Artifactory, the repository URL must be prefixed with api/lfs in the path, except when
configuring replication.
For example, if you are using Artifactory standalone or as a local service, you would access your LFS repositories using the following
URL:
http://localhost:8081/artifactory/api/lfs/
Or, if you are using SaaS the URL would be:
https://.jfrog.io//api/lfs/

When configuring replication, reference the repository's browsable url i.e.;
http://localhost:8081/artifactory/

Working with Artifactory without Anonymous Access
By default, Artifactory allows anonymous access to Git LFS repositories. This is defined in the Admin module under Security | General . For
details please refer to Allow Anonymous Access.
If you want to be able to trace how users interact with your repositories you need to uncheck the Allow Anonymous Access setting. This means
that users will be required to enter their username and password.
The Git LFS client will ask for credentials for the Artifactory LFS repo when accessing it - if anonymous access is allowed you can just enter blank
credentials, otherwise you should enter your Artifactory user name and password (not your Git one).
To make the authentication process automatic you can use Git Credential Helpers to store these for you, and have the Git LFS client authenticate
automatically.
Git stores credentials in plain text by default
You should take extra measures to secure your username and password when using Git credential
helpers

Authenticating with SSH
From version 4.4, Artifactory supports authenticating your Git LFS client via SSH.
To authenticate yourself via SSH when using the Git LFS client, execute the following steps:
Make sure Artifactory is properly configured for SSH as described in Configuring Server Authentication.

Upload your SSH Public Key in the SSH section of your user profile as described in Configuring User Authentication.
Configure the Git LFS client as follows:
Update the known_hosts file with the Artifactory server public key. This file is located under ~/.ssh/known_hosts (and there
is also a system-wide file under /etc/ssh/known_hosts). This should take the following format:
[]:
For example,

[myartifactory.company.com]:1339 ssh-rsa
AAAAB3Nza...PC0GuTJT9TlaYD user@domain.com

Update your .lfsconfig file at the repository level (not the global level) as follows:
ssh://$USERNAME@$HOST:$PORT/artifactory/
For example,

url =
"ssh://git@myartifactory.company.com:1339/artifactory/lfs-local"

Artifactory Online Dedicated Server
If you are using a dedicated server on Artifactory SaaS and wish to authenticate via SSH, please contact support@jfrog.com.

Metadata
As the Git LFS client supplies only limited data about the blob being uploaded (only it's sha256 checksum, or 'OID', and it's size) Artifactory does
not store or process any metadata for LFS blobs.

You can set properties on the blobs for your own convenience but this requires extra logic to infer a sha256-named file stored in artifactory from
the actual pointer stored in your Git repository.

Storage
Artifactory stores LFS blobs in a manner similar to the Git LFS client, using the provided sha256 checksum.
Git LFS blobs will be stored under a path such as /objects/ad/1b/ad1b8d6e1cafdf33e941a5de462ca7edfa8818a70c79f
eaf68e5ed53dec414c4
Where ad and 1b are the 1st and 2nd, and the 3rd and 4th characters in the blob's name respectively.

Git LFS behavior when download from the LFS endpoint fails
The Git LFS client will download the pointer file it created in your remote Git repository if downloading the blob from the LFS endpoint
failed (i.e. wrong credentials, network error etc.).
This will cause the actual file in your local repo to be substituted with the pointer created by the LFS client with the same name and
lead to any number of problems this behavior can cause.
This is a limitation of the LFS client tracked by issue 89.

5-Minute Setup
Visit our Knowledge Base and learn how to setup Git LFS to work with Artifactory in 5 minutes.

Npm Registry
Overview
Artifactory provides full support for managing npm packages and ensures optimal and reliable access to npmj
s.org.Aggregating multiple npm registries under a virtual repository Artifactory provides access to all your
npm packages through a single URL for both upload and download.

As a fully-fledged npm registry on top of its capabilities for advanced artifact management, Artifactory's
support for npm provides:
1. The ability to provision npm packages from Artifactory to the npm command line tool from all
repository types
2. Calculation of Metadata for npm packages hosted in Artifactory's local repositories
3. Access to remote npm registries (such as https://registry.npmjs.org) through Remote
Repositories which provide the usual proxy and caching functionality
4. The ability to access multiple npm registries from a single URL by aggregating them under a Virtual
Repository. This overcomes the limitation of the npm client which can only access a single registry at
a time.
5. Compatibility with the npm command line tool to deploy and remove packages and more.
6. Support for flexible npm repository layouts that allow you to organize your npm packages and assign
access privileges according to projects or development teams.

Npm version support
Artifactory supports NPM version 1.4.3 and above.

Configuration
Local Npm Registry
To enable calculation of npm package metadata in local repositories so they are, in effect, npm registries, set
the Package Type to npm when you create the repository:

Page Contents
Overview
Configuration
Local Npm
Registry
Repository Layout
Remote Npm
Registry
Virtual Npm
Registry
Adva
nced
Confi
gurati
on
Using the Npm
Command Line
Setting the
Default
Registry
Authenticating
the npm Client
Using
npm
login
Using
Basic
Authe
nticati
on
Resolving
npm
Packages
Npm Publish
(Deploying Packages)
Setting Your
Credentials
Deploying
Your
Packages
Specifying the Latest
Version
Working with
Artifactory without
Anonymous Access
Using OAuth Credenti
als
Npm Search
Cleaning Up the Local
Npm Cache
Npm Scope Packages

Configuring
the npm Client
for a Scope
Registry
Using
Login
Crede
ntials
Automatically
Rewriting External
Dependencies
Rewriting
Workflow
Viewing Individual
Npm Package
Information
Watch the Screencast

Repository Layout
Artifactory allows you to define any layout for your npm regsitries. In order to upload packages according to your custom layout, you need to
package your npm files using npm pack.
This creates the .tgz file for your package which you can then upload to any path within your local npm repository.

Remote Npm Registry
A Remote Repository defined in Artifactory serves as a caching proxy for a registry managed at a remote URL such as https://registry.np
mjs.org.
Artifacts (such as tgz files) requested from a remote repository are cached on demand. You can remove downloaded artifacts from the remote
repository cache, however, you can not manually deploy artifacts to a remote npm registry.
To define a remote repository to proxy a remote npm registry follow the steps below:
1. In the Admin module, under Repositories | Remote, click "New".
2. In the New Repository dialog, set the Package Type to npm, set the Repository Key value, and specify the URL to the remote registry
in the URL field as displayed below

3. Click "Save & FInish"

Virtual Npm Registry
A Virtual Repository defined in Artifactory aggregates packages from both local and remote repositories.
This allows you to access both locally hosted npm packages and remote proxied npm registries from a single URL defined for the virtual
repository.
To define a virtual npm registry, create a virtual repository, set the Package Type to be npm, and select the underlying local and remote npm
registries to include in the Basic settings tab.

Click "Save & Finish" to create the repository.
Advanced Configuration

The fields under External Dependency Rewrite are connected to automatically rewriting external dependencies for npm packages that need
them.
Enable
Dependency
Rewrite

When checked, automatically rewriting external dependencies is enabled.

Remote
Repository For
Cache

The remote repository aggregated by this virtual repository in which the external dependency will be cached.

Patterns
Whitelist

A white list of Ant-style path expressions that specify where external dependencies may be downloaded from. By default,
this is set to ** which means that dependencies may be downloaded from any external source.
For example, if you wish to limit external dependencies to only be downloaded from github.com, you should add **gith
ub.com** (and remove the default ** expression).

Using the Npm Command Line
Npm repositories must be prefixed with api/npm in the path
When accessing an npm repository through Artifactory, the repository URL must be prefixed with api/npm in the path. This applies to all
npm commands including npm install and npm publish.
For example, if you are using Artifactory standalone or as a local service, you would access your npm repositories using the following
URL:
http://localhost:8081/artifactory/api/npm/
Or, if you are using Artifactory SaaS the URL would be:
https://.jfrog.io//api/npm/
To use the npm command line you need to make sure npm is installed. Npm is included as an integral part of recent versions of Node.js.
Please refer to Installing Node.js via package manager on GitHub or the npm README page.
Once you have created your npm repository, you can select it in the Tree Browser and click Set Me Up to get code snippets you can use to
change your npm registry URL, deploy and resolve packages using the npm command line tool.

Setting the Default Registry
For your npm command line client to work with Artifactory, you first need to set the default npm registry with an Artifactory npm repository using
the following command (the example below uses a repository called npm-repo):

Replacing the default registry
npm config set registry
http://:8081/artifactory/api/npm/npm-repo

For scoped packages, use the following command:

npm config set @:registry
http://:8081/artifactory/api/npm/npm-repo

We recommend referencing a Virtual Repository URL as a registry. This gives you the flexibility to reconfigure and aggregate other
external sources and local repositories of npm packages you deployed.
Note that If you do this, you need to use the --registry parameter to specify the local repository into which you are publishing your
package when using the npm publish command.

Authenticating the npm Client
Once you have set the default registry, you need to authenticate the npm client to Artifactory in one of two ways: using the npm login command
or using basic authentication.
Using npm login

Authentication using npm login was introduced in version 5.4.
Run the following command in your npm client. When prompted, provide your Artifactory login credentials:

npm login

Upon running this command, Artifactory creates a non-expirable access token which the client uses for authentication against Artifactory for
subsequent npm install and npm publish actions.
If the token is removed from Artifactory, the client will have to login again to receive a new token.
Using Basic Authentication

To support basic authentication you need to edit your .npmrc file and enter the following:
Your Artifactory username and password (formatted username:password) as Base64 encoded strings
Your email address (npm publish will not work if your email is not specified in .npmrc)
You need to set always-auth = true
.npmrc file location
Windows: %userprofile%\.npmrc
Linux: ~/.npmrc

Getting .npmrc entries directly from Artifactory
You can use the following command to get these strings directly from Artifactory:

$ curl -uadmin:
http://:8081/artifactory/api/npm/auth

Where is your Artifactory password or API Key

Here is an example of the response:

_auth = YWRtaW46e0RFU2VkZX1uOFRaaXh1Y0t3bHN4c2RCTVIwNjF3PT0=
email = myemail@email.com
always-auth = true

If, in addition, you are also working with scoped packages, you also need to run the following command:

curl -uadmin:
http://:8081/artifactory/api/npm/npm-repo/auth/

Where is your Artifactory password or API Key
Paste the response to this command in the ~/.npmrc file on your machine (in Windows, %USERPROFILE%/.npmrc).

Resolving npm Packages
Once the npm command line tool is configured, every npm install command will fetch packages from the npm repository specified above. For
example:

$ npm install request
npm http GET http://localhost:8081/artifactory/api/npm/npm-repo/request
npm http 200 http://localhost:8081/artifactory/api/npm/npm-repo/request
npm http GET
http://localhost:8081/artifactory/api/npm/npm-repo/request/-/request-2.33.
0.tgz
npm http 200
http://localhost:8081/artifactory/api/npm/npm-repo/request/-/request-2.33.
0.tgz

Npm Publish (Deploying Packages)
Setting Your Credentials
The npm command line tool requires that sensitive operations, such as publish, are authenticated as described under Authenticating the npm
Client above.

Deploying Your Packages
There are two ways to deploy packages to a local repository:
Edit your package.json file and add a publishConfig section to a local repository:
"publishConfig":{"registry":"http://localhost:8081/artifactory/api/npm/npm-local"}
Provide a local repository to the npm publish command:
npm publish --registry http://localhost:8081/artifactory/api/npm/npm-local

Specifying the Latest Version
By default, the "latest" version of a package in an NPM registry in Artifactory is the one with the highest SemVer version number. You can
override this behavior so that the most recently uploaded package is returned by Artifactory as the "latest" version. To do so, in Artifactory's
system.properties file, add or set:

artifactory.npm.tag.tagLatestByPublish = true

Working with Artifactory without Anonymous Access
By default, Artifactory allows anonymous access to npm repositories. This is defined in the Admin module under Security | General. For details
please refer to Allow Anonymous Access.
If you want to be able to trace how users interact with your repositories you need to uncheck the Allow Anonymous Access setting. This means
that users will be required to enter their username and password as described in Setting Your Credentials above.

Using OAuth Credentials
Artifactory uses GitHub Enterprise as its default OAuth provider. If you have an account, you may use your GitHub Enterprise login details to be
authenticated when using npm login.

Npm Search
Artifactory supports a variety of ways to search of artifacts. For details please refer to Searching Artifacts.
Artifactory also supports npm search [search terms ...], however, packages may not be available immediately after being published for

the following reasons:
When publishing a package to a local repository, Artifactory calculates the search index asynchronously and will wait for a "quiet period" to lapse
before indexing the newly published package.
Since a virtual repository may contain local repositories, a newly published package may not be available immediately for the same reason.
You can specify the indexing "quiet period" (time since the package was published) by setting the following system properties (in $ARTIFACTORY
_HOME/etc/artifactory.system.properties) .

artifactory.npm.index.quietPeriodSecs=60
artifactory.npm.index.cycleSecs=60

In the case of remote repositories, a new package will only be found once Artifactory checks for it according to the Retrieval Cache Period setting
.
Artifactory annotates each deployed or cached npm package with two properties: npm.name and npm.version
You can use Property Search to search for npm packages according to their name or version.

Cleaning Up the Local Npm Cache
The npm client saves caches of packages that were downloaded, as well as the JSON metadata responses (named .cache.json).
The JSON metadata cache files contain URLs which the npm client uses to communicate with the server, as well as other ETag elements sent by
previous requests.
We recommend removing the npm caches (both packages and metadata responses) before using Artifactory for the first time. This is to ensure
that your caches only contain elements that are due to requests from Artifactory and not directly from https://registry.npmjs.org.
The default cache directory on Windows is %APPDATA%\npm-cache while on Linux it is ~/.npm.

Npm Scope Packages
Artifactory fully supports npm scope packages. The support is transparent to the user and does not require any different usage of the npm client.
Npm 'slash' character encoding
By default, the npm client encodes slash characters ('/') to their ASCII representation ("%2f") before communicating with the npm
registry. If you are running Tomcat as your HTTP container (the default for Artifactory), this generates an "HTTP 400" error since
Tomcat does not allow encoded slashes by default. In order work with npm scoped packages, you can override this default behavior by
defining the following property in the catalina.properties file of your Tomcat:
org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true
Note that since Artifactory version 4.4.3, the bundled Tomcat is configured by default to enable encoded slashes. If you are using a
previous version you will need to adjust the Tomcat property above.

URL decoding and reverse proxy
If Artifactory is running behind a reverse proxy, make sure to disable URL decoding on the proxy itself in order to work with npm scope
packages.
For Apache, add the "AllowEncodedSlashes NoDecode" directive inside the block.

Configuring the npm Client for a Scope Registry
Using Login Credentials

Scopes can be associated with a separate registry. This allows you to seamlessly use a mix of packages from the public npm registry and one or
more private registries.

For example, you can associate the scope @jfrog with the registry http://localhost:8081/artifactory/api/npm/npm-local/ by
manually altering your ~/.npmrc file and adding the following configuration:

@jfrog:registry=http://localhost:8081/artifactory/api/npm/npm-local/
//localhost:8081/artifactory/api/npm/npm-local/:_password=cGFzc3dvcmQ=
//localhost:8081/artifactory/api/npm/npm-local/:username=admin
//localhost:8081/artifactory/api/npm/npm-local/:email=myemail@email.com
//localhost:8081/artifactory/api/npm/npm-local/:always-auth=true

Getting .npmrc entries directly from Artifactory
From Artifactory 3.5.3, you can use the following command to get these strings directly from Artifactory:
$ curl -uadmin:password "http://localhost:8081/artifactory/api/npm/npm-local/auth/jfrog"
@jfrog:registry=http://localhost:8081/artifactory/api/npm/npm-local/
//localhost:8081/artifactory/api/npm/npm-local/:_password=QVA1N05OaHZTMnM5Qk02RkR5RjNBVmF4TVFl
//localhost:8081/artifactory/api/npm/npm-local/:username=admin
//localhost:8081/artifactory/api/npm/npm-local/:email=admin@jfrog.com
//localhost:8081/artifactory/api/npm/npm-local/:always-auth=true

User email is required
When using scope authentication, npm expects a valid email address. Please make sure you have included your email address in your
Artifactory user profile.

The password is just a base64 encoding of your Artifactory password, the same way used by the old authentication configuration.

Recommend npm command line tool version 2.1.9 and later.
While npm scope packages have been available since version 2.0 of the npm command line tool, we highly recommend using npm
scope packages with Artifactory only from version 2.1.9 of the npm command line tool.

Automatically Rewriting External Dependencies
Packages requested by the Npm client frequently use external dependencies as defined in the packages' package.json file. These
dependencies may, in turn, need additional dependencies. Therefore, when downloading an Npm package, you may not have full visibility into the
full set of dependencies that your original package needs (whether directly or transitively). As a result, you are at risk of downloading malicious
dependencies from unknown external resources. To manage this risk, and maintain the best practice of consuming external packages through
Artifactory, you may specify a "safe" whitelist from which dependencies may be downloaded, cached in Artifactory and configure to rewrite the
dependencies so that the Npm client accesses dependencies through a virtual repository as follows:
Check Enable Dependency Rewrite in the Npm virtual repository advanced configuration.
Specify a whitelist patterns of external resources from which dependencies may be downloaded.
Specify the remote repository in which those dependencies should be cached.
It is preferable to configure a dedicated remote repository for that purpose so it is easier to maintain.
In the example below the external dependencies will be cached in "npm" remote repository and only package from https://github.com/jfro
gdev are allowed to be cached.

Artifactory supports all possible shorthand resolvers including the following:

git+ssh://user@hostname:project.git#commit-ish
git+ssh://user@hostname/project.git#commit-ish
git+https://git@github.com//.git

Rewriting Workflow
1.

When downloading an Npm package, Artifactory analyzes the list of dependencies needed by the
package.
If any of the dependencies are hosted on external resources (e.g. on github.com), and those
resources are specified in the white list,
a. Artifactory will download the dependency from the external resource.
b. Artifactory will cache the dependency in the remote repository configured to cache the external
dependency.
c. Artifactory will then modify the dependency's entry in the package's package.json file indicating its
new location in the Artifactory remote repository cache before returning it to the Npm client.
Consequently, every time the Npm client needs to access the dependency, it will be provisioned from its
new location in the Artifactory remote repository cache.

Viewing Individual Npm Package Information
Artifactory lets you view selected metadata of an npm package directly from the UI.
In the Tree Browser, drill down to select the tgz file you want to inspect. The metadata is displayed in the Npm Info tab.

Watch the Screencast

NuGet Repositories
Overview
From version 2.5, Artifactory provides complete support for NuGet repositories on top of Artifactory's existing
support for advanced artifact management.
Artifactory support for NuGet provides:
1.
2.
3.
4.
5.

The ability to provision NuGet packages from Artifactory to NuGet clients from all repository types
Metadata calculation for NuGet packages hosted in Artifactory's local repositories
The ability to define proxies and caches to access Remote NuGet repositories
Multiple NuGet repository aggregation through virtual repositories
APIs to deploy or remove packages that are compatible with NuGet Package Manager Visual Studio
extension and the NuGet Command Line Tool
6. Debugging NuGet packages directly using Artifactory as a Microsoft Symbol Server

Metadata updates
NuGet metadata is automatically calculated and updated when adding, removing, copying or
moving NuGet packages. The calculation is only invoked after a package-related action is
completed.
It is asynchronous and its performance depends on the overall system load, therefore it may
sometimes take up to 30 seconds to complete.
You can also invoke metadata calculation on the entire repository by selecting "Reindex
Packages".

Page Contents
Overview
Configuration
Local
Repositories
Local

Repo
sitory
Layou
t
Publis
hing
to a
Local
Repo
sitory
Remote
Repositories
Virtual
Repositories
Accessing NuGet
Repositories from
Visual Studio
Using the NuGet
Command Line
NuGet API Key
Authentication
Anonymous Access to
NuGet Repositories
Working
Without
Anonymous
Access
Allowing
Anonymous
Access
Viewing Individual
NuGet Package
Information
Watch the Screencast

JFrog Artifactory 5.6 User Guide

JFrog%20Artifactory%205.6%20User%20Guide

Navigation menu

Versions of this User Manual:

Views

Navigation