Render the new UI only for the users who should see it.

Use the useFlag hook to conditionally render components, roll out a redesign gradually, and kill it instantly if something breaks.

Setup in under 2 minutesNo sales callsREST APICLIJavaScript logoJavaScriptNode.js logoNode.jsReact logoReactNext.js logoNext.jsPython logoPythonRuby logoRubyMCP Support
Core concept

What are feature flags?

A feature flag is a runtime switch in your code that decides whether a piece of functionality is visible or active, without requiring a new deployment.

Instead of shipping a feature straight to every user the moment it merges, you wrap it in a flag. The code reaches production immediately, but stays off until you decide to turn it on — for one user, a percentage of traffic, or everyone at once.

Application
Feature Flag SDK
Evaluate Flag
Show Feature
Why developers use them

Six problems a feature flag solves

01

Deploy continuously

Merge and ship to production every day, and keep unfinished work safely behind a flag instead of a long-lived branch.

02

Release gradually

Turn a feature on for 5% of traffic first, watch for errors, then widen the rollout instead of flipping a switch for everyone at once.

03

Beta test with real users

Target specific accounts or user IDs so a handful of people can try a feature before it reaches everyone else.

04

Disable instantly

If a feature misbehaves in production, turn it off from the dashboard in seconds — no rollback, no redeploy.

05

Reduce deployment risk

Separate "deployed" from "released." Code can sit in production, inactive, until you decide it is ready.

06

Ship faster as a team

Multiple engineers can merge into main continuously without waiting on each other's features to be release-ready.

See it in action

One flag, four states

Feature OFF
0% of users
Feature ON
100% of users
Rollout
35% of users
Specific user
usr_alpha only

The same flag key, evaluated with a different user context, can return a different result for every visitor — without a second deployment.

Installation

Get the SDK

Terminalshell
npm install @flagpilot/javascript @flagpilot/react
Quick start

From install to your first evaluation

1

Install the SDK

Add both the core client and the React bindings.

App.tsx
npm install @flagpilot/javascript @flagpilot/react
2

Wrap your app in a provider

Create one client outside your component tree and pass it to FlagPilotProvider.

App.tsx
const client = new FlagPilot({
  clientKey: 'fk_client_xxxx',
  environment: 'production'
});

<FlagPilotProvider client={client}>
  <App />
</FlagPilotProvider>
3

Evaluate with a hook

Call useFlag() from any component beneath the provider.

App.tsx
const { enabled, loading } = useFlag('beta-payment-gate');
4

Render conditionally

Use the hook's return value directly in your JSX.

App.tsx
if (loading) return <SkeletonLoader />;
return enabled ? <StripePaymentV2 /> : <StripePaymentV1 />;
Application
SDK
Local Cache
FlagPilot API
Boolean Result
Under the hood

How evaluation works

On startup, the SDK fetches your project's flag configuration once and stores it in an in-memory cache. Every evaluate() call after that reads from the cache, not the network, so checking a flag is effectively free.

The cache refreshes in the background on a polling interval, so a change you make in the dashboard shows up in connected clients within seconds, without blocking any request.

If the API is temporarily unreachable — a network blip, or a cold start before the first fetch completes — evaluation falls back to a safe default instead of throwing, so a flag outage never becomes a feature outage.

Framework benefits

Built for React

01

One hook, no boilerplate

useFlag() returns enabled/loading state directly — no manual subscription or context wiring.

02

Provider handles initialization

Wrap your app in FlagPilotProvider once; it initializes the client and re-renders consumers automatically.

03

Consistent across renders

The same user sees the same flag state across re-renders and route changes, based on deterministic hashing.

04

TypeScript support

Hooks are fully typed, so enabled and loading are inferred without manual generics.

05

Tiny bundle size

The React bindings add only a thin hook layer on top of the ~10KB JavaScript client.

06

Browser & server rendering

Use the hooks in Client Components, and evaluate server-side with @flagpilot/next for the same flags during SSR.

Code examples

Common patterns in React

Basic
const { enabled, loading } = useFlag('beta-payment-gate');

if (loading) return <SkeletonLoader />;
return enabled ? <StripePaymentV2 /> : <StripePaymentV1 />;
Best practices

Getting flags right from day one

01

Never expose secret keys

Secret API keys belong on your server only. Client-side code should use a public client key that can't modify flags.

02

Use stable user identifiers

Percentage rollouts hash the user ID you pass in. A stable ID means the same user always gets the same result.

03

Keep flags short-lived

A flag that never gets removed becomes a permanent branch in your code. Treat flags as temporary scaffolding, not config.

04

Remove stale flags regularly

Once a rollout reaches 100% and stays there, delete the flag and the old code path along with it.

05

Roll out gradually before going global

It's far cheaper to catch a bug at 5% of traffic than to catch it at 100%.

06

Use meaningful flag names

A key like new-checkout-flow-v2 is easier to audit six months later than test123.

Specific to React
  • Create the FlagPilot client once, outside your component tree, and pass it to a single FlagPilotProvider.
  • Render a skeleton or loading state while `loading` is true, instead of assuming the flag is off.
  • Use the public client key — never the secret server key — in a React app that ships to browsers.
Why choose FlagPilot

Feature flags that feel like part of React, not a bolted-on library

01

Lightweight by default

Every SDK stays under 10KB and evaluates from an in-process cache, so adding flags never becomes a performance conversation.

02

REST API for everything

Every action available in the dashboard — creating flags, updating rollouts, reading audit history — is also a documented REST endpoint.

03

A CLI that matches the API

Script flag creation and rollout changes from your terminal or CI pipeline, using the same operations the dashboard performs.

04

Built for AI-assisted development

A native MCP server lets Cursor, Claude Code, or any MCP-compatible assistant create and toggle flags directly from a prompt.

05

Dead flag detection included

Flags that haven't been evaluated recently, or have sat at 100%/0% for months, are surfaced automatically instead of silently rotting in your codebase.

06

Developer experience first

No sales calls, no seat-based pricing negotiations — sign up, get an API key, and evaluate your first flag in the same session.

Performance

Fast enough to not think about

Evaluation logic must never slow down your app or disrupt a user flow — here's what that looks like in practice.

< 10 KB
SDK size
gzipped client bundle
< 100ms
Initialization
cold start to ready
< 1ms
Cached evaluation
local in-memory lookup
Background only
Network requests
evaluate() never blocks on the network
FAQ

Frequently Asked Questions

Ready to ship features safely?

Install FlagPilot in React in under a minute.