9 remote configuration services for 2026: an honest comparison

If you want to change how your application behaves at runtime (e.g. a rate limit, a cache TTL, a model name, a price) without deploying anything, the category you’re shopping in is called remote configuration. The category was mostly established by Firebase Remote Config but, today, there are many Configuration-as-a-Service (CaaS) vendors to choose from. In this article, we review 9 of them.

Two names to rule out before we start, because the search terrain here is genuinely bad:

1. Configuration management belongs to Ansible, Puppet, and the CMDB people - that’s provisioning servers, a different universe that happens to share a noun.
2. Secrets management like Doppler and Vault are the adjacent-but-different case: they hand your process credentials when it starts.

Remote config is about values your application reads while it runs, from a service that can change them while it runs.

Full disclosure: I build one of the services on this list: Smpl Config. I’ve put it where I think it belongs and said where I think the others are stronger.

Two classes of vendor

It’s part of your platform

AWS AppConfig, Azure App Configuration, and Firebase Remote Config live here. Nobody signs up for AWS to get AppConfig; you reach for it because your workloads are already there and the IAM roles are already wired. These services inherit their platform’s strengths (e.g. billing, permissions, compliance) and also its assumptions: polling, per-request metering, and identity handled by the mothership.

You choose it on purpose

ConfigCat, Flagsmith, LaunchDarkly, Reforge Launch, Smpl Config, and Statsig live here. They’re cloud-neutral, SDK-first, and you choose them on purpose. Most grew up as feature-flag platforms and added config values along the way; a couple treat config as the headline product. The differences hide in the value model - whether “config” means a typed value, a JSON blob, or are you really just using feature flags for configuration.

Config-first or flag-first

Cutting across those two classes is a second split, and it matters more: what the product was built around.

• AWS AppConfig, Azure App Configuration, Firebase Remote Config, Reforge Launch, and Smpl Config are config-first.
• ConfigCat, Flagsmith, LaunchDarkly, and Statsig are flag-first, with config values added to an engine that was built to evaluate flags.

That isn’t a purity test, it’s a question about failure. A feature flag SDK ships with a default sitting in your code, so an unreachable service means you evaluate the default and keep going. The graceful degradation is the design. Bootstrap configuration inverts it: if your JDBC connection string lives in the service and the service isn’t there, your process doesn’t degrade, it fails to start. Storing your database credentials in something engineered to be safely absent would be ill-advised.

But you can make do with a flag-first product. LaunchDarkly’s Relay Proxy and file-data modes exist precisely so that you can, and AWS’s agent caches to local disk for the same reason. But “making do” is the right description for it. If a friend asked me what solutions to consider for centralized configuration management, I would not tell them to store their configuration as feature flags.

With that out of the way, on with the review!

The field at a glance

Service	Type	Typed values	JSON types	Environments	Push updates	Client-side SDK
AWS AppConfig	Config-first	⚠︎ Flags only	✓	✓	✗	✗
Azure App Configuration	Config-first	✗	✗	✗	✗	✗
ConfigCat	Flag-first	✓	✗	✓	✗	✓
Firebase Remote Config	Config-first	✓	✓	✗	⚠︎ Clients only	✓
Flagsmith	Flag-first	✓	✓	✓	✓	✓
LaunchDarkly	Flag-first	✓	✓	✓	✓	✓
Reforge Launch	Config-first	✓	✓	✓	✓	✓
Smpl Config	Config-first	✓	✓	✓	✓	✓
Statsig	Flag-first	✗	✓	✓	✗	✓

One thing deliberately left off: role-based access control, the “who is allowed to change this in production” question. Every vendor here has an answer, so a column of eight checkmarks would have told you nothing. AWS and Azure lean on the cloud’s own IAM, Firebase ships Remote Config Admin and Viewer roles, and ConfigCat, Flagsmith, LaunchDarkly, Statsig, and Smpl Config all have permission groups or roles of their own. Reforge Launch is the exception, and only in the sense that its documentation doesn’t cover permissions either way.

