App Config - Environment Specific Settings
App Config - Environment Specific Settings

Azure App Configuration Service – Labels for Environment Specific Settings

As we know, we can store configuration settings in App Configuration Service in the form of key-value pairs. We can also apply labels to each key value pair. In this article, we are going to have a look at how labels can be used to store environment specific key value pairs.

Why environment specific settings are needed ?

Many times, the application may use different configurations in different environments. One of the simplest example is – the database connection string. Each environment would have a its own specific database instance. The dev environment’s application should connect with dev environment’s database. Similarly, test environment’s application should connect with test environment’s database. So, the application has a single key, but it’s value is supposed to vary based on which environment is asking for key.

Similarly, some feature flags may also have different values in different environments. Some features which are still under development, may be disabled on production, but they may be enabled on dev environment.

We can use labels for this purpose. We can define multiple keys with different value. Each of the key will have a label specifying the environment in which the value should be used.

Let’s take an example !

Let’s say, we have an ASP .NET Core API application. The API application connects with App Configuration Service for reading the configuration settings. Let’s say there is a setting for log level, TestApi:LogLevel. The log level is supposed to have different value on different environments

  • On Development environment, the log level should be Debug
  • On Staging environment, the log level should be set to Information
  • On Production environment, the log level should be set to Warning

In addition to this environment specific setting, there are supposed to be some other configuration settings which are not specific to environment.

Let’s say, our application needs another setting, let’s say the application wants to call a third party API. The third party API would be stored in the App Configuration Service. Let’s say the setting name is TestApi:ApiEndpointUrl.

For the sake of demo, the application will read the keys and return the key and value as output.


For following all steps in this article, we will need Azure Subscription.  If you don’t have an Azure subscription, create an Azure free account before you begin.

Create Azure App Configuration Service

We will need an instance of Azure App Configuration Service. You can refer this article to create one using Azure Portal. Alternatively, you can run the bicep script from this article to create one for you. Refer my GitHub repository to create the resource if you want to use the Bicep files. This bicep file will also add some key value pairs.

Add the key value pairs needed for our demo.

  • Key = TestApi:ApiEndpointUrl, Value set to some URL, without any label
  • Key = TestApi:LogLevel, Value = Debug, Label = Development
  • Key = TestApi:LogLevel, Value = Information, Label = Staging
  • Key = TestApi:LogLevel, Value = Warning, Label = Production
Azure Portal – Added new key-value pairs

Create ASP .NET Core API Project

You can create a new project and then configure it to connect with our newly created Azure App Configuration service. Refer this article to create the new project.

Or you can also use the API project from my GitHub repository.

New Controller and New Action !

Now, let’s add a new controller, let’s say, SettingsController.cs. Add a new GET action, which will return the above mentioned two settings. The IConfiguration object should be injected in this controller. The complete code is shown in the snippet given below.

Modify Startup

In the Program.cs file, we need to modify the AddAzureAppConfiguration call a bit.

  • The connection string of Azure App Configuration Service should be read from the environment variable
  • Then the AddAzureAppConfiguration should take Action parameter as input.

In this Action parameter, we have to make three different method calls:

  • Connect, which takes connection string as input. It is needed to make connection with Azure App Configuration instance
  • Select, this first call takes two input parameters, the setting prefix which we have set to be “TestApi:*” with null label. It loads configuration values with no label.
  • Another Select call, this time as well, there are two parameters. The first parameter is again prefix of the settings which we have set to be “TestApi:*“. But this time, we are passing environment name as second parameter. So, any setting with TestApi: prefix and whose label is matching with environment name, will be fetched. These environment-specific values override any corresponding values with no label. You don’t need to define environment-specific values for every key. 

Add a reference to the Microsoft.Extensions.Configuration.AzureAppConfiguration namespace in order to access the KeyFilter and LabelFilter classes.

Run and Verify

Now, we need to run and verify that our setup works. It’s easy ! We can run the project from Visual Studio. The launchsettings.json file contains profiles and for each profile, there is a collection of environment variables. We can set ASPNETCORE_ENVIRONMENT variable to three different values, Development, Staging and Production.

After changing the value, we can run the API and then try to call the GET settings endpoint. The LogLevel value will vary every time the environment variable is changed, but the ApiEndpointUrl value will not change as it does not have any label.

Environment Specific Values are Printed Every Time Environment Name is Changed

So, we have successfully shown how the environment specific settings can be used. I hope you find this information helpful. Let me know your thoughts.

Leave a ReplyCancel reply