The application reads flag state and values through the Flagsmith SDK or REST API. Flagsmith runs on the appliance cluster.
#### Architecture Terraform creates a Flagsmith Kubernetes Deployment on port 8000 and a PostgreSQL StatefulSet with a persistent volume. A ClusterIP Service exposes Flagsmith to the application; a headless Service exposes PostgreSQL to Flagsmith. PostgreSQL stores flag state and values, which Flagsmith evaluates when the SDK refreshes its data. A provisioning step reads the AppConfig document and creates flags through the Flagsmith administration API before the application starts reading them. After provisioning, the application reads the running Flagsmith service. Your platform team operates Flagsmith and PostgreSQL, including availability, capacity, backups and upgrades.
The Flagsmith server and its Postgres run on the appliance cluster; a one-time provisioning step at deploy creates the flags from the AppConfig configuration document, and the application reads from the server after that.
#### Creating flags from the configuration document An `AWS.AppConfig.FeatureFlags` profile has a top-level `values` map, one entry per flag, each with an `enabled` boolean and optional typed attributes. The provisioning step walks that map and creates one Flagsmith flag per entry: the flag's on/off state maps to Flagsmith's enabled state, and a flag's attributes become its remote-config value. A configuration profile that holds free-form JSON rather than feature flags becomes remote-config values on the same Flagsmith environment. AppConfig validates feature-flag attributes against declared types and constraints. Flagsmith stores the translated values but does not apply that schema. Validate content before provisioning or editing flags so future values meet your application's expectations.
Each AWS.AppConfig.FeatureFlags entry becomes a Flagsmith flag; its enabled state and typed value come with it, and free-form configuration becomes remote-config values.
#### Reading flag state and values Flagsmith returns a flag's enabled state and its associated configuration value, such as a rollout percentage, variant name or tuning constant. Update application integration to the Flagsmith SDK while preserving how the application uses those values. #### Per-environment targeting An AppConfig application maps to a Flagsmith project, and each AppConfig environment maps to a Flagsmith environment. Environments such as staging and production keep independent states and values for the project's flags. AppConfig configuration profiles, profile versions and deployment history are not recreated. The target contains the provisioned flag state. Keep the source document and change history in the system that provisions Flagsmith. #### Reading at runtime Replace reads from the AppConfig agent's loopback address with the Flagsmith SDK or REST API for the in-cluster server. The SDK caches the environment's flags and refreshes periodically; reads against that cache do not require a request per flag. Configure the Flagsmith SDK with the server URL and the appropriate environment key. The native SDK uses that key; cluster workload identity does not replace Flagsmith authentication. Size Flagsmith and PostgreSQL for refresh traffic. Choose cache settings based on how long the application can tolerate stale flags during a server interruption. #### Replacing rollout and rollback controls This target provisions current flag values but does not recreate AppConfig deployment strategies, deployment monitoring or validators. Add the following controls to your release process where your application requires them. * **Staged rollout.** An AppConfig deployment strategy ramps a new value to a growing fraction of the fleet over a bake window (a growth factor, a growth type, a final bake time). Flagsmith flips a flag for the whole environment at once. To stage a Flagsmith rollout, drive it from the percentage-split value the application reads, changed on a schedule by the provisioning process. * **Monitored, rollback-capable deployment.** An AppConfig deployment is an object with a lifecycle that can be halted and rolled back. Flagsmith has no deployment object; a rollback is republishing the prior flag value. Keep the prior value recoverable in the provisioning pipeline so a revert is one step. * **Automatic rollback on an alarm.** AppConfig reverts a deployment automatically when a bound CloudWatch alarm fires during the bake. Flagsmith does not watch a metric. Reproduce this as a pipeline that watches the signal and republishes the prior value on a bad reading. * **Pre-deploy validators.** AppConfig can block a new version on a JSON-Schema or Lambda validator before it ships. Flagsmith enforces no validator on a flag change. Run that validation in CI, on the flag content, before it is provisioned. #### Other considerations * **Provision the final AppConfig state.** Flagsmith is initialized from the configuration document at deployment. If AppConfig changes during cutover, update that document before provisioning so the target receives the intended final values. * **Operate Flagsmith and its database.** The appliance hosts the server, PostgreSQL and their Kubernetes Services. Your team manages cluster capacity and patching, Flagsmith upgrades and database backups. ## On Azure | Operation | Area | Support | Depth | Notes | | -------------------------------------- | ------------------- | ------------ | ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------- | | GetLatestConfiguration | Config reads | Supported | Common | polls the current flags and values; served as an App Configuration SDK read of the store's keys and feature flags for the workload's label | | StartConfigurationSession | Config reads | Supported | Common | the application opens a flag / config read session; served by the Azure App Configuration SDK client instead of the AppConfig agent | | CreateDeploymentStrategy | Deployment controls | Out of scope | Full surface | the staged bake / growth / final-bake ramp has no App Configuration analog; the rollout schedule is a CI / pipeline responsibility | | Deployment validators + alarm rollback | Deployment controls | Out of scope | Full surface | JSON-Schema / Lambda validators and CloudWatch-alarm automatic rollback have no counterpart; validation and revert move to CI / pipeline | | StartDeployment / StopDeployment | Deployment controls | Out of scope | Full surface | no managed deployment object; the store's key-value revision history keeps the prior value recoverable, but the revert is a manual or pipeline step | | Feature flag enabled state | Feature flags | Supported | Common | a flag's on/off state reads back through the native App Configuration feature-flag SDK | | Feature flag typed value | Feature flags | Supported | Most usage | the value is kept on the native feature flag; App Configuration does not enforce the AWS.AppConfig.FeatureFlags attribute schema | | CreateApplication / CreateEnvironment | Provisioning | Partial | Most usage | the environment dimension maps to App Configuration labels; the AppConfig application and configuration-profile hierarchy is not recreated | | CreateConfigurationProfile | Provisioning | Supported | Most usage | a feature-flag profile becomes native feature flags; a free-form profile becomes key-values | | CreateHostedConfigurationVersion | Provisioning | Supported | Most usage | the configuration document is the source Terraform provisions the store's entries from | #### How it works Azure App Configuration replaces the AppConfig agent as the source of feature flags and dynamic configuration. Update application reads to use the Azure App Configuration SDK against the managed store in the customer's subscription. Terraform provisions feature flags and key-values from the `AWS.AppConfig.FeatureFlags` document. AppConfig's staged rollout, deployment monitoring and automatic rollback are not recreated; implement those controls in the process that publishes configuration changes.
The application reads flag state and values through the Azure App Configuration SDK. Microsoft operates the configuration store.
#### Architecture The compiler emits an `azurerm_app_configuration` store in the target subscription, one `azurerm_app_configuration_feature` for each AppConfig feature flag, and one `azurerm_app_configuration_key` for each free-form configuration key. Terraform provisions all of them from the AppConfig configuration document at apply time. The store is a managed Azure service: Microsoft runs its storage, replication, and availability, and the flags and values live in the customer's own store. The application connects directly to Azure App Configuration using its SDK and the workload's Azure identity. Terraform provisions configuration, so there is no Tensor9 adapter in the read path.
Terraform provisions the App Configuration store, one native feature flag per AppConfig flag, and one key-value per free-form key; the application reads through the SDK, and no runtime component sits in the path.
#### Creating flags and configuration keys An `AWS.AppConfig.FeatureFlags` profile has a top-level `values` map, one entry per flag, each with an `enabled` boolean and optional typed attributes. Terraform walks that map and provisions one native App Configuration feature flag per entry: the flag's on/off state maps to the feature flag's enabled state, and its attributes supply the flag's value. A configuration profile that holds free-form JSON rather than feature flags is provisioned as key-values in the same store, one per top-level key. Azure App Configuration stores translated values but does not apply AppConfig's declared attribute types and constraints. Validate new content before provisioning it so future edits remain compatible with the application.
Each AWS.AppConfig.FeatureFlags entry becomes a native App Configuration feature flag; it retains its enabled state and typed value, and free-form configuration becomes key-values.
#### Reading feature flags and configuration Feature flags use App Configuration's feature-flag key convention and content type. The Azure SDK and Feature Management libraries read their enabled state and any associated value. Free-form configuration uses regular key-values. * **Enabled state.** The SDK reads the flag's boolean state, corresponding to the AppConfig enabled field. * **Typed values are preserved.** AppConfig's typed attributes become the feature flag's value. The application reads the value; App Configuration does not enforce the attribute type or its constraints, so that discipline lives wherever the flag content is authored. * **Free-form config shares the store.** A non-flag configuration profile is provisioned as key-values in the same store, so a workload that mixes feature flags with dynamic configuration reads both from one place through one SDK. * **SSM configuration can use the same store.** SSM Parameter Store maps to Azure App Configuration key-values. AppConfig feature flags use feature-flag entries, allowing the SDK to distinguish them from ordinary configuration values. #### Per-environment targeting AppConfig scopes configuration by application and environment: the same flag can be on in one environment and off in another. App Configuration expresses the environment dimension with labels. A key or feature flag can hold a different value per label, and the SDK selects a label at read time, so one store serves several environments and the application reads the value for its own. The AppConfig environment maps onto the label the workload reads. AppConfig profile versions and deployment history are not imported. The target stores current values by label and maintains its own key-value revision history. Keep the AppConfig source history in the system that provisions the store. #### Reading at runtime Replace reads from the AppConfig agent's loopback address with Azure App Configuration SDK reads for the workload's environment label. The SDK caches keys and flags and refreshes on an interval or change signal; reads against that cache do not require a network request per value. The SDK authenticates with the workload's Azure identity, without a separate credential for this path. Microsoft operates store availability, replication and patching. Your team selects the store tier, access policy and client cache settings. #### Replacing rollout and rollback controls This target provisions current configuration but does not recreate AppConfig deployment strategies, monitored deployment objects or validators. Add the following controls to your release process where required. * **Staged rollout.** An AppConfig deployment strategy ramps a new value to a growing fraction of the fleet over a bake window (a growth factor, a growth type, a final bake time). App Configuration serves the current value of a key or flag with no managed ramp. To stage a rollout, drive it from a percentage value the application reads, changed on a schedule by whatever provisions the store. * **Monitored, rollback-capable deployment.** An AppConfig deployment is an object with a lifecycle that can be halted and rolled back. App Configuration has no deployment object; a rollback is republishing the prior value (its key-value revision history makes the prior value recoverable, but the revert is a manual or pipeline step, not an automatic one). * **Automatic rollback on an alarm.** AppConfig reverts a deployment automatically when a bound CloudWatch alarm fires during the bake. App Configuration does not watch a metric. Reproduce this as a pipeline that watches the signal and republishes the prior value on a bad reading. * **Pre-deploy validators.** AppConfig can block a new version on a JSON-Schema or Lambda validator before it ships. App Configuration enforces no validator on a value change. Run that validation in CI, on the flag content, before it is provisioned. Run validation, staged updates and monitoring-driven reverts in the process that provisions the store. Include these controls in the migration plan alongside the SDK change. #### Other considerations * **Provision the final AppConfig state.** Terraform creates flags and key-values from the configuration document. If AppConfig changes during cutover, update the document before applying Terraform. * **Operations and ownership.** App Configuration is a managed Azure service, so its storage, replication, and availability are Microsoft's to run; there is no self-hosted server and no Tensor9 runtime component to operate. What remains operational is the surrounding platform: the Azure subscription, the store's SKU and access policy, and the identity the workload reads with. [Service Catalog](/service-adapters/catalog).