Cloud customer?
Start for Free >
Upgrade in MyJFrog >
What's New in Cloud >



The YAML configuration file offers an alternative way to specify your initial settings for JFrog Distribution. 

To get you up and running as quickly and easily as possible for a new installation, you can configure your basic initial setup through the filesystem, before starting Distribution for the first time.

Any edits will apply to the whole Distribution cluster.

Take care when modifying Distribution configurations

Modifying the Distribution configurations is an advanced feature, and if done incorrectly may render the Distribution service in an undefined and unusable state. Since it is easy to overwrite configurations, we strongly recommend backing up the configuration before making any direct changes, and taking great care when doing so.

Default Home Directory / $JFROG_HOME

The default Distribution home directory is defined according to the installation type. For additional details see the System Directories page.

Note: This guide uses $JFROG_HOME to represent the JFrog root directory containing the deployed product.

Page Contents

Applying Configuration Changes

To update the application configuration using the yaml file, follow these steps:

  1. Copy the template yaml file.

    cd $JFROG_HOME/distribution/var/etc/distribution/
    cp template.distribution.config.import.yml distribution.config.import.yml
  2. Edit the properties in the new distribution.config.import.yml file
  3. Restart the Distribution service with the updated yaml file. This update will propagate to the additional nodes.

Configuration file changes

A snapshot of the last imported configuration state will be saved as distribution.config.latest.yml.

Previous yaml configuration files will be saved as distribution.config.TIMESTAMP.yml. Up to a maximum of 10 previous configuration states.

Supported Configurations

Application YAML Configuration File
    interval-seconds: 5        # interval between successive runs of the heartbeat job
    consider-stale-seconds: 30 # the time period (seconds) a server can remain unresponsive before being considered stale in the cluster
    interval-seconds: 5        # interval between successive runs of the distribute job
    interval-seconds: 5        # interval between successive runs of the release bundle handler job

    timeout-millis: 100               # initial time (ms) to wait before retrying a request
    socket-timeout-millis: 5000       # time to wait (ms) before giving up on executing a REST call on another server
    exponential-backoff-multiplier: 2 # number by which the retry timeout should be multiplied before a subsequent retry. For example, by default, the third retry will happen after 200 ms
    number-of-retries: 3              # maximum number of retries
    backoff-max-delay-millis: 1000    # maximum time between successive retries regardless of other settings

  enabled:  true

  max-artifacts: 3000 # maximum number of artifacts to fetch from artifactory on release bundle creation

  edge-node-token-expiration-minutes: 180 # the time period (minutes) a token lives for communicating with edge node
  load-balancer: "simple"                 # algorithm to use for distributing the work between the Distribution nodes

  max-http-header-size: 16384 # 16kb in bytes

  client-short-socket-timeout: 10000    # socket timeout in millis for Artifactory bound short tasks, e.g.: auth and pairing with Artifactory
  client-long-socket-timeout: 120000    # socket timeout in millis for Artifactory bound long tasks, e.g.: release-bundles' store, deletion and artifacts' gathering (AQL) queries

  release-bundle-scan-consider-stuck: 600000 # the time in millis for xray vulnerability scanning considering stuck

Increasing the Header Size (server.max-http-header-size)

The Request header max size can manually be increased to prevent receiving an HTTP 400 message when signing into Distribution with SSO.
For this change to take effect, each distribution node in the cluster must be restarted. Start with rebooting the first node one on which the config file is installed and proceed to the remaining Edge nodes.

Deploying your GPG Key on the source Artifactory

Distribution will trigger the source Artifactory to clone the contents of signed release bundles into an isolated release-bundles repository. To allow this, you need to deploy the GPG Key that is used in each of your Artifactory Edge nodes to the source Artifactory service.

For more details, refer to Setting a GPG Key.

For more details on additional required configurations, refer to configuring Distribution.

Copyright © 2022 JFrog Ltd.