Central Configuration Overview

As we move towards Kubernetes-based containerized Deploy solution, the Digital.ai Deploy shared configuration files are moved to a centralized location from where they are managed by the Central Configuration Management server. The idea of Central Configuration is to have one central place—in this case, the Digital.ai Deploy’s Master server—where you can store, distribute, and manage configuration data for master/worker pods in your cluster. Digitial.ai Central Configuration is the process of maintaining and managing the configuration from a centralized location in the file system. With a centralized management, you can configure workers and masters easily and more efficiently. For example, if you have a Master-Master and Master-Worker setup with two masters and two workers, before Central Configuration you had to individually modify the configuration on all four instances. With the Central Configuration, the configurations are automatically reflected in all the instances.

In Digital.ai, a Central Configuration Management server stores and manages the configuration data from the Central Configuration directory (centralConfiguration) of the Deploy Master server’s file system so that the configuration data is clearly separated from your application data. Digital.ai Deploy uses the Spring Cloud Config framework to support the central configuration of Deploy shared configuration files. For more information on the Spring Cloud Config framework, see Spring Cloud Config framework.

Migration of Configuration Files

As part of the migration to Central Configuration process, all the shared configuration files are moved to the centralConfiguration folder from conf folder. The configurations that are specific to the instance are retained in the conf folder. This is to ensure that you do not duplicate conf folder, and save only the configuration that is specific to the instance, for example JVM configuration and Logback Configuration. Here is a sample of the folder structure:

For a detailed list of configuration files that are moved to the centralConfiguration directory, see Deploy Configuration Files.

Configuration File Changes

The Central Configuration features impact the configuration files in the .conf and centralConfiguration folders as follows:

  • The xl-deploy.conf file contains the details to configure database, server, license, and so on. For better management, the xl-deploy.conf file—that included the details to configure database, server, license, and so on—is refactored and logically broken down into modular configuration files to manage the different aspects of the application. The xl-deploy.conf file is no longer available, and each Configuration from xl-deploy.conf file is moved to separate .yaml files.
  • The Spring Cloud Configuration supports .yaml and .properties file formats. In Digital.ai, the .json configuration files are converted to .yaml file format. The type-defaults.properties file retains the .properties file format. The deployit-defaults.properties file is renamed as type-defaults.properties. Other configuration files that are not migrated to the centralConfiguration folder will remain in their original file format in the .conf folder.
  • The files that are migrated to the centralConfiguration folder have the prefix deploy. Additionally, the root key in the .yaml files, which used to be xl, is now changed to deploy. An example from the deploy-command-whitelist.yaml file:


  • Some of the properties in the deployit.conf file are distributed between deploy-client.yaml and deploy-server.yaml. The deploy-client-gui.yaml file is no longer available, and is subsumed by deploy-client.yaml file. The following properties in the deployit.conf file are redistributed:

    • deploy-client.yaml

    • deploy-server.yaml


      The following fields are deprecated, as they are no longer used in the deploy-client.yaml file:


      For more information about the deployit.conf file properties, see Deploy Configuration Files.

Note: The xl root key in deploy-repository.yaml file is not changed to deploy.

For more information about the configuration properties in the redistributed configuration files, see Deploy Properties.


If you modify the configuration parameters, you must refresh the configuration files to reflect the changes. To refresh the configuration files, run the following command:

$ curl XLD_URL/actuator/refresh -d {} -H "Content-Type: application/json"

Encryption/Decryption Policy

In Digital.ai, the sensitive information, such as passwords in the repository are encrypted with an encryption key that is stored in a keystore file called XL_DEPLOY_SERVER_HOME/conf/repository-keystore.jceks. With the central configuration, a new security encryption policy is created for the encryption/decryption of the values in XL_DEPLOY_SERVER_HOME/conf/deployit.conf file based on Password-based Encyrption (PBE) method used in the Spring Cloud Config framework. For more information, see Encryption and Decryption.

Encryption Algorithm

The PBE method uses the user-supplied password to create a strong cryptographic key using the hashing algorithm. In Digital.ai, we use the Advanced Encryption Standard (AES) algorithm that is based on the PBE method where the input value is converted to a compressed numerical value using the hash function. The specified password or the encryption key xl.spring.cloud.encrypt.key is used to create a hash with PBEKeySpec from the keystore to get the AES-256 encrypted key. If the user does not provide encryption key, a default key is generated by the Deploy system. The encryption key supports the following characters:

  • Uppercase letters (A–Z)
  • Lowercase letters (a–z)
  • Numbers (0–9)
  • Special characters (~`!@#%^&*()-_=+[{]}\|;:’”,<.>/?)

For more information about the key rotation process, see key rotation process.

Are you Upgrading to Deploy 10.1 and later versions?

For the customers upgrading to Deploy 10.1 and later versions, the central-config.version file is used to verify the current version of installed for the specific customer. Based on the installed version, it is decided if an upgrade to Central Configuration is required for the specific Master node.

For more information on the upgrade procedure, see Upgrade Deploy 8.0.X and Higher to Current.