Feature Flags without redeploying: what people usually get wrong in .NET

This issue is made possible thanks to JetBrains, who help keep this newsletter free for everyone. A huge shout-out to them for their support of our community. Let's thank them by entering the link below. Struggling with slow builds, tricky bugs, or hard-to-understand performance issues? dotUltimate fixes all of that. It’s the all-in-one toolbox for serious .NET developers. 👉 Upgrade your .NET workflow.

Introduction

How do you enable or disable features without redeploying the app?

If your first thought is “I’ll just flip a value in appsettings.json” - you’re not alone. But that’s also where most Feature Flag implementations quietly fail.

In the last few days, I shared a short post about Feature Flags in .NET, and the comments were exciting.

They all circled the same confusion:

Do we really avoid redeployment? How does this work with multiple instances? Is appsettings.json enough? Do I still need to run a DevOps release?

Let’s clear this up - with real code that actually works.

First: What “Without Redeploying” Actually Means

Let’s be very explicit.

“Without redeploying” means:

• ❌ no build
• ❌ no release pipeline
• ❌ no app restart
• ❌ no new container image

• ✅ behavior changes while the app is running

  If changing a feature flag requires you to click 'Deploy', then you haven’t decoupled deployment from release - you've just moved the toggle.

  Why appsettings.json Is NOT Enough

Yes, you can define feature flags in appsettings.json.

12345
{  "FeatureManagement": {    "BetaFeature": true  }}

But here’s the problem:

1. appsettings.json is read at startup
2. each instance has its own copy
3. any change requires:
   • file change
   • restart
   • redeploy So this works for:
   • local development
   • demos
   • small experiments

But it does not work for:

• multiple instances
• Kubernetes
• Azure App Service
• real production traffic

To truly avoid redeployment, feature flags must live outside the application.

The Correct Architecture

Feature Flags must be:

• centrally stored
• shared across instances
• read at runtime
• refreshable without a restart In .NET, this is exactly what Azure App Configuration + Feature Management gives us. Let’s build this properly.

Step 1: Install Required Packages

These give us:

• Feature Flags API
• Azure App Configuration integration
• runtime refresh support

12
dotnet add package Microsoft.FeatureManagement.AspNetCoredotnet add package Microsoft.Azure.AppConfiguration.AspNetCore

Step 2: Configure Azure App Configuration

In Azure Portal:

1. Create Azure App Configuration
2. Go to Feature Manager
3. Create a feature flag:
   • Name: BetaFeature
   • Enabled: false You now have a central switch. Read the full tutorial about Feature Manager Azure App Configuration.

Step 3: Add Connection String

In appsettings.json:

12345
{  "AzureAppConfig": {    "ConnectionString": "<YOUR_CONNECTION_STRING>"  }}

In real projects, this belongs in Key Vault or environment variables.

Step 4: Configure Program.cs

This is the part most examples skip or oversimplify.

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556
using Microsoft.FeatureManagement;using Microsoft.Extensions.Configuration.AzureAppConfiguration; var builder = WebApplication.CreateBuilder(args); // 1. Connect to Azure App Configurationbuilder.Host.ConfigureAppConfiguration(config =>{    var settings = config.Build();    config.AddAzureAppConfiguration(options =>    {        options            .Connect(settings["AzureAppConfig:ConnectionString"])            // Register feature flags            .UseFeatureFlags(featureOptions =>            {                featureOptions.CacheExpirationInterval =                    TimeSpan.FromSeconds(10);            })            // Register refresh with a sentinel key            .ConfigureRefresh(refresh =>            {                refresh                    .Register("FeatureFlags:Sentinel", true)                    .SetCacheExpiration(                        TimeSpan.FromSeconds(10));            });    });}); // 2. Add Feature Managementbuilder.Services.AddFeatureManagement(); // 3. Add Azure App Config refresh middlewarebuilder.Services.AddAzureAppConfiguration(); var app = builder.Build(); // Enable refresh middlewareapp.UseAzureAppConfiguration(); app.MapGet("/", () =>    "Feature Flags Demo is running"); // Feature-gated endpointapp.MapGet("/beta", async (IFeatureManager featureManager) =>{    if (await featureManager.IsEnabledAsync("BetaFeature"))    {        return Results.Ok("Beta feature is ENABLED");    }     return Results.Ok("Beta feature is DISABLED");}); app.Run();

Step 5: (Optional but Recommended) Sentinel Key

In Azure App Configuration:

Create a key-value pair:

• Key: FeatureFlags:Sentinel
• Value: any string (e.g. timestamp)

Whenever you update this value:

• all feature flags refresh
• no restart
• no redeploy

Step 6: See It in Action

Run the app and call GET /beta → ❌ disabled Enable BetaFeature in the Azure Portal Wait ~10 seconds Call /beta again → 🚀 enabled

No redeploy. No restart. No pipeline.

Important Production Gotcha: Caching

Azure App Configuration does cache values.

If you don’t configure refresh:

• changes may take minutes
• developers think “it doesn’t work”

That’s why:

• CacheExpirationInterval
• sentinel keys
• refresh middleware

matter a lot.

This is where most “Feature Flags don’t work” stories come from.

What About Multiple Instances?

This setup works perfectly with:

• multiple app instances
• load balancers
• Kubernetes
• App Service scaling Because:
• flags are centralized
• decision logic is deterministic
• instances are stateless The feature decision does not depend on the instance.

3rd-Party Feature Flag Providers

Azure App Configuration is great if you’re already on Azure.

Other solid options:

• LaunchDarkly
  • enterprise-grade
• Unleash
  • open-source & self-hosted
• Flagsmith
  • SaaS or self-hosted

The provider matters less than the runtime architecture.

When Feature Flags Become a Problem

Feature Flags are powerful - but dangerous if abused:

• flags that live for years
• nested if statements everywhere
• “temporary” flags that never die Best practice:
• flags should have an owner
• flags should have a removal date
• flags should not replace versioning

Wrapping Up

Feature Flags are not about hiding code paths.

hey are about decoupling deployment from release.

If flipping a flag requires a redeploy, you didn’t gain flexibility - you added complexity.

If you want a deeper dive, I’ve already written a full article on Feature Flags in .NET with Azure Feature Management here.

More real-world .NET architecture topics coming soon 🚀 That's all from me for today.

Want to enforce clean code automatically? My Pragmatic .NET Code Rules course shows you how to set up analyzers, CI quality gates, and architecture tests - a production-ready system that keeps your codebase clean without manual reviews. Or grab the free Starter Kit to try it out.