Deploying new features directly to production can introduce significant risks. If a bug is discovered after deployment, rolling back an entire application may be time-consuming and disruptive.
Feature flags (also known as feature toggles) allow developers to deploy code to production while controlling feature availability without redeploying the application. This enables gradual rollouts, A/B testing, canary releases, and quick feature rollbacks.
In this article, you'll learn how to implement feature flags in ASP.NET Core 11 using Microsoft Feature Management, explore common rollout strategies, and understand how to validate feature behavior in production.
Note: This article focuses on implementation patterns and testing methodology. It does not include fabricated performance benchmarks.
What Are Feature Flags?
A feature flag is a conditional switch that determines whether a feature is enabled.
Without feature flags:
Deploy New Feature
│
▼
All Users Receive It
With feature flags:
Deploy New Feature
│
▼
Feature Flag Evaluation
│
┌────┴────┐
▼ ▼
Enabled Disabled
The feature exists in production but is available only to selected users or environments.
Benefits of Feature Flags
Feature flags enable teams to:
Deploy features independently of releases
Perform gradual rollouts
Instantly disable problematic features
Conduct A/B testing
Enable beta testing
Reduce deployment risk
Support continuous delivery
Create the Project
dotnet new webapi -n FeatureFlagsDemo
Install the Feature Management package.
dotnet add package Microsoft.FeatureManagement.AspNetCore
Configure Feature Management
Register Feature Management services.
builder.Services.AddFeatureManagement();
Define Feature Flags
Configure features in appsettings.json.
{
"FeatureManagement": {
"NewCheckout": true,
"DarkMode": false
}
}
Each feature can be enabled or disabled independently.
Inject the Feature Manager
using Microsoft.FeatureManagement;
public class ProductService
{
private readonly IFeatureManager _featureManager;
public ProductService(
IFeatureManager featureManager)
{
_featureManager = featureManager;
}
}
Check Whether a Feature Is Enabled
if (await _featureManager.IsEnabledAsync("NewCheckout"))
{
// Execute new implementation
}
else
{
// Execute existing implementation
}
This allows both implementations to coexist during rollout.
Protect an Endpoint
Use the FeatureGate attribute.
using Microsoft.FeatureManagement.Mvc;
[FeatureGate("NewCheckout")]
[ApiController]
[Route("api/checkout")]
public class CheckoutController : ControllerBase
{
[HttpGet]
public IActionResult Get()
{
return Ok("New Checkout");
}
}
Requests automatically receive a 404 Not Found response when the feature is disabled.
Percentage-Based Rollout
Gradually expose a feature to a percentage of users.
{
"FeatureManagement": {
"NewCheckout": {
"EnabledFor": [
{
"Name": "Percentage",
"Parameters": {
"Value": 20
}
}
]
}
}
}
Only approximately 20% of users receive the new feature.
This strategy minimizes deployment risk.
Time-Based Activation
Enable a feature automatically after a specific date.
{
"FeatureManagement": {
"HolidaySale": {
"EnabledFor": [
{
"Name": "TimeWindow",
"Parameters": {
"Start": "2026-12-01T00:00:00Z",
"End": "2026-12-31T23:59:59Z"
}
}
]
}
}
}
No redeployment is required when the activation time arrives.
Targeted Rollouts
Feature flags can also target:
Specific users
User groups
Tenants
Regions
Subscription plans
Beta testers
This enables controlled releases before full deployment.
Feature Evaluation Flow
A typical request follows these steps:
Client sends a request.
ASP.NET Core evaluates the feature flag.
Feature filters determine whether the feature is enabled.
If enabled, the new implementation executes.
Otherwise, the existing implementation continues.
The response is returned.
This process allows safe experimentation without affecting all users.
Common Rollout Strategies
| Strategy | Best For |
|---|
| On/Off | Immediate enable or disable |
| Percentage rollout | Gradual deployment |
| Time window | Scheduled launches |
| User targeting | Beta testing |
| Tenant targeting | Multi-tenant applications |
Different strategies can be combined for more sophisticated deployment workflows.
Testing Methodology
Feature flags primarily improve deployment safety rather than runtime performance.
Test Environment
Maintain consistency for:
.NET SDK version
Configuration provider
Hosting environment
User identity
Feature configuration
Test Scenarios
Evaluate:
Metrics to Observe
Monitor:
Useful Tools
Useful tools include:
Azure App Configuration
Application Insights
OpenTelemetry
Serilog
Grafana
Prometheus
Monitor feature adoption throughout the rollout process.
Best Practices
Keep feature flags focused on a single capability.
Remove obsolete flags after rollout.
Name flags consistently.
Test both enabled and disabled paths.
Use gradual rollouts for high-risk features.
Monitor feature-specific metrics.
Document feature ownership.
Store configuration outside application code for production environments.
Common Mistakes
| Mistake | Impact |
|---|
| Leaving old feature flags indefinitely | Increased code complexity |
| Nesting multiple feature flags | Difficult maintenance |
| Using feature flags for configuration | Incorrect responsibility |
| Never testing the disabled path | Hidden production issues |
| Enabling features for all users immediately | Higher deployment risk |
| Ignoring monitoring during rollout | Delayed issue detection |
Troubleshooting
Feature Never Enables
Verify:
Endpoint Returns 404
Review:
Percentage Rollout Appears Inconsistent
Remember that percentage filters evaluate users individually. Different users may receive different results based on the configured rollout strategy.
FAQs
What is the difference between deployment and release?
Deployment moves code to production, while release makes a feature available to users. Feature flags allow these activities to happen independently.
Should feature flags be permanent?
No. Once a rollout is complete and stable, obsolete feature flags should be removed to reduce maintenance overhead.
Can feature flags be changed without redeployment?
Yes. When backed by a dynamic configuration provider such as Azure App Configuration, feature states can be updated without redeploying the application.
Are feature flags suitable for A/B testing?
Yes. Percentage-based and targeted rollouts make feature flags well suited for controlled experiments and gradual feature validation.
Do feature flags affect performance?
The evaluation overhead is typically minimal compared to database access or network operations. However, complex feature evaluation logic should still be monitored in high-throughput applications.
Conclusion
Feature flags provide a safe and flexible way to deliver new functionality in ASP.NET Core applications. By separating deployment from release, they reduce risk, support progressive rollouts, and enable rapid rollback without requiring a new deployment.
When combined with thoughtful rollout strategies, monitoring, and regular cleanup of obsolete flags, feature flags become a valuable part of a modern continuous delivery workflow for production-ready .NET applications.