Propagation: how a change actually reaches your process

Every service here agrees on the goal (i.e. new value, no deploy) and splits on the mechanics.

• Pollers fetch on a timer: simple, cache-friendly, and your freshness is your interval.
• Streamers hold a connection open (SSE or WebSocket) and push the change when it happens. Neither is virtuous by itself; a 10-second poll beats a stream that reconnects badly. But the defaults tell you who a product was built for.

Service	Delivery	Default freshness	Push reaches
AWS AppConfig	Poll	Whatever interval you poll at	Nowhere
Azure App Configuration	Poll	~30 seconds in Microsoft's own examples	Nowhere
ConfigCat	Poll	60 seconds	Nowhere
Firebase Remote Config	Stream+Poll	12 hours on clients by default; the real-time listener bypasses it	Clients
Flagsmith	Poll+ Stream	60 seconds (local evaluation)	Servers and clients
LaunchDarkly	Stream	On change	Servers and clients
Reforge Launch	Stream	On change	Servers and clients
Smpl Config	Stream	On change	Servers
Statsig	Poll	10 seconds (server SDKs)	Nowhere

Vendors' propagation numbers are claims, and this article reports them accordingly.

Category 1: It’s part of your platform

AWS AppConfig

AWS AppConfig treats a config change the way the rest of AWS treats a code change: as a deployment. You pick a strategy (e.g. grow 20% of targets at a time, bake for a while, watch a CloudWatch alarm), and a bad value rolls itself back before it finishes shipping. That’s the personality of the product, and it’s a good one.

Feature-flag profiles get typed attributes with real constraints (regex, ranges, enums); freeform configs are JSON, YAML, or text documents with no per-key type, though you can attach up to two validators (an inline JSON Schema, a Lambda, or one of each) and a deployment won’t proceed unless the data passes them. History is native: every save to the hosted configuration store is a numbered version you can label, list, and redeploy, and deployments are recorded per environment. The who-and-when lives in CloudTrail rather than in a change view inside the product.

Retrieval is polling, usually through an agent you run beside your code, and every poll is billed: 20 cents per million requests plus 80 cents per thousand configurations delivered. AWS’s own pricing example (2,000 servers polling every two minutes) works out to $152.64 a month. There’s no free tier and no push. Best when you’re already on AWS and the thing you fear is a bad config change, not the polling bill.

Azure App Configuration

Azure App Configuration is a centralized key-value store with real operational maturity: 30-day revision history with point-in-time restore, snapshots, soft delete, geo-replication, and a flat bill - the Standard tier is $1.20 per store per day, about $36 a month, with 200,000 requests a day included.

Values are strings. All of them. A contentType field can remind you that a string is secretly JSON, but nothing enforces it; typing is your application’s problem. Targeting exists only on the feature-flag surface, via a Targeting filter in the feature management libraries; a plain key-value gets none of it.

Environments are done with labels, and permissions are store-scoped, so the documented answer to keeping staging hands off production is a separate store per environment - each with its own daily charge. Refresh is polling against a sentinel key, roughly every 30 seconds in Microsoft’s examples; a push mode exists for .NET and Spring via Event Grid, and the Spring docs file it under “not recommended.” Best for .NET and Java shops on Azure that want boring, durable, centrally managed config and don’t need typed values or user targeting.

Firebase Remote Config

Firebase Remote Config is the category’s center of gravity for a reason. If your surface is a mobile app, the targeting is superb: conditions across 18 rule types, Google Analytics audiences, ML-driven per-user personalization, A/B testing wired straight into Analytics, and real-time streaming updates on Android, Apple, and Flutter. (Client templates reach Web, Unity, and C++ too, but the real-time listener doesn’t; those platforms fetch.)

