Firebase Remote Config Now Bills by Usage. What It Means for Your Flutter App

For years, Firebase Remote Config cost nothing. Many Flutter apps use it for feature flags, forced-update checks and A/B test parameters, often without anyone thinking about volume.

On September 1, 2026, Remote Config started to bill by usage. Most apps still pay nothing. Bigger apps now get a bill that grows with their user count, and some free-plan apps will see config updates silently stop. This post explains the new rules, shows how to estimate your own number, and shows how to keep your feature code independent of the vendor.

The new pricing

All numbers below come from the Remote Config pricing page.

Plan	Daily fetch requests	Price
Spark (free)	up to 100,000	no cost
Blaze (pay as you go)	first 100,000	no cost
Blaze	100,001 to 10,000,000	$0.06 per 10,000
Blaze	above 10,000,000	$0.01 per 10,000

The limit is per project and per day. Every feature stays included on both plans: personalization, rollouts and the A/B Testing integration.

What counts as a fetch

A fetch is a request that the Remote Config client SDK or the REST API sends to the Remote Config service. Two details matter:

• Realtime Remote Config counts. When the server pushes an invalidation, the download that follows on each device is a billed fetch.
• Cached values do not count. When your app reads a value that is already on the device, there is no network call and no charge.

Fetches made inside other Firebase products do not count.

Grace periods and throttling

Projects that used Remote Config before September 1 got time to adjust:

• Existing Spark projects have until December 1, 2026. Upgrade to Blaze before November 15 and the grace period extends to five months.
• Existing Blaze projects have until February 1, 2027.

After that, a free project that goes over 100,000 fetches in a day gets a 30-day grace period. Throttling starts on day 31. Requests above the cap are dropped, so some users stop receiving new config values. Your app does not crash. It keeps the last values it activated, which can be weeks old. That is the failure to watch for, because nobody gets an error.

Estimate your own number

The useful number is fetches per day: daily active users multiplied by fetches per user per day.

Fetches per user depend on your minimum fetch interval and on how often people open the app. Firebase recommends an interval of 12 hours. With that interval, a user who opens the app in the morning and in the evening makes about two fetches a day.

An example, with numbers chosen for illustration:

• 50,000 daily users at two fetches each is 100,000 fetches. That is exactly the free limit.
• 500,000 daily users at two fetches each is 1,000,000 fetches. 900,000 are billed at $0.06 per 10,000, which is $5.40 a day, or about $162 for a 30-day month.

The interval moves the result more than anything else. An interval of one hour, used by an app that people open many times a day, can multiply fetches per user several times. Check your real volume in the Google Cloud console under Quotas & System Limits for firebaseremoteconfig.googleapis.com before you guess.

Lower the count

Firebase suggests three changes. All of them are small.

1. Fetch for the next session. Activate the cached values at startup, then fetch in the background with a 12 to 24 hour interval. The new values apply on the next launch.
2. Fetch on purpose. Tie a fetch to a user action that needs fresh values, such as opening a checkout screen. Do not fetch on every lifecycle event.
3. Use Realtime only where you need it. Each realtime update triggers a billed fetch on every connected device. Keep it for flags that must change within minutes, such as a kill switch.

Keep the vendor behind a contract

The pricing change is a reminder that a vendor can change its terms, and that you cannot control when. The cost of that change depends on how much of your code knows the vendor's name.

In an app generated by Archipelago, feature code never imports firebase_remote_config. It talks to a small contract in feature_flag_api:

final enabled = await flags.isEnabled(
  flagKey: 'new_checkout',
  defaultValue: false,
);

The Remote Config provider is one implementation of that contract, in its own package. You choose the vendor when you generate the project, and you can set the fetch interval where the provider is created:

FirebaseRemoteConfigFeatureFlagProvider(
  minimumFetchInterval: const Duration(hours: 12),
);

A manager in feature_flag_impl (the feature_flag_sdk brick) asks the providers in priority order, caches results, and returns the defaultValue from the call site when every provider fails. A debug override from the in-app debugger sits in front of all of them. Because of that structure, three changes stay local:

• Changing the interval is a one-line change in one package.
• Adding a second provider, for example a self-hosted Flagr server, means registering it next to Remote Config. Feature code does not change.
• Leaving Remote Config means removing one package and one registration.

Should you leave Remote Config?

For most apps, no. Under about 50,000 daily users with a sensible interval, Remote Config is still free, and its console and A/B testing integration are good.

Review it when two things are true: your daily fetches are well above 100,000, and you use Remote Config mostly as a simple on/off flag store. In that case a self-hosted flag service can cost less than the bill. The deciding factor is the cost of running that service, not the price per fetch.

Whatever you decide, first check your interval. It is the cheapest change, and it applies whichever vendor you use.

The feature_flag_sdk brick keeps the vendor behind one contract. See the brick catalogue and pricing.