Introduction This article clarifies the expected behavior of the artifactory.config.latest.xml file when Global Configuration Descriptor changes are applied in an Artifactory High Availability (HA) cluster, particularly in Helm deployments with multiple pods. It addresses why this file might not update uniformly across all nodes. How Artifactory Handles Configuration Updates Artifactory's primary configuration resides in its shared database, which all HA nodes access. When a configuration change is made (via UI, or REST API), the update is written directly to this central database. The artifactory.config.latest.xml file on each node serves as a local backup. Importantly, this file is only updated on the specific node where the configuration change was initiated. This is Artifactory's intended behavior for HA deployments. Therefore, if you make a change to the configuration, only the node serving that request will update its local artifactory.config.latest.xml. Other nodes in the cluster will continue to read the correct, current configuration directly from the database, without updating their local backup files unless a change is initiated from them. Verifying Configuration Across All Nodes To confirm all pods in your Artifactory HA cluster are reading the correct and latest configuration, you can use the Retrieving and Setting the Global Configuration Descriptor REST API . Since the database is the single source of truth, all active nodes will always reflect the latest settings. For example, observe the differences in artifactory.config.latest.xml files between pods after an update via a PATCH to the Artifactory YAML Configuration:Then, to verify a specific change on another pod, log into one pod and execute the Retrieving and Setting the Global Configuration Descriptor REST API against the other pod's internal endpoint. The response will confirm the current, database-driven configuration:
