Leveraging Azure Container Apps Labels for Environment-based Routing and Feature Testing
Azure Container Apps offers a powerful feature through labels and traffic splitting that can help developers easily manage multiple versions of an app, route traffic based on different environments, and enable controlled feature testing without disrupting live users. In this blog, we'll walk through a practical scenario where we deploy an experimental feature in a staging revision, test it with internal developers, and then switch the feature to production once it’s validated. We'll use Azure Container Apps labels and traffic splitting to achieve this seamless deployment process.
Unlocking Client-Side Configuration at Scale with Azure App Configuration and Azure Front Door
As modern apps shift more logic to the browser, Azure App Configuration now brings dynamic configuration directly to client-side applications. Through its integration with Azure Front Door, developers can deliver configuration to thousands or millions of clients with CDN-scale performance while avoiding the need to expose secrets or maintain custom proxy layers. This capability is especially important for AI-powered and agentic client applications, where model settings and behaviors often need to adjust rapidly and safely. This post introduces the new capability, what it unlocks for developers, and how to start building dynamic, configuration-driven client experiences in Azure. App Configuration for Client Applications Centralized Settings and Feature Management App Configuration gives developers a single, consistent place to define configuration settings and feature flags. Until now, this capability was used almost exclusively by server-side applications. With Azure Front Door integration, these same settings can now power modern client experiences across: Single Page Applications (React, Vue, Angular, Next.js, and others using JavaScript) Mobile/ and desktop applications with .Net MAUI JavaScript-powered UI components or embedded widgets running in browser Any browser-based application that can run JavaScript This allows developers to update configuration without redeploying the client app. CDN-Accelerated Configuration Delivery with Azure Front Door Azure Front Door enables client applications to fetch configuration using a fast, globally distributed CDN path. Developers benefit from: High-scale configuration delivery to large client populations Edge caching for fast, low-latency configuration retrieval Reduced load on your backend configuration store through CDN offloading Dedicated endpoint that exposes only the configuration subset it is scoped for. Secure and Scalable Architecture App Configuration integrates with Azure Front Door to deliver configuration to client-side apps using a simple, secure, and CDN-accelerated flow. How it works The browser calls Azure Front Door anonymously, like any CDN asset. Front Door uses managed identity to access App Configuration securely. Only selected key-values, feature flags or snapshots are exposed through Azure Front Door. No secrets or credentials are shipped to the client. Edge caching enables high throughput and low latency configuration delivery. This provides a secure and efficient design for client applications and eliminates the need for custom gateway code or proxy services. Developer Scenarios: What You Can Build CDN-delivered configuration unlocks a range of rich client application scenarios: Client-side feature rollouts for UI components A/B testing or targeted experiences using feature flags Control AI/LLM model parameters and UI behaviors through configuration Dynamically control client-side agent behavior, safety modes, and guardrail settings through configuration Consistent behavior for clients using snapshot-based configuration references These scenarios previously required custom proxies. Now, they work out-of-the-box with Azure App Configuration + Azure Front Door. End-to-End Developer Journey The workflow for enabling client-side configuration with App Configuration is simple: Define key values or feature flags in Azure App Configuration Connect App Configuration to Azure Front Door in the portal Scope configuration exposed by Front Door endpoint with key value or snapshot filter. Use the updated AppConfig JavaScript or .NET provider to connect to Front Door anonymously. Client app fetches configuration via Front Door with CDN performance Update your configuration centrally, no redeployment required To see this workflow end-to-end, check out this demo video. The video shows how to connect an App Configuration store to Azure Front Door and use the Front Door endpoint in a client application. It also demonstrates dynamic feature flag refresh as updates are made in the store. Portal Experience to connect Front Door Once you create your App Configuration store with key values and/or feature flags, you can configure the Front Door connection directly in the Azure portal. The App Configuration portal guides you through connecting a profile, creating an endpoint, and scoping which keys, labels, or snapshots will be exposed to client applications. A detailed “How-To” guide is available in the App Configuration documentation. Using the Front Door Endpoint in Client Applications JavaScript Provider Minimum version for this feature is 2.3.0-preview, get the provider from here. Add below snippet in your code to fetch the key values and/or feature flags from App Configuration through front door. import { loadFromAzureFrontDoor } from "@azure/app-configuration-provider"; const appConfig = await loadFromAzureFrontDoor("https://<your-afd-endpoint>", { featureFlagOptions: { enabled: true }, }); const yoursetting = appConfig.get("<app.yoursetting>"); .NET Provider Minimum version supporting this feature is 8.5.0-preview, get the provider from here builder.Configuration.AddAzureAppConfiguration(options => { options.ConnectAzureFrontDoor(new Uri("https://<your-afd-endpoint>")) .UseFeatureFlags(featureFlagOptions => { featureFlagOptions.Select("<yourappprefix>"); }); }); See our GitHub samples for JavaScript and .NET MAUI for complete client application setups. Notes & Limitations Feature flag scoping requires two key prefix filters, startsWith(".appconfig.featureflag") and ALL keys. Portal Telemetry feature does not reflect client-side consumption yet. This feature is in preview, and currently not supported in Azure sovereign clouds. Conclusion By combining Azure App Configuration with Azure Front Door, developers can now power a new generation of dynamic client applications. Configuration is delivered at CDN speed, securely and at scale letting you update experiences instantly, without redeployment or secret management on client side. This integration brings App Configuration’s flexibility directly to the browser, making it easier to power AI-driven interfaces, agentic workflows, and dynamic user experiences. Try client-side configuration with App Configuration today and update your apps’ behavior in real time, without any redeployments.
A seeming illogical design\test strategy?
This post is looking for answers from people in the Microsoft Edge design\testing team. I have been in IT system administration and software development for over 30 years but I just don't get your design and testing strategy specifically related to who gets to see new features and on what devices. Here is my gripe, I run Edge Canary on multiple systems, each using the same Microsoft account and none of installations exhibit\expose the same feature set. So how in the world are we suppose to be involved in validating features that say, are supposed to sync but are only exposed on one install? I can totally understand A\B testing, but the same setup should apply to the user across all their devices - either they see the feature on everything or not at all. Say for example the feature "Payment instruments are now synced across devices" that I saw appear today. This shows on just one device; this seems to me to be bluntly illogical? In another area, I have been able to set 2 rows of quicklink icons on the new tab page on all but 1 device; it is hugely inconsistent and to be honest frustrating. It would seem sensible to make the same Microsoft account get all the same testing features rather than as it seems so randomly assigned. Regardless, I am sure there are more users who would benefit from an explanation and look forward to an explanation. Lastly looking for a real explanation, not supposition. Pete
