Forem: Dmitry Tilyupo

Dynamic Configuration in React — Feature Flags Without the Jank

Dmitry Tilyupo — Fri, 09 Jan 2026 18:55:11 +0000

We shipped a new checkout flow last week. Product wanted a kill switch. The "solution"? A REACT_APP_NEW_CHECKOUT env var, hardcoded at build time.

Then they asked to roll it out to 10% of users first. Then premium users only. Then specific accounts for beta testing.

That env var wasn't going to cut it.

The Problem With Feature Flags in React

Most React apps handle configuration one of three ways:

1. Build-time env vars

const isNewCheckout = process.env.REACT_APP_NEW_CHECKOUT === "true";

function Checkout() {
  return isNewCheckout ? <NewCheckout /> : <LegacyCheckout />;
}

Change it? Rebuild and redeploy the entire app.

2. Props drilled from the top

function App() {
  const [flags, setFlags] = useState(null);

  useEffect(() => {
    fetch("/api/flags")
      .then((r) => r.json())
      .then(setFlags);
  }, []);

  if (!flags) return <Loading />;

  return <Checkout newCheckoutEnabled={flags.newCheckout} />;
}

Works, but now you're threading props through 15 components. Or you reach for Context, but then every flag change re-renders everything.

3. Third-party SDK with its own patterns

import { useFlags } from "some-feature-flag-sdk";

function Checkout() {
  const { newCheckout } = useFlags();
  // ...
}

Better, but now you have a $300/month bill and a vendor-specific API.

What Dynamic Configuration Should Feel Like

Here's what I wanted:

function Checkout() {
  const isNewCheckout = useConfig<boolean>("new-checkout");

  return isNewCheckout ? <NewCheckout /> : <LegacyCheckout />;
}

And when someone flips that value in a dashboard:

Component re-renders automatically
No page refresh
No prop drilling
Full TypeScript support

Building It With Replane

Replane is open-source (MIT) and does exactly this. Here's the setup:

1. Wrap your app

import { ReplaneProvider } from "@replanejs/react";

function App() {
  return (
    <ReplaneProvider
      connection={{
        baseUrl: "https://cloud.replane.dev",
        sdkKey: process.env.REACT_APP_REPLANE_SDK_KEY!,
      }}
      loader={<AppSkeleton />}
    >
      <Router />
    </ReplaneProvider>
  );
}

The provider connects via Server-Sent Events. Config loads once, then streams updates in real-time.

2. Read configs anywhere

import { useConfig } from "@replanejs/react";

function Checkout() {
  const isNewCheckout = useConfig<boolean>("new-checkout");
  const discountBanner = useConfig<string>("checkout-banner-text");

  return (
    <div>
      {discountBanner && <Banner text={discountBanner} />}
      {isNewCheckout ? <NewCheckout /> : <LegacyCheckout />}
    </div>
  );
}

The hook subscribes to that specific config. When it changes on the server, only components using that config re-render.

3. Add targeting with context

Want different values for different users?

function Checkout() {
  const { user } = useAuth();

  const rateLimit = useConfig<number>("api-rate-limit", {
    context: {
      userId: user.id,
      plan: user.subscription,
      country: user.country,
    },
  });

  // Premium users might get 10000, free users get 100
}

Override rules are defined in the Replane dashboard:

If plan equals premium → return 10000
If country equals DE → return 500
Default → 100

No code changes when you add new rules.

Making It Type-Safe

Generic hooks work, but you can do better:

// config.ts
import { createConfigHook } from "@replanejs/react";

interface AppConfigs {
  "new-checkout": boolean;
  "checkout-banner-text": string | null;
  "api-rate-limit": number;
  "pricing-tiers": {
    free: { requests: number };
    pro: { requests: number };
  };
}

export const useAppConfig = createConfigHook<AppConfigs>();

// Checkout.tsx
import { useAppConfig } from "./config";

function Checkout() {
  // Autocomplete works, type is inferred
  const isNewCheckout = useAppConfig("new-checkout");
  //    ^? boolean

  const pricing = useAppConfig("pricing-tiers");
  //    ^? { free: { requests: number }; pro: { requests: number } }
}

Typo in the config name? TypeScript catches it. Wrong type assumption? TypeScript catches it.

Handling Loading States

Three options depending on your needs:

Option 1: Loader prop (default)

<ReplaneProvider
  connection={connection}
  loader={<FullPageSpinner />}
