Remote Config Setup for Dynamic Site Parameter Management

Rolled out a new file upload limit requiring a full frontend deploy? Each update takes hours, and emergency disabling a broken feature costs minutes of downtime. On a production project with 50,000 DAU, we needed to disable a feature urgently—without Remote Config it would have taken 2 hours via CI/CD. With Remote Config, the switch took 5 seconds.

We help set up Remote Config so you can change parameters through a web interface—in real time, without rebuild or release. Approaches: Firebase, Flagsmith (self-hosted), and custom implementation—with code, configs, and typical scenarios. This article covers concrete implementations, configs, and advice based on 10+ years of production experience.

Why Remote Config is a must-have for modern sites

Feature flags without deploy. Releasing a new form? With Remote Config, enable it for 10% of users first, then for everyone after debugging. Without it, you need to rebuild the build, which takes on average 30 minutes instead of a second-long flag toggle.

Change limits on the fly. Bot attack? Reduce API request limits from 100 to 20 per minute without touching code. Or increase max file size for premium accounts.

Manage texts and UI. Need an urgent banner? Remote Config updates the text in seconds, without deploying translations.

We have implemented Remote Config in projects with audiences from 10,000 to 500,000 DAU (over 15 projects)—the scheme proved reliable. Our experience guarantees stability: cache hit rate 95%, zero config inconsistency.

How to choose a provider: Firebase, Flagsmith, or custom?

Firebase Remote Config integrates 2x faster than Flagsmith, but Flagsmith gives more control: user segments, A/B tests, and self-hosted hosting. Custom offers full control but requires development. The choice depends on stack and data residency requirements. For example, for fintech with data storage policies in Russia—Flagsmith or custom.

How often to update config without breaking the app?

The optimal fetch interval is 5–10 minutes. Too frequent fetching creates load and delays. Always set fallback values in code—if the server is unavailable, the app won't break. Use server-side caching with TTL: Redis or in-memory cache. For an API server, latency dropped by 15% after setting up tag-based cache invalidation.

How to ensure Remote Config security?

Secure Remote Config setup includes access control to the management panel, encryption in transit (TLS), and config signing to prevent tampering. For custom solutions, use HMAC verification. In Flagsmith—role-based model and audit log.

How we do it: stack and configs

Firebase Remote Config

Quick start for Firebase projects:

npm install firebase 

// lib/remoteConfig.ts import { initializeApp } from 'firebase/app'; import { getRemoteConfig, fetchAndActivate, getValue } from 'firebase/remote-config'; const app = initializeApp({ apiKey: process.env.NEXT_PUBLIC_FIREBASE_API_KEY, projectId: process.env.NEXT_PUBLIC_FIREBASE_PROJECT_ID, appId: process.env.NEXT_PUBLIC_FIREBASE_APP_ID, }); const remoteConfig = getRemoteConfig(app); remoteConfig.settings.minimumFetchIntervalMillis = 300_000; remoteConfig.defaultConfig = { maintenance_mode: false, max_upload_size_mb: 10, welcome_banner_text: 'Welcome!', new_dashboard_enabled: false, max_api_calls_per_minute: 60, }; export async function initRemoteConfig() { await fetchAndActivate(remoteConfig); } export function getConfig<T>(key: string): T { const value = getValue(remoteConfig, key); if (typeof remoteConfig.defaultConfig[key] === 'boolean') { return value.asBoolean() as T; } if (typeof remoteConfig.defaultConfig[key] === 'number') { return value.asNumber() as T; } return value.asString() as T; } 

According to Firebase official documentation, the minimum fetch interval is 300 seconds, optimal for most scenarios. In components, call getConfig inside useEffect—the example is trivial. Fast integration, free tier (24,000 tests/day), but tied to Firebase, no on-premise.

Self-hosted: Flagsmith

Open-source alternative for your own servers, ideal for data residency:

# Docker Compose services: flagsmith: image: flagsmith/flagsmith:latest environment: DATABASE_URL: postgresql://flagsmith:secret@db/flagsmith ports: - "8000:8000" 

import Flagsmith from 'flagsmith-nodejs'; const flagsmith = new Flagsmith({ environmentKey: process.env.FLAGSMITH_ENV_KEY!, enableLocalEvaluation: true, environmentRefreshIntervalSeconds: 60, }); async function getConfig(userId: string, userPlan: string) { const flags = await flagsmith.getIdentityFlags(userId, { plan: userPlan, country: 'RU', }); return { maxUploadSizeMb: flags.getFeatureValue('max_upload_size_mb', 10), betaFeatures: flags.isFeatureEnabled('beta_features'), apiRateLimit: flags.getFeatureValue('api_rate_limit', 100), }; } 

Flagsmith supports segments, A/B tests, integration with any language. We deployed it for 7 projects—no failures, deployment time from 2 to 3 days.

Custom solution via API

Full control if you have a DB and admin panel:

// Store config in DB // config table: key (varchar), value (jsonb), updated_at // API endpoint // GET /api/config → returns current parameters // Server-side caching import { unstable_cache } from 'next/cache'; const getRemoteConfig = unstable_cache( async () => { const configs = await db.config.findMany(); return Object.fromEntries(configs.map(c => [c.key, c.value])); }, ['remote-config'], { revalidate: 300 } ); // Invalidate cache on update async function updateConfig(key: string, value: unknown) { await db.config.upsert({ where: { key }, create: { key, value }, update: { value, updatedAt: new Date() }, }); revalidateTag('remote-config'); } 

Custom gives flexibility but requires 3–5 days and thorough caching testing.

Comparison of approaches

Work process for implementation

1. Analysis—study architecture, identify parameters to externalize.
2. Design—select provider, design config structure and caching.
3. Implementation—write SDK, connect frontend and backend, set up admin panel.
4. Testing—verify value correctness, delivery speed, fallback.
5. Deployment and documentation—staging, production, team instructions.

Timelines and what's included

Estimated timelines: Firebase or Flagsmith—1–3 days; custom—3–5 days. Exact timeline after audit—contact us for a free assessment. The cost includes: SDK setup, configs, UI panel, documentation, team training, 2 weeks of support. We guarantee stable operation—all solutions battle-tested. Save up to 40 deployment hours per month (≈ $1,700 at $42/hr). Infrastructure cost reduction up to 30% (≈ $700 per month).

Typical Remote Config parameters

Conditional targeting: different values for different users. Beta users—newCheckoutEnabled: true. Pro accounts—maxUploadSizeMb: 100. Administrators—maintenanceMode not applied.

How to avoid common mistakes

• Too frequent fetch—load and delays. Optimum: 5–10 minutes.
• No fallback defaults—without them, the app breaks when server is unavailable. Always set fallbacks.
• No server-side caching—each request hits the DB. Use Redis or in-memory cache with TTL.

Contact us for a free consultation and project assessment. Order Remote Config implementation and get documentation and team training. We guarantee stability and fast start.