Skip to main content
On this page

​
Coverage by target cloud

​
How the targets compare

Each row compares a capability of AppConfig with its adaptation on each target. A dash means this row is not stated for that target.

​
Infrastructure-only adaptation

​
On Google Cloud, OCI, and Private Kubernetes

​
How it works

This target replaces the AppConfig agent with Flagsmith, an open-source feature-flag and configuration server on the appliance’s Kubernetes cluster. Update application reads to use the Flagsmith SDK or REST API for each flag’s enabled state and value. At deployment, Tensor9 creates flags and remote-configuration values from the AWS.AppConfig.FeatureFlags JSON document. AppConfig’s staged rollout, deployment monitoring and automatic rollback are unsupported; implement those release controls in your deployment process.
Before: on AWS the application reads flags and configuration from the AppConfig agent, which fetches them from AWS AppConfig. After: in the target cloud the same application reads the same flags through the Flagsmith SDK from a self-hosted Flagsmith server running on the appliance's cluster.Before: on AWS the application reads flags and configuration from the AppConfig agent, which fetches them from AWS AppConfig. After: in the target cloud the same application reads the same flags through the Flagsmith SDK from a self-hosted Flagsmith server running on the appliance's cluster.

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.
Architecture: on the appliance cluster the application reads flags from a Flagsmith server Deployment, which stores its state in an in-cluster Postgres StatefulSet. At deploy time a provisioning step reads the AppConfig configuration document and creates the flags in Flagsmith through its admin API.Architecture: on the appliance cluster the application reads flags from a Flagsmith server Deployment, which stores its state in an in-cluster Postgres StatefulSet. At deploy time a provisioning step reads the AppConfig configuration document and creates the flags in Flagsmith through its admin API.

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.
An AWS.AppConfig.FeatureFlags document has a values map, one entry per flag with an enabled boolean and typed attributes. Each entry becomes a Flagsmith flag that keeps its enabled state and value; the typed-attribute schema is not enforced by Flagsmith.An AWS.AppConfig.FeatureFlags document has a values map, one entry per flag with an enabled boolean and typed attributes. Each entry becomes a Flagsmith flag that keeps its enabled state and value; the typed-attribute schema is not enforced by Flagsmith.

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

​
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.
Before: on AWS the application reads flags and configuration from the AppConfig agent, which fetches them from AWS AppConfig. After: in Azure subscription the same application reads the same flags through the Azure App Configuration SDK from a native, Microsoft-managed App Configuration store.Before: on AWS the application reads flags and configuration from the AppConfig agent, which fetches them from AWS AppConfig. After: in Azure subscription the same application reads the same flags through the Azure App Configuration SDK from a native, Microsoft-managed App Configuration store.

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.
Architecture: in Azure subscription the application reads from a Microsoft-managed App Configuration store through the App Configuration SDK. Terraform provisions the store, one native feature flag per AppConfig flag, and one key-value per free-form key, from the AppConfig configuration document. No runtime component sits in the read path.Architecture: in Azure subscription the application reads from a Microsoft-managed App Configuration store through the App Configuration SDK. Terraform provisions the store, one native feature flag per AppConfig flag, and one key-value per free-form key, from the AppConfig configuration document. No runtime component sits 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.
An AWS.AppConfig.FeatureFlags document has a values map, one entry per flag with an enabled boolean and typed attributes. Each entry becomes a native App Configuration feature flag whose enabled state and value both survive; free-form JSON keys become key-values.An AWS.AppConfig.FeatureFlags document has a values map, one entry per flag with an enabled boolean and typed attributes. Each entry becomes a native App Configuration feature flag whose enabled state and value both survive; free-form JSON keys become key-values.

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.