>
  <App />
</ReplaneProvider>

Shows loader until all configs are loaded. Simple, but blocks the whole app.

Option 2: Suspense

<Suspense fallback={<FullPageSpinner />}>
  <ReplaneProvider connection={connection} suspense>
    <App />
  </ReplaneProvider>
</Suspense>

Integrates with React's Suspense. Better if you're already using it for data fetching.

Option 3: Async mode with defaults

<ReplaneProvider
  connection={connection}
  defaults={{
    "new-checkout": false,
    "api-rate-limit": 100,
  }}
  async
>
  <App />
</ReplaneProvider>

Renders immediately with defaults. Updates to real values when connection establishes. No loading state, but values might "flip" after initial render.

Server-Side Rendering

For Next.js or any SSR setup, you can hydrate from a server-fetched snapshot:

// On server
import { Replane, getReplaneSnapshot } from "@replanejs/react";

const replane = new Replane();
await replane.connect({ baseUrl: "...", sdkKey: "..." });
const snapshot = replane.getSnapshot();
// Pass to client via props or serialized in HTML

// On client
<ReplaneProvider
  connection={connection}
  snapshot={snapshot}  // Hydrates instantly, no loading state
>
  <App />
</ReplaneProvider>

The client hydrates immediately from the snapshot, then connects for real-time updates.

When To Use This

Good fits:

Feature flags for gradual rollouts
A/B test variants (simple ones)
Per-user or per-tenant customization
UI text that marketing wants to tweak
Operational limits (rate limits, max items, timeouts)
Kill switches for incident response

Keep as build-time config:

