Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

Firebase Remote Config lets a web app fetch and activate values—such as a feature flag or interface setting—that its existing code already knows how to use. It can change those values without a new client build, but it cannot deliver new application code. The basic cycle is to define defaults, fetch a configuration, then activate it when the change suits the user experience.

What Remote Config can—and cannot—change

Remote Config stores parameters and conditional values in a Firebase template. A web app using the Firebase JavaScript SDK can retrieve those values, cache them, and make them available to its code after activation. For example, code can read a parameter to show or hide an existing feature, change text, or select among layouts already implemented in the app. Firebase’s Remote Config documentation explains the client workflow.

It does not update the app’s JavaScript bundle or add behavior that the deployed code does not contain. Treat parameters as inputs to existing logic, not as a deployment mechanism or a replacement for code review and release processes.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

How fetch and activation work

Remote Config has separate steps that matter to the user experience: the app has usable defaults, requests a configuration, and then activates a fetched configuration so getters can use it. Firebase’s API reference describes activate as making the last fetched configuration available to getters. fetchAndActivate combines fetching and activation. The JavaScript API reference documents these methods.

  1. Initialize Firebase and Remote Config. Use the modular JavaScript SDK, for example initializeApp and getRemoteConfig. Firebase’s web guide also documents a compatibility API path. See the web setup guide.
  2. Set in-app defaults. Provide values in the client so the app has defined behavior before a backend fetch succeeds. Firebase also supports defaults defined in the backend template.
  3. Choose a fetch interval. Firebase documents 12 hours as both the default and recommended minimum fetch interval for production. A shorter interval can help development iteration, but repeated fetching can be throttled. If throttling occurs, Firebase recommends exponential backoff. Review the fetch settings guidance.
  4. Fetch and activate. Call fetchConfig and then activate, or use fetchAndActivate when applying the fetched values together is appropriate. A successful fetch does not itself mean the newly fetched values are already being used by getters.
  5. Decide when a change takes effect. Activation can alter behavior or appearance. Applying at app startup may suit a small feature flag; for a disruptive interface change, a team may instead wait for a natural transition. That timing is an application design choice, not a Firebase guarantee.

Target users with conditions and rollouts

Remote Config parameters are key/value pairs. Conditions can serve different values to groups of app instances. Firebase lists targeting options including app version, platform, language, country or region, Analytics audiences and user properties, user percentile, and custom signals. Analytics is required for conditional targeting based on Analytics properties and audiences, according to the web setup documentation.

Publishing a changed template creates a new version, and Firebase retains earlier versions that teams can retrieve or roll back. A staged parameter rollout can reduce the scope of a change, but it does not replace authorization checks or a complete deployment process. Firebase specifically warns against using Remote Config for app updates that should require user authorization. Read the parameter and template documentation.

Rank #2
Sale
HTML and CSS: Design and Build Websites
  • HTML CSS Design and Build Web Sites
  • Comes with secure packaging
  • It can be a gift option

Ordinary fetch or real-time updates?

Ordinary fetching follows the configured minimum interval and cache behavior. Real-time Remote Config can notify a listening app that a newer template exists, after which the SDK fetches it; the app still decides when to activate changed values.

Free tools Windows power users keep installed

One-click scans. No signup required.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Consideration Ordinary fetch Real-time listener
When an update arrives On a fetch, subject to the configured interval and cache. After a template invalidation signal prompts an automatic fetch while listening.
Activation App code controls when to activate; fetchAndActivate combines the operations. App code still chooses whether and when to activate, including after inspecting changed keys.
Requirements Standard Remote Config JavaScript SDK workflow. Firebase JavaScript SDK v12.3.0 or later, with the Remote Config Realtime API enabled.
Operational trade-off Frequent fetches can be throttled. Invalidation-triggered fetches count toward fetch limits; the open HTTP connection uses device battery.
App lifecycle Follows the app’s ordinary fetch behavior. Firebase says the connection is maintained in the foreground and the SDK automatically stops listening in the background.

For real-time behavior, use onConfigUpdate to register a listener. In its callback, inspect which keys changed and activate when those changes fit the current interface. The listener returns an unsubscribe function, which app code can use to stop listening. Firebase’s web guide covers real-time listeners, and its real-time documentation explains invalidations and connection behavior.

Firebase documents a limit of 20 million concurrent open real-time connections per project. Above that limit, incremental connection requests may be rejected and the client SDK falls back to standard fetching. The limit is temporarily suspended while a newly published template propagates. Because listeners have fetch and battery costs, use them only for parameters and experiences that benefit from prompt updates. See Firebase’s real-time limits and guidance.

Client templates, server templates, and security

The web JavaScript SDK workflow uses client templates: client apps fetch and activate values on devices. Firebase also offers server templates for backend environments, where configuration is loaded and evaluated server-side. These are different architectures; a browser app’s client-side Remote Config values should be treated as accessible to its user. Firebase describes the template types and parameters.

Rank #4
Sale
Web Design with HTML, CSS, JavaScript and jQuery Set
  • Brand: Wiley
  • Set of 2 Volumes
  • A handy two-book set that uniquely combines related technologies Highly visual format and accessible language makes these books highly effective learning tools Perfect for beginning web designers and front-end developers

Firebase’s web guide states, “Don’t store confidential data in Remote Config parameter keys or values.” That includes secrets such as credentials or private tokens. Client-visible defaults and fetched values are not secret, even if the connection to Firebase is encrypted. Read Firebase’s security guidance.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Project quotas and pricing to check

Firebase’s parameter documentation lists quotas of up to 3,000 parameters and 2,000 conditions per project, parameter keys up to 256 characters, and up to 1,000,000 characters total across parameter values. Check the live parameter documentation before designing around these limits, because quotas can change.

Firebase’s pricing page retrieved October 7, 2026 describes a flexible pricing structure effective September 1, 2026. It shows up to 100,000 fetch requests per day at no cost on Spark; Blaze also has a no-cost threshold through 100,000 daily requests, with per-request rates at higher daily volumes. The same page lists billing transition dates of December 1, 2026 for existing Spark projects, with a longer period for qualifying early upgrades, and February 1, 2027 for existing Blaze projects. These terms and dates can change; consult the current Firebase pricing page and your project’s billing status rather than treating them as permanent rates.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.