If you’ve worked with LaunchDarkly, the idea of Firebase Remote Config will probably feel familiar.
You’ve probably done this before:
if (featureFlags.newCheckout) {
// Show the new experience
} else {
// Keep the old experience
}
Enter fullscreen mode Exit fullscreen mode
The beauty of feature flags is that you can deploy the code without necessarily exposing the feature to everyone.
You can turn something on.
Turn it off.
Roll it out gradually.
Experiment with it.
And, most importantly, you don’t need to create a new deployment every time you want to flip a switch.
Firebase Remote Config follows a very similar idea.
But here’s the interesting part:
It’s not just about feature flags.
It lets you remotely control configuration and certain aspects of your web application’s behavior.
Think of it as a remote control for your web app.
And yes, sometimes changing a true to a false really shouldn’t require another deployment.
The problem we’re trying to solve
Let’s start with a very normal web development scenario.
You’ve built a new dashboard.
The feature is ready.
You deploy it to production.
Then the product manager says:
“Let’s show this to only a few users first.”
You think:
“No problem.”
And then reality kicks in.
Change code
↓
Create PR
↓
Code review
↓
CI
↓
Build
↓
Deploy
↓
Verify
Enter fullscreen mode Exit fullscreen mode
Or maybe you already have the flag in your code:
const newDashboard = false;
Enter fullscreen mode Exit fullscreen mode
Now you need to change:
const newDashboard = true;
Enter fullscreen mode Exit fullscreen mode
Same ceremony.
Different boolean.
This is where remote configuration becomes useful.
What is Firebase Remote Config?
At a very basic level, Firebase Remote Config allows you to define parameters remotely and let your application consume those values.
For example:
new_dashboard = true
Enter fullscreen mode Exit fullscreen mode
Your web application reads the value and decides what to do.
The application code might look like:
if (newDashboardEnabled) {
renderNewDashboard();
} else {
renderOldDashboard();
}
Enter fullscreen mode Exit fullscreen mode
The code doesn’t change.
The configuration does.
That’s the fundamental idea.
Your code defines what the application can do. Remote Config helps decide how it behaves.
If you’ve used LaunchDarkly, this should sound familiar
This is where my previous experience with feature flagging helped me understand Remote Config quickly.
With a feature flagging platform such as LaunchDarkly, the mental model is something like:
Application
↓
Ask for flag
↓
Flag service
↓
ON / OFF / variation
↓
Application decides what to show
Enter fullscreen mode Exit fullscreen mode
Remote Config has a very similar flow:
Web Application
↓
Fetch configuration
↓
Firebase Remote Config
↓
Parameter value
↓
Application uses the value
Enter fullscreen mode Exit fullscreen mode
So if you’ve worked with feature flags before, you’re already halfway there.
The difference is that Remote Config is broader than just feature flags.
You can use it for things like:
feature_enabled = true
max_results = 20
show_beta_banner = false
search_mode = "new"
ai_prompt_version = "v2"
Enter fullscreen mode Exit fullscreen mode
Feature flags are one use case.
Remote configuration is the bigger idea.
Feature flags are basically switches
Let’s take the simplest example.
You have a new checkout experience.
Your code:
if (newCheckoutEnabled) {
showNewCheckout();
} else {
showOldCheckout();
}
Enter fullscreen mode Exit fullscreen mode
Remote Config:
new_checkout = false
Enter fullscreen mode Exit fullscreen mode
The old checkout appears.
Change the configuration:
new_checkout = true
Enter fullscreen mode Exit fullscreen mode
The new checkout appears.
No code change.
No new build.
No deployment.
It’s essentially a remote switch.
Remote Config
|
new_checkout
|
┌──────┴──────┐
↓ ↓
true false
↓ ↓
New checkout Old checkout
Enter fullscreen mode Exit fullscreen mode
Simple.
But this simple idea unlocks quite a few interesting possibilities.
Deploying code and releasing a feature are different things
This is probably my favorite concept here.
Traditionally, we tend to think:
Deploy = Release
Enter fullscreen mode Exit fullscreen mode
But feature flags and remote configuration allow us to separate them.
You can do:
Deploy code
↓
Feature OFF
↓
Test in production
↓
Enable for selected users
↓
Monitor
↓
Increase rollout
Enter fullscreen mode Exit fullscreen mode
So:
You can deploy a capability without immediately exposing that capability to everyone.
That’s a powerful change in release strategy.
Gradual rollouts
Let’s say you’re introducing a new search experience.
You could release it to everyone:
100% → New Search
Enter fullscreen mode Exit fullscreen mode
Or you could gradually expose it:
5%
↓
10%
↓
25%
↓
50%
↓
100%
Enter fullscreen mode Exit fullscreen mode
At every stage, you can watch:
- errors
- performance
- conversion
- engagement
- user feedback
If something looks wrong at 10%, you don’t necessarily need to roll back the entire deployment.
You can change the configuration and reduce exposure.
This is especially useful when the feature is:
- new
- risky
- performance-sensitive
- used by a large number of users
- difficult to test completely before production
Production becomes less of a big bang and more of a controlled experiment.
“But how do I choose who gets it?”
This is where feature flags become more interesting than a simple ON/OFF switch.
You may want:
new_dashboard = true
Enter fullscreen mode Exit fullscreen mode
for one group of users and:
new_dashboard = false
Enter fullscreen mode Exit fullscreen mode
for everyone else.
You might target based on available Firebase conditions and application context.
Conceptually:
Users
|
┌────────┴────────┐
↓ ↓
Selected users Everyone else
↓ ↓
New dashboard Old dashboard
Enter fullscreen mode Exit fullscreen mode
Now you’re not just asking:
“Is the feature enabled?”
You’re asking:
“For whom is the feature enabled?”
That’s where remote configuration becomes a proper release-management tool.
Remote Config + experimentation
Now let’s make things a little more interesting.
Imagine you’re building an e-commerce website.
You have two versions of a CTA:
Version A
Start Free Trial
Enter fullscreen mode Exit fullscreen mode
Version B
Try It Free
Enter fullscreen mode Exit fullscreen mode
Which one performs better?
Instead of continuously changing the frontend code and deploying every experiment, configuration can control which variation is presented.
Conceptually:
Users
|
┌──────┴──────┐
↓ ↓
Group A Group B
↓ ↓
Version A Version B
Enter fullscreen mode Exit fullscreen mode
Then you measure the results.
That’s where Remote Config and experimentation start working together.
You’re not just changing configuration.
You’re using configuration to learn from real users.
This gets even more interesting with AI
AI-powered web applications make remote configuration particularly interesting.
Why?
Because AI applications often have parameters that change frequently.
For example:
prompt
model
response length
thresholds
fallback behavior
UI behavior
Enter fullscreen mode Exit fullscreen mode
Imagine an AI assistant on your website.
Your first prompt might be:
Summarize the user's question.
Enter fullscreen mode Exit fullscreen mode
You want to try:
Summarize the user's question in three concise bullet points.
Enter fullscreen mode Exit fullscreen mode
Instead of hardcoding every variation and deploying for every small change, you can use remotely managed configuration where appropriate.
You could experiment with:
Group A → Prompt A
Group B → Prompt B
Enter fullscreen mode Exit fullscreen mode
Then observe things like:
- completion rate
- engagement
- user feedback
- conversion
- response quality
The important idea isn’t that Remote Config magically makes AI better.
It gives you more control over how you introduce and experiment with changes.
And when AI behavior is involved, that control becomes even more valuable.
Real-time changes
Firebase Remote Config also supports real-time configuration updates.
Here’s the basic idea.
Suppose you’ve changed a configuration parameter.
Instead of waiting for a traditional release cycle, the client can be notified that the Remote Config values have changed and can fetch and activate the latest configuration according to the application’s implementation.
Conceptually:
Firebase
|
Configuration changed
|
↓
Client notified
|
↓
Fetch latest values
|
↓
Activate
|
↓
Application reacts
Enter fullscreen mode Exit fullscreen mode
For a web application, this can be useful when you need configuration changes to reach active clients faster.
But there’s an important engineering detail:
Real-time does not mean “ignore caching, fetching, activation, or application state.”
Your application still needs to implement the behavior correctly.
Remote Config isn’t a magic wand
There’s one thing we need to be very clear about.
Remote Config cannot create new functionality.
You can’t write:
build_new_payment_system = true
Enter fullscreen mode Exit fullscreen mode
and expect Firebase to build your payment system.
Nice thought, though.
Your application needs to already contain the functionality.
For example:
if (paymentV2Enabled) {
usePaymentV2();
}
Enter fullscreen mode Exit fullscreen mode
The code needs to exist.
Remote Config simply controls whether that path is used.
Think:
Application code
+
Configuration
=
Application behavior
Enter fullscreen mode Exit fullscreen mode
Not:
Configuration
↓
Generate application
Enter fullscreen mode Exit fullscreen mode
What happens when Remote Config isn’t available?
This is where good engineering comes in.
What if the user’s internet connection is terrible?
What if the configuration can’t be fetched?
What if Firebase isn’t reachable?
Your application should still know what to do.
That’s why you should define sensible defaults.
For example:
const defaults = {
newDashboard: false
};
Enter fullscreen mode Exit fullscreen mode
Now the flow becomes:
Fetch Remote Config
|
┌──────┴──────┐
↓ ↓
Success Failure
↓ ↓
Remote value Default value
Enter fullscreen mode Exit fullscreen mode
The remote configuration is the override.
The default is the safety net.
And your application should choose defaults that fail safely.
Remote Config isn’t your database
Another common question is:
“Why not just store this in Firestore?”
Because configuration and application data are different things.
Think about it this way.
Firestore
What does my application know?
users
orders
products
messages
Enter fullscreen mode Exit fullscreen mode
Remote Config
How should my application behave?
new_dashboard = true
max_results = 20
beta_banner = false
Enter fullscreen mode Exit fullscreen mode
Secret Manager
What must remain secret?
API credentials
private keys
secrets
Enter fullscreen mode Exit fullscreen mode
A simple mental model:
Firestore
↓
Application DATA
Remote Config
↓
Application BEHAVIOUR
Secret Manager
↓
Application SECRETS
Enter fullscreen mode Exit fullscreen mode
And please don’t put passwords into Remote Config because:
“Well… it’s remote.”
Remote does not mean secret.
Don’t make everything configurable
There’s another trap waiting for us.
Once you discover Remote Config, everything suddenly looks like a candidate.
button_color
button_padding
button_radius
font_size
animation_speed
header_height
show_logo
random_flag_1
random_flag_2
random_flag_3
Enter fullscreen mode Exit fullscreen mode
And congratulations.
You’ve just created a second codebase.
Remote Config should be used where changing a value remotely provides meaningful value.
Good candidates might include:
feature flags
rollout controls
experiment parameters
limits
behavior switches
maintenance controls
AI-related configuration
Enter fullscreen mode Exit fullscreen mode
But if something never needs to change independently of a deployment, keeping it in code may be perfectly fine.
Configurable doesn’t automatically mean better.
Where Remote Config fits in a web architecture
A simplified architecture might look like this:
Web Application
|
┌─────────┴─────────┐
| |
Code Remote Config
| |
"What can it do?" "How should it behave?"
| |
└─────────┬─────────┘
↓
User Experience
Enter fullscreen mode Exit fullscreen mode
The application owns the logic.
Remote Config provides configuration.
The browser combines the two.
Remote Config vs LaunchDarkly
Since LaunchDarkly is a familiar name for many developers, here’s the simplest way I’d describe the relationship.
They overlap heavily around:
- feature flags
- targeting
- gradual rollouts
- experimentation
- runtime control
But their positioning is different.
LaunchDarkly is primarily a dedicated feature-management platform.
Firebase Remote Config is a Firebase service focused on remote application configuration, with feature flags and experimentation as important use cases.
So I wouldn’t think of Remote Config as:
“LaunchDarkly, but from Google.”
I’d think:
“Remote configuration with feature-management capabilities, integrated into the Firebase ecosystem.”
That distinction makes the product easier to understand.
Why this matters for modern web applications
Web applications are no longer static pages that we deploy once and forget.
We’re constantly changing:
- UI
- experiments
- feature availability
- performance settings
- user experiences
- AI behavior
- product flows
And every change doesn’t necessarily deserve another deployment.
Sometimes you simply need control.
Remote Config provides a mechanism for that control.
The bigger shift
For me, Remote Config represents a broader change in how we think about software delivery.
Old mindset:
Build
↓
Deploy
↓
Everyone gets it
Enter fullscreen mode Exit fullscreen mode
New mindset:
Build
↓
Deploy
↓
Control exposure
↓
Observe
↓
Learn
↓
Gradually roll out
Enter fullscreen mode Exit fullscreen mode
That distinction is especially valuable when you don’t know exactly how a change will behave in the real world.
And let’s be honest:
we rarely do.
You can have:
- unit tests
- integration tests
- E2E tests
- QA environments
- staging environments
- performance testing
And production will still find a way to surprise you.
Production has a PhD in that.
Final takeaway
Firebase Remote Config may look like a simple key-value store.
But the interesting part isn’t the key-value pair.
It’s the control it gives you after deployment.
You can:
- toggle features
- target users
- run experiments
- gradually roll out functionality
- change configuration remotely
- react to feedback faster
- manage certain AI-related behavior
- reduce the blast radius of risky releases
And the idea I’d take away is this:
Deploy the capability. Control the exposure.
Your code doesn’t have to change every time your product decision changes.
Sometimes the code is perfectly fine.
You just need to flip the switch.
And that’s when having a remote control for your web application starts making a lot of sense.
One last mental model
Your Web App
|
┌────────┴────────┐
↓ ↓
Code Remote Config
↓ ↓
"What can it do?" "How should it behave?"
| |
└────────┬────────┘
↓
User Experience
Enter fullscreen mode Exit fullscreen mode
Ship the code.
Control the experience.
And maybe save yourself one more deployment for a tiny configuration change.