Skip to content
The Bridge Logo The Bridge docs

Feature Flags

Section titled “Feature Flags”

Bridge Feature Flags lets you ship code dark, roll it out gradually, target it at specific users, and kill it instantly, all without a deploy. The SDK evaluates flags locally: it keeps your flag rules in memory, evaluates them against in-process context, and receives rule changes over the live channel (a persistent realtime connection the SDK maintains). A flag check is an O(1) lookup with no network call, safe in render paths.

Flags work standalone: an appId is all the configuration you need. Bridge auth and billing are optional context sources you can target on once they’re enabled.

The mental model

Section titled “The mental model”
  1. You create a flag in Control Center (your admin dashboard at app.thebridge.dev) and give it rules: on/off, a percentage rollout, or conditions on attributes like user.role or tenant.plan.
  2. The SDK evaluates those rules locally against the eval context: the identity and attributes a flag rule evaluates against. Bridge auth and billing feed attributes in automatically; your code can add its own.
  3. Changes arrive live. Edit a rule in Control Center and every connected app updates in place, typically within seconds, over the live channel. No refresh, no redeploy.

For the full picture (evaluation model, outage behavior, connection status), read How flags work.

Get started

Section titled “Get started”

Get started walks the whole loop in a few minutes: wire up <BridgeBootstrap />, create a flag in Control Center, read it with useFlag, then flip it and watch your app change live.

Using flags

Section titled “Using flags”
  • Show or hide UI: the declarative <FeatureFlag> component, with fallback content for the off case.
  • Use flags in your logic: the useFlag API for branching code paths, plus flagStore and multi-type values (boolean, string, number, JSON).
  • Guard routes: gate whole routes behind a flag with routeConfig rules; the SDK’s route guard redirects before the route renders.
  • Use flags on your backend: forward the eval context in the x-bridge-context header so your server and browser agree on identity and bucketing.

Targeting

Section titled “Targeting”
  • Target by plan or role: with Bridge auth or billing enabled, attributes like user.role, tenant.plan, and bridge:billing.* merge into every evaluation with no app code. For plan-granted features, prefer entitlement attributes; see Lock features to a plan.
  • Send context from your code: supply app-specific facts (like a project count) per call or app-wide via bridge.attributes on the bridge object. The full attributes API is in the Live Updates guide.
  • Target anonymous visitors: visitors who aren’t signed in get a persisted anonymous ID and stable bucketing, so percentage rollouts and A/B tests work before signup and never flicker.