API endpoints (don't change at runtime)
Analytics keys (don't change at runtime)
Anything that affects build output

Common Mistakes

1. Putting everything in dynamic config

Not every value needs real-time updates. If it doesn't change while the app is running, keep it simple.

2. No defaults

// Bad - crashes if config server is down
const limit = useConfig<number>("rate-limit");

// Good - works even before connection
<ReplaneProvider
  connection={connection}
  defaults={{ "rate-limit": 100 }}
>

3. Context in the wrong place

// Bad - creates new object every render, breaks memoization
const value = useConfig("limit", { context: { userId: user.id } });

// Better - stable reference
const context = useMemo(() => ({ userId: user.id }), [user.id]);
const value = useConfig("limit", { context });

4. Ignoring error boundaries

import { ErrorBoundary } from "react-error-boundary";

<ErrorBoundary fallback={<div>Config failed to load</div>}>
  <ReplaneProvider connection={connection}>
    <App />
  </ReplaneProvider>
</ErrorBoundary>

Connection failures throw. Catch them.

Getting Started

npm install @replanejs/react

If you're self-hosting Replane, point baseUrl to your instance. Otherwise, cloud.replane.dev has a free tier.

import { ReplaneProvider, useConfig } from "@replanejs/react";

function App() {
  return (
    <ReplaneProvider
      connection={{
        baseUrl: "https://cloud.replane.dev",
        sdkKey: "your-sdk-key",
      }}
      defaults={{ "feature-enabled": false }}
      loader={<div>Loading...</div>}
    >
      <Main />
    </ReplaneProvider>
  );
}

function Main() {
  const isEnabled = useConfig<boolean>("feature-enabled");
  return <div>Feature is {isEnabled ? "on" : "off"}</div>;
}

That checkout kill switch? It's now a toggle in the dashboard. Product can flip it themselves. The 10% rollout? One rule change, no deploy. And when something breaks at 2am, I disable it from my phone.

Questions? Drop a comment or check out the GitHub repo.

Stop Redeploying Just to Change a Config Value

Dmitry Tilyupo — Thu, 08 Jan 2026 22:23:57 +0000

Last Friday, our API got hammered during a flash sale. Rate limit was set to 100 requests/second. We needed 50. Our deploy pipeline? 12 minutes.

That's when I realized: environment variables are static configuration. They change when you redeploy. But some values need to change now.

The Problem I Kept Hitting

Most Node.js apps start like this:

const config = {
  rateLimit: parseInt(process.env.RATE_LIMIT || "100"),
  featureNewCheckout: process.env.FEATURE_NEW_CHECKOUT === "true",
  cacheMaxAge: parseInt(process.env.CACHE_MAX_AGE || "3600"),
};

Fine for database URLs and API keys. But for these? Pain:

Rate limits during traffic spikes
Feature flags for gradual rollouts
Timeouts when downstream services are slow
Kill switches for broken features

Every change = PR → review → merge → CI → deploy → pray.

What Dynamic Configuration Actually Is

Three properties make config "dynamic":

Changes propagate without restarts. Update a value, running instances get it in seconds.
Values are evaluated at read time. Not cached forever at startup.
History is preserved. Who changed what, when. Instant rollback if needed.

Three Ways to Implement It

1. Polling (Simplest)

Fetch config from an external store on a timer:

let config: Config = JSON.parse(readFileSync("./config.json", "utf-8"));

setInterval(async () => {
  try {
    const response = await fetch("https://config-api.internal/v1/config");
    config = await response.json();
  } catch (error) {
    console.error("Failed to refresh config:", error);
    // Keep using last known good config
  }
}, 30_000);

Pros: Works with anything (Redis, DB, HTTP API).

Cons: Updates delayed by polling interval. Wasteful if config rarely changes.

2. Webhooks (Push-based)

Config server pushes updates when they happen:

app.post("/config-webhook", express.json(), (req, res) => {
  const { secret, payload } = req.body;

  if (secret !== process.env.WEBHOOK_SECRET) {
    return res.status(401).json({ error: "Invalid secret" });
  }

  config = payload;
  res.json({ ok: true });
});

Pros: Faster updates.

Cons: Need to expose endpoint, handle auth, ensure all instances get the update.

3. Server-Sent Events (Best of Both)

Persistent connection, server streams updates:

import { EventSource } from "eventsource";

const source = new EventSource("https://config-api.internal/v1/stream", {
  headers: { Authorization: `Bearer ${process.env.CONFIG_API_KEY}` },
});

source.addEventListener("config_change", (event) => {
  const change = JSON.parse(event.data);
  config = { ...config, [change.name]: change.value };
});

Pros: Real-time updates (<100ms). Auto-reconnection. No inbound endpoints.

Cons: Needs infrastructure that supports long-lived connections.

Beyond Key-Value: What Real Apps Need

Simple get(key) isn't enough. You also need:

Type safety — TypeScript should know rateLimit is a number
Context-aware values — Different rate limits for premium vs free users
Defaults — Keep running if config server is down
Subscriptions — React when specific values change

Here's what this looks like with Replane (open-source, SSE-based):

import { Replane } from "@replanejs/sdk";

interface Configs {
  "api-rate-limit": number;
  "feature-new-checkout": boolean;
  "cache-settings": { maxAge: number; staleWhileRevalidate: number };
}

const replane = new Replane<Configs>({
  defaults: {
    "api-rate-limit": 100,
    "feature-new-checkout": false,
    "cache-settings": { maxAge: 3600, staleWhileRevalidate: 60 },
  },
});

await replane.connect({
  sdkKey: process.env.REPLANE_SDK_KEY!,
  baseUrl: "https://cloud.replane.dev",
});

// Type-safe
const rateLimit = replane.get("api-rate-limit");

// Context-aware
const userRateLimit = replane.get("api-rate-limit", {
  context: { userId: user.id, plan: user.subscription },
});

// React to changes
replane.subscribe("cache-settings", (config) => {
  cacheManager.configure(config.value);
});

When to Use Dynamic Config

Good candidates:

Use Case	Example	Why Dynamic
Feature flags	`new-checkout-enabled`	Roll out to 1% → 10% → 100%
Rate limits	`api-rate-limit`	Respond to traffic spikes
Timeouts	`downstream-timeout-ms`	Adjust for slow services
Kill switches	`payments-enabled`	Disable broken features instantly

Keep as env vars:

Database connection strings
API keys and secrets
Service URLs
Log destinations

These don't change while running (and shouldn't).

Common Mistakes

Putting secrets in dynamic config — Use a secrets manager instead.
Using it for everything — DB URLs don't need instant updates.
No defaults — App should start even if config server is down.
Fetching on every request — Cache in memory, update via SSE/polling.
No validation — A typo shouldn't crash production.

Getting Started

Identify candidates — What do you wish you could change without deploying?
Set up a backend — Start simple (JSON file, Redis) or use something like Replane.
Add defaults — Always have fallbacks.
Migrate incrementally — Start with one value, expand from there.
Monitor config changes — Know when changes happen.

If you're building something similar or have questions, drop a comment. Been running this in production for a while now and happy to share what worked (and what didn't).