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 Firebase Admin Node.js SDK v12.1.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
When you use Remote Config in server apps using the Firebase Admin SDK, you fetch and load the entire template in order to extract appropriate parameter values on-demand for each client request. A parameter might have several conditional values associated with it.
The following rules determine which value is assigned during template evaluation at a particular point in time:
First, conditional values are applied for any conditions that evaluate to
truefor a given client request. If multiple conditions evaluate totrue, the first (top) one shown in the Firebase console UI takes precedence, and conditional values associated with that condition are provided when the template is evaluated. You can change the priority of conditions by dragging and dropping conditions in the Conditions tab.If there are no conditional values with conditions that evaluate to
true, Remote Config's default value is provided during template evaluation. If a parameter doesn't exist in the template, or if the default value is set to Use in-app default, then no value is provided for that parameter when the template is evaluated.
For more information about loading and evaluating Remote Config templates in server apps, see Use Remote Config in server environments.
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:
StringBooleanNumberJSON
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:
- Select Manage groups.
- Select checkboxes for parameters you want to add and select Move to group.
- 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
Remote Config templates for server applications support the following condition types:
User in random percentage
Use this field to apply a change to a random sample of app instances (with sample sizes as small as .0001%), using the slider widget to segment randomly-shuffled users (app instances) into groups.
Each app instance is persistently mapped to a random whole or fractional number, according to a seed defined in that project.
A rule will use the default key (shown as Edit seed in the Firebase console) unless you modify the seed value. You can return a rule to using the default key by clearing the Seed field.
To consistently address the same app instances within given percentage ranges, use the same seed value across conditions. Or, select a new randomly-assigned group of app instances for a given percentage range by specifying a new seed.
For example, to create two related conditions that each apply to a non-overlapping 5% of an app's users, you could configure one condition to match a percentage between 0% and 5% and configure another condition to match a range between 5% and 10%. To allow some users to randomly appear in both groups, use different seed values for the rules within each condition.
To learn how to add random percentage conditions to your application, see Configure your server application.
Custom signals
With Firebase Admin Node.js SDK 12.5.0 and higher, you can use the Custom signal condition type to match arbitrary conditions you define in your application. This lets you tailor server response for each client request.
For example, if you're working on a server app that uses generative AI to help craft responses with different models tuned for specific platforms, you could do the following:
- Add the
promptandmodel_nameparameters to your Remote Config server template. - Add custom signals with a value of
platformfor each platform you want to target. - Add default values to your server-specific Remote Config template and conditional values for each platform condition you defined.
- Update your application code to set and use the
platformcustom signal.
Now, your app can extract the appropriate prompt and model during template evaluation and use them to return customized responses to each client.
You can use the following rule types to create custom signals in the Firebase console.
| Operator category | Operator(s) | Value | Note |
|---|---|---|---|
| Text | exactly matches, contains, does not contain, contains regex |
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 RE2 format. Your regular expression can match all or part of the target version string. You can also use the ^ and $ anchors to match the beginning, end, or entirety of a target string. |
|
| Numbers | <, <=, =, !=, >, >= | Numeral with no more than ten digits on each side of the decimal point. | |
| Versions | <, <=, =, !=, >, >= | Numeral that represents the version number(s) to match (for example, 2.1.0). |
To learn how to add custom signals to your application, see Configure your server application.
Search parameters and conditions
You can search your project's parameter keys, parameter values, and conditions from the Firebase console using the search box at the top of the Remote Config Parameters tab.
Limits on parameters and conditions
Within a Firebase project, you can have up to 2000 parameters, and up to 500 conditions. Parameter keys can be up to 256 characters long, must start with an underscore or English letter character (A-Z, a-z), and may also include numbers. The total length of parameter value strings within a project cannot exceed 1,000,000 characters.
View changes to parameters and conditions
You can view the latest changes to your Remote Config templates from the Firebase console. For each individual parameter and condition, you can:
View the name of the user who last modified the parameter or condition.
If the change occurred within the same day, view the number of minutes or hours that have elapsed since the change was published to the active Remote Config template.
If the change occurred one or more days in the past, view the date when the change was published to the active Remote Config template.
Change history for parameters
On the Remote Config Parameters page, the Last published column shows the last user who modified each parameter and the last publish date for the change:
To view change metadata for grouped parameters, expand the parameter group.
To sort in ascending or descending order by publish date, click the Last published column label.
Change history for conditions
On the Remote Config Conditions page, you can see the last user who modified the condition and the date they modified it next to Last modified under each condition.