External configuration of microservices

Microservices are designed to be deployed in multiple environments. Externalizing the configuration with MicroProfile Config helps microservices run in different environments without a change in code.

Separating the configuration and code

During their lifecycle, microservices are deployed repeatedly across development, test, and production environments. They need different configuration data, for example, deployment-specific external URLs or credentials that change regularly. Microservices must run in these conditions without a change in code.

Backing services require changes in connection details in the application source code, for example, in databases, messaging services, SMTP services, API accessible consumer services, and so on. Your application must swap among local and external services without a code change.

In the cloud, microservices deployed to Kubernetes clusters must communicate. Therefore, port binding, or knowing which port to connect to, is important. As instances of microservices are created and destroyed in Kubernetes to scale the application up and down, port numbers can change. You must assign new port numbers to the microservices and inject information during startup. For more information, see Configuring microservices running in Kubernetes.

Thus, it is important to change the configuration of microservices without updating or recompiling the code.

MicroProfile Config

MicroProfile Config separates the configuration from code. With MicroProfile Config, you can inject the external configuration into services in the containers without repackaging them.

Applications can use MicroProfile Config as a single API to retrieve configuration information from different sources such as system properties, system environment variables, properties files, XML files, or data sources. In MicroProfile Config, these data sources are called ConfigSources. The same configuration property can be defined in multiple ConfigSources. You can prioritize which ConfigSource to use for the property value. Each ConfigSource has a specified priority, which is defined by its ordinal value. A higher ordinal means that the values taken from this ConfigSource override ConfigSources with a lower ordinal value.

Default configsources

MicroProfile Config has three default configsources. The following table describes the default configsources in MicroProfile Config and their corresponding values.

ConfigSource Default ordinal values

All META-INF/microprofile-config.properties found on the class path


Environment variables


System properties


An optional default value can be specified by using Java annotations and applies if the application does not find the configuration values in any of the ConfigSources. For more information, see Separating configuration from code in microservices.

MicroProfile Config can configure other MicroProfile capabilities. It externalizes the configuration of keystores when microservices are secured. For example, in MicroProfile Java Web Token, the public key location and verification can be set in properties files so that if the location of the key repository changes, it can easily be updated. MicroProfile Config is also used in the configuration of channel attributes. For example, in MicroProfile Reactive Messaging, it can set the connection details of messaging channels, connectors, and the topic names that the application uses to produce messages. MicroProfile Config helps override values in fault tolerance. For example, in MicroProfile Fault Tolerance, it can set the value of an annotation so that you can change the value if the tolerance is too low or too high.