Configuration data is accessed using HTTP like:


This request will serve you the configuration file for your artifact „myArtifact“ in version 2.0 and for your environment (Dev, UAT, Production). Behind the scenes it’s possible to have the config file for version 2.0 of your artifact. The Configuration Server analyzes the requested version. In case there is no 2.2 and no 2.1 but a 2.0 you’ll get the 2.0. This fallback saves you from creating configuration just because it’s a rule but nothing really changed.

So your directory structure would be:

│ └───
│ └───

A different scenario is to prepare configuration for rollout. Many Ops use provisioning and management software like Chef and Puppet. These can deploy applications for example. In case you’ve split responsibilities, Ops deploy the application you deploy the configuration also the Configuration Server is perfect: Just prepare configuration for version 2.3 (would be the next) of your artifact and deploy it to your configuration data repository. As soon as the new artifact version is deployed it’ll pull the right version of the configuration. The older installation will still stick to the old configuration and won’t be tangled by this change.