Do you use Azure App Configuration to manage configuration and secrets for local .NET development?

Starting a new .NET project often means chasing down local.settings.json files, environment variables, and secrets shared via chat or password managers. These files quickly drift out of date, are hard to rotate, and create friction for new developers who just want to press F5 and be productive.

Use Azure App Configuration as the single source of truth

Azure App Configuration provides a centralized, secure place to store application settings, feature flags, and references to secrets (via Azure Key Vault). By using it for local development as well as cloud environments, you eliminate the need to distribute configuration files.

Key benefits include:

• No shared config files – no more emailing or copying `local.settings.json`
• Faster onboarding – developers sign in and run the app
• Dynamic updates – configuration can change without restarting the app
• Improved security – secrets are never stored on disk

How it works for local .NET development

For local development, the .NET application loads configuration from Azure App Configuration at startup.

• Configuration values are fetched from Azure
• Values are held in memory while the application is running locally
• Optional refresh mechanisms allow changes to flow through dynamically
• Secrets are resolved securely via Azure Key Vault

var configBuilder = new ConfigurationBuilder();

var configuration = configBuilder
  .AddJsonFile(path: "path-to-local.settings.json")
  .AddEnvironmentVariables()
  .Build();

configBuilder.AddAzureAppConfiguration(acOptions =>
{
  var appConfig = configuration.GetRequiredSection("AppConfig");
  var appConfigUri = appConfig.GetValue<string>("Uri");
  var env = configuration.GetValue<string>("AppEnvironment");

  Console.WriteLine($"Connecting to '{appConfigUri}' to get values for '{env}'");

  acOptions
    .UseFeatureFlags(featureFlagOptions =>
    {
      // Set the Label to use
      featureFlagOptions.Label = env;

      // All Feature Flags will be refreshed at this interval
      featureFlagOptions.SetRefreshInterval(TimeSpan.FromMinutes(5));
    })
    // Get only key-values with label for the relevant environment
    .Select(KeyFilter.Any, env)
    .ConfigureRefresh(refreshOptions =>
    {
      refreshOptions.SetRefreshInterval(TimeSpan.FromMinutes(5));
    })
    .ConfigureKeyVault(kvOptions => { kvOptions.SetCredential(new DefaultAzureCredential()); });

  acOptions.Connect(new Uri(appConfigUri), new DefaultAzureCredential());
});

Figure: Sample App Configuration connection using Feature Flags and Key Vault

This creates a seamless local experience that closely mirrors production.

Authentication via Azure CLI

To access Azure App Configuration locally, developers authenticate using the Azure CLI.

• The developer runs `az login`
• The .NET app uses `DefaultAzureCredential`
• Access is granted based on Azure RBAC

This avoids local secrets entirely and ensures access is auditable and revocable.

✅ Figure: Good example - Configuration is centralized, secure, and requires no local files or manual setup

Why this improves the F5 experience

Using Azure App Configuration removes setup friction and configuration guesswork.

• New developers are productive in minutes
• Configuration stays consistent across the team
• Updates can be made centrally without redeploying or reconfiguring machines
• Local development behaves more like production

When to use this rule

You should follow this rule when:

• Building .NET applications (especially Azure-hosted workloads)
• Onboarding multiple developers to the same project
• Managing sensitive or frequently changing configuration
• You want a clean, secure, and scalable local development experience

Summary

If configuration is shared, sensitive, or frequently changing, it does not belong in local files. Azure App Configuration provides a secure, centralized, and developer-friendly approach that dramatically improves onboarding time and delivers an excellent F5 experience.