What is Remote Configuration? A Developer's Guide
Ever shipped a bug to production and wished you could fix it without deploying? Or wanted to enable a feature for just 10% of users? That’s where remote configuration comes in.
In this article, we’ll explore what remote configuration is, how it works under the hood, and when you should (and shouldn’t) use it.
What is remote configuration?
Remote configuration (also called dynamic configuration) is a technique where your application fetches its settings from an external server instead of reading them from local files or environment variables.
The key difference from traditional configuration:
| Traditional Config | Remote Config | |-------------------|---------------| | Read at startup | Read at runtime | | Changes require redeploy | Changes take effect immediately | | Same for all users | Can vary per user/context | | No history | Full version history |
Here’s a simple example. Traditional configuration looks like this:
// Read once at startup, never changes
const RATE_LIMIT = parseInt(process.env.RATE_LIMIT ?? '100', 10)With remote configuration:
// Value can change at any time
const rateLimit = replane.get('rate-limit')The difference is subtle in code but significant in practice. With remote config, you can change that rate limit from 100 to 50 in seconds—without touching your code or restarting your servers.
How does it work?
A remote configuration system has three main components:
1. Configuration store — This is where you define and edit configuration values. It’s usually a web dashboard or API where you can create configs, set values, and manage versions.
2. Propagation mechanism — When a value changes, that change needs to reach your running applications. Common approaches include:
- Polling: Applications check for updates every N seconds
- Webhooks: The server pushes updates to applications
- Server-Sent Events (SSE): Applications maintain a persistent connection and receive updates in real-time
3. Client library (SDK) — Your application uses a library to connect to the config server, receive updates, and expose values through a simple API.
Here’s what the flow looks like:
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Dashboard │ ──► │ Server │ ──► │ Your App │
│ (edit) │ │ (store) │ │ (SDK) │
└─────────────┘ └─────────────┘ └─────────────┘When you change a value in the dashboard, the server stores it and notifies connected applications. The SDK in your app receives the update and makes the new value available immediately.
What’s the main advantage of remote configuration over environment variables?
Common use cases
Remote configuration shines in several scenarios:
Feature flags
Enable or disable features without deploying code:
if (replane.get('new-checkout-enabled')) {
showNewCheckout()
} else {
showOldCheckout()
}This lets you:
- Deploy code with features hidden behind flags
- Enable features for specific users or percentages
- Instantly disable broken features (kill switch)
Operational tuning
Adjust performance parameters in real-time:
const rateLimit = replane.get('api-rate-limit')
const cacheTtl = replane.get('cache-ttl-seconds')
const batchSize = replane.get('worker-batch-size')When traffic spikes, you can lower rate limits. When a database is slow, you can increase timeouts. No deploy required.
A/B testing
Serve different experiences to different users:
const variant = replane.get('pricing-page-variant', {
context: { userId: user.id }
})
if (variant === 'A') {
showOriginalPricing()
} else {
showNewPricing()
}Per-tenant configuration
Give different customers different limits:
const maxUsers = replane.get('max-users', {
context: { tenant: tenant.id }
})Enterprise customers might get 10,000 users while free tier gets 10.
When NOT to use remote configuration
Remote config isn’t the right tool for everything:
Secrets and credentials — API keys, database passwords, and encryption keys should live in a dedicated secrets manager (like HashiCorp Vault or AWS Secrets Manager), not in remote config.
Truly static values — Database connection strings, service URLs, and other values that don’t change at runtime can stay in environment variables. Don’t over-engineer.
Application data — Remote config is for settings, not for storing user profiles or transaction records. Use a database for that.
Complex experimentation — If you need statistical significance calculations and multivariate testing, use a dedicated experimentation platform.
Which of these should you store in remote configuration?
Building vs buying
You can build your own remote configuration system or use an existing one. Here’s what each option involves:
Building your own:
- Create a server to store configs (database + API)
- Build a dashboard for editing
- Implement a propagation mechanism (polling, webhooks, or SSE)
- Build client libraries for each language you use
- Handle versioning, rollback, access control
This is a lot of work, and you’ll likely reinvent many wheels.
Using an existing solution:
- Replane — Open-source, self-hosted or cloud, SDKs for JavaScript, Python, .NET
- LaunchDarkly — Enterprise feature flags (paid)
- ConfigCat — Feature flags with generous free tier
- Firebase Remote Config — Mobile-focused, free tier available
For most teams, using an existing solution saves months of development time. If you want to self-host and need open-source, Replane is worth checking out—it handles versioning, rollback, and real-time updates via SSE.
Getting started
If you’re new to remote configuration, here’s a path to get started:
-
Identify candidates — Look at your codebase for values you wish you could change without deploying. Rate limits, feature flags, and timeout values are good starting points.
-
Start small — Pick one or two configs to migrate first. Prove the pattern works before going all-in.
-
Set up defaults — Always have fallback values in case the config server is unreachable. Your app should work (perhaps in a degraded mode) even if it can’t fetch remote config.
-
Add monitoring — Track when config values change. If something breaks after a config change, you want to know immediately.
Summary
Remote configuration lets you change application behavior without redeploying code. It’s essential for:
- Feature flags and gradual rollouts
- Operational tuning (rate limits, timeouts)
- A/B testing and experimentation
- Per-user or per-tenant customization
The tradeoff is added complexity—you now depend on an external system. But for values that need to change quickly, that tradeoff is worth it.
Exercises
-
Identify config candidates: Think about an application you’ve worked on. List 5 configuration values that would benefit from being remote rather than static.
-
Design a simple config system: Sketch out how you would build a minimal remote configuration system. What would you store in the database? How would clients receive updates?
-
Implement a polling client: Write a JavaScript class that polls a JSON endpoint every 30 seconds and caches the result. Make sure it handles network errors gracefully.
Discussion