Parameters carry a declared type in the console, but it’s validated at publish time, not enforced at retrieval; your get call does the casting. Server-side is a different story: officially a Preview, limited to the Admin SDKs in Node.js, Python, Go, and Java, with no streaming - you re-download the template on a timer.

There’s no environments concept either; Google’s guidance for dev/staging/prod is three separate Firebase projects, promoted by hand. Version history caps at 300 lifetime versions and there are no approvals - anyone with console access ships to production. And the free lunch is ending: from September 1, 2026, fetches beyond 100,000 a day bill at six cents per 10,000. Best when you’re building a mobile app, which is exactly what it’s for.

Category 2: Configuration as a Service

ConfigCat

ConfigCat sells flags and config as one product with one refreshingly flat idea: every feature on every plan (e.g. unlimited seats everywhere, SAML included on the free tier), and plans differ only in quotas.

Settings are typed (boolean, string, integer, double) with targeting rules and percentage rollouts on any custom user attribute, served from a CDN your SDK polls every 60 seconds by default, with SDKs for 17 platforms and a proper offline/override story. There’s no JSON setting type; since July 2026 a text setting can be required to validate as JSON, which is most of the way there as long as your app does the parsing.

The free tier’s 10 settings go quickly if you’re doing config rather than a handful of flags; Pro is $110 a month ($95 billed annually) for 100 settings and three environments. Scheduled changes still aren’t native - ConfigCat’s own blog suggests the public API plus cron, and if you go that route we have opinions about cron services. Best when you want flags-plus-config economics an entire team can log into without a seat-count negotiation.

Flagsmith

Flagsmith has the richest value model among the flag-first products here: a flag carries an on/off state plus a typed value (string, number, boolean, or JSON) with multivariate variants and segment targeting on identity traits. It’s also the one open-source option in this lineup (BSD-3-Clause, self-hosted via Docker Compose), which is the sturdiest possible answer to “what happens if the config service goes away.”

The SaaS tiers claw a fair amount back, though: real-time SSE updates require an Enterprise plan, audit logs arrive with Scale-Up governance at $300 a month, and as of this writing the pricing page says scheduled flags come with Start-Up while the docs say Scale-Up and Enterprise. We’ll let them settle it. Free is 50,000 requests a month with one seat; Start-Up is $45 a month for a million requests and three seats. Best when open source or self-hosting is a requirement - just check that the features you need aren’t gated two tiers up.

LaunchDarkly

LaunchDarkly is the enterprise flag platform, and its remote-config story is the flag model stretched to fit: a “config” is a multivariate flag serving string, number, or JSON variations. Delivery is excellent - streaming is the default, SDKs cover 13 server-side platforms plus clients and edge runtimes, and a Relay Proxy runs in your own infrastructure if you want it. The constraint is the variation model itself: variations are a predefined set with the type locked at flag creation, so “serve a new value” means editing a named variation in the dashboard rather than writing an arbitrary value to a key.

The new thing this year is AI Configs, now GA under the AgentControl banner - runtime control of prompts and model settings, billed per AI run. It’s the closest LaunchDarkly has come to a dedicated config product, and it’s for AI workloads specifically.

The Developer tier is free with one project, three environments, and 14-day data retention; Foundation runs $10 per service connection plus $8.33 per thousand client-side MAU, billed yearly. Per-flag change history is included broadly, but the full audit log, approvals, and scheduling are Enterprise features. Best when you’re buying a flag platform for a large organization and config can live inside it as JSON variations.

Reforge Launch (formerly Prefab)

The product formerly known as Prefab is the closest thing this lineup has to another config-first platform, and it’s had an eventful stretch: acquired by Reforge in late 2024 and relaunched as Reforge Launch, with the docs now at docs.reforge.com - while the old prefab.cloud homepage redirects to Quonfig, the Prefab founder’s new product. The product underneath survived the move intact.

Config values are properly typed (string, int, double, boolean, JSON, plus exotics like duration) with per-environment values that can explicitly inherit the default, SSE push to running server SDKs, and two genuinely useful bundled extras: dynamic log levels and secrets. SDKs cover Ruby, Java, Node.js, Python, Go, and JavaScript/React; there’s no .NET.

Pricing, per the page still published at the old domain: free for up to 5 servers and around 1.5 million requests a month; Pro at $99 a month for up to 100 servers and 15 million requests. Best when you want typed config with push and dynamic logging in one tool, and .NET isn’t in your stack.

Smpl Config

Smpl Config is built around an idea the rest of this lineup skips: real inheritance. A config can declare a parent; inherited keys resolve through the chain and locally declared keys shadow them - so “every service gets these defaults, this one overrides two of them” is a data-model feature instead of a copy-paste convention. (Reforge Launch’s per-environment [inherit] is the nearest neighbor, on a different axis.)

The second idea is code-first registration, and nothing else in this lineup does it. You declare a config’s defaults in your own source, bind() them at startup, and the keys appear in the console for someone to override, with changes streaming back into the running process. Everywhere else the key has to exist in a dashboard before your code can read it.

Values are typed (string, number, boolean, JSON), and the API enforces the type on every write, including per-environment overrides. Six server SDK languages, a browser SDK (@smplkit/browser) that reads config straight from the page with a publishable read-only key - inheritance resolved locally, updates streamed over SSE - plus a CLI and a Terraform provider come with every tier, alongside unlimited servers and API requests; the free tier covers 10 configs of 25 keys each across two environments.

Now the honest part: there’s no user-level targeting - configs vary by environment, and per-user rules are Smpl Flags’ job. Change history starts on the $49 Standard tier, point-in-time restore on the $99 Pro tier, and per-environment write permissions are an Enterprise feature. If typed, inherited, push-updated configuration management is the actual job you’re hiring for, Smpl Config belongs on your shortlist.

Statsig (Dynamic Config)

Statsig’s Dynamic Config is a JSON object served through the same rule engine that powers its feature gates and experiments: target by user ID, email, country, app version, custom fields, or segments, with gradual rollouts. Typing is client-side discipline - getters take a fallback, and a fallback of the wrong type wins over the stored value, which is a sensible guard but not a schema.

Server SDKs poll every 10 seconds; push requires self-hosting their Forward Proxy. Configs cap at 100 KB, audit logs are kept indefinitely, and approval policies are an Enterprise feature. The free tier is remarkable for this use case: config checks are unmetered on every plan (the billing meter is analytics events), so a config-heavy, experiment-light team rides free for a long time.

Ownership has been busy: OpenAI acquired Statsig in September 2025, and in May 2026 the brand, platform, and customers moved to Amplitude while the founding team stayed at OpenAI. The product is live and taking signups; the roadmap is now Amplitude’s. Best when you’re running experiments anyway - it’s an experimentation platform, and Dynamic Config is one of its instruments.

Which should you pick?

Already on AWS or Azure? Use what you’re already paying for. AppConfig when what you fear is a bad config change, since it treats a config push like a production deployment. Azure App Configuration when you’re a .NET or Java shop that can live with every value being a string. Neither is the best product on this page, but neither needs a new vendor, a new bill, or a new set of credentials, and that counts for more than it sounds like it should.

Building a mobile app? Firebase Remote Config, and don’t overthink it. The targeting, the A/B testing, and the price were built for exactly you. Watch the September 2026 pricing change if your fleet is large, and don’t ask the server side to keep up.

Otherwise, we would recommend a best-of-breed Configuration as a Service. In this field, that means Reforge Launch or Smpl Config. Reforge Launch bundles dynamic log levels and secrets, so take it if those earn their keep and .NET isn’t in your stack. Take Smpl Config for typed values the API enforces on every write, configuration inheritance, a code-first programming model where a key exists because your code declared it, and a browser SDK that reads it all from the page with a publishable key.