Remote Config Parameters and Conditions

You can configure templates for both client and server use cases. Client templates are served to any app instances that implement the Firebase client SDKs for Remote Config, including Android, Apple, Web, Unity, Flutter, and C++ apps. Remote Config parameters and values from server-specific templates are served to Remote Config implementations (including Cloud Run and Cloud Functions) that use the following server environments:

• Firebase Admin Node.js SDK v12.1.0+
• Firebase Admin Python SDK v6.7.0+

When using Firebase console or the Remote Config backend APIs, you define one or more parameters (key-value pairs) and provide in-app default values for those parameters. You can override in-app default values by defining parameter values. Parameter keys and parameter values are strings, but parameter values can be cast as other data types when you use these values in your app.

Using the Firebase console, Admin SDK or the Remote Config REST API, you can create new default values for your parameters, as well as conditional values that are used to target groups of app instances. Each time you update your configuration in the Firebase console, Firebase creates and publishes a new version of your Remote Config template. The previous version is stored, allowing you to retrieve or rollback as needed. These operations are available to you in the Firebase console, the Firebase Admin SDK, and the REST API and are described more extensively in Manage Remote Config template versions.

This guide explains parameters, conditions, rules, conditional values, and how various parameter values are prioritized on the Remote Config backend and in your app. It also provides details on the types of rules used to create conditions.

Conditions, rules, and conditional values

A condition is used to target a group of app instances. Conditions are made up of one or more rules that must all evaluate to true for the condition to evaluate to true for a given app instance. If the value for a rule is undefined (for example, when no value is available), that rule will evaluate to false.

For example, you could create a parameter that defines a large language model (LLM) model name and version string, and serve responses from different models based on custom signal rules. In this use case, you might use a stable model version as the default value to serve most requests, and use the custom signal to use an experimental model to respond to test client requests.

A parameter can have multiple conditional values that use different conditions, and parameters can share conditions within a project. In the Parameters tab of the Firebase console, you can view the fetch percentage for each parameter's conditional values. This metric indicates the percentage of requests in the last 24 hours that received each value.

Parameter value priority

A parameter might have several conditional values associated with it. The following rules determine which value is fetched from the Remote Config template, and which value is used in a given app instance at a particular point in time:

1. First, conditional values are applied for any conditions that evaluate to true for a given client request. If multiple conditions evaluate to true, the first (top) one shown in the Firebase console UI takes precedence, and conditional values associated with that condition are provided when an app fetches values from the backend. You can change the priority of conditions by dragging and dropping conditions in the Conditions tab.

2. If there are no conditional values with conditions that evaluate to true, the Remote Config's default value is provided when an app fetches values from the backend. If a parameter doesn't exist in the backend, or if the default value is set to Use in-app default, then no value is provided for that parameter when an app fetches values.

In your app, parameter values are returned by get methods according to the following priority list

1. If a value was fetched from the backend and then activated, the app uses the fetched value. Activated parameter values are persistent.

2. If no value was fetched from the backend, or if values fetched from the Remote Config backend have not been activated, the app uses the in-app default value.

   For more information on obtaining and setting default values, see Download Remote Config template defaults.

3. If no in-app default value has been set, the app uses a static type value (such as 0 for int and false for boolean).

This graphic summarizes how parameter values are prioritized in the Remote Config backend, and in your app:

Parameter value data types

Remote Config lets you select a data type for each parameter, and validates all Remote Config values against that type before a template update. The data type is stored and returned on a getRemoteConfig request.

Supported data types are:

• String
• Boolean
• Number
• JSON

In the Firebase console UI, the data type can be selected from a drop-down next to the parameter key. In the REST API, types can be set using the value_type field within the parameter object.

Parameter groups

Remote Config lets you group parameters together for a more organized UI and enhance usability.

For example, say you need to enable or disable three different auth types while rolling out a new login feature. With Remote Config, you can create the three parameters to enable the types you want, and then organize them in a group named "New login," with no need to add prefixes or special sorting.

You can create parameter groups using the Firebase console or the Remote Config REST API. Each parameter group you create has a unique name in your Remote Config template. When creating parameter groups, keep in mind:

• Parameters can be included in only one group at any time, and a parameter key must still be unique across all parameters.
• Parameter group names are limited to 256 characters.
• If you use both the REST API and the Firebase console, make sure that any REST API logic is updated to handle parameter groups on publish.

Create or modify parameter groups using the Firebase console

You can group parameters in the Parameters tab of the Firebase console. To create or modify a group:

1. Select Manage groups.
2. Select checkboxes for parameters you want to add and select Move to group.
3. Select an existing group, or create a new group by entering a name and description, and selecting Create new group. After you save a group, it is available to be published using the Publish changes button.

Condition rule types

The following rule types are supported in the Firebase console. Equivalent features are available in the Remote Config REST API, as detailed in the conditional expression reference.

Rule type	Operator(s)	Value(s)	Note
App	==	Select from a list of App IDs for apps associated with your Firebase project.	When you add an app to Firebase, you enter a bundle ID or Android package name that defines an attribute that's exposed as App ID in Remote Config rules. Use this attribute as follows: For Apple platforms: Use the app's CFBundleIdentifier. You can find the Bundle Identifier in the General tab for your app's primary target in Xcode. For Android: Use the app's applicationId. You can find the applicationId in your app-level build.gradle(.kts) file.
App version	For string values: exactly matches, contains, does not contain, contains regex For numeric values: <, <=, =, !=, >, >=	Specify the version(s) of your app to target. Before using this rule, you must use an App ID rule to select an Android/Apple app associated with your Firebase project.	For Apple platforms: Use the app's CFBundleShortVersionString. Note: Make sure your Apple app is using Firebase Apple platforms SDK version 6.24.0 or higher, as CFBundleShortVersionString is not being sent in earlier versions (see release notes). For Android: Use the app's versionName. String comparisons for this rule are case-sensitive. When using the exactly matches, contains, does not contain , or contains regex operator, you can select multiple values. When using the contains regex operator, you can create regular expressions in