What Are Feature Flags? The Complete Guide

What is a feature flag?

At its simplest, a feature flag is a conditional in your code whose outcome is controlled from outside your code:

if (featureflow.evaluate('new-checkout', user).isOn()) {
  // show the new checkout flow
} else {
  // show the existing checkout flow
}

The interesting part isn't the if statement - it's where the answer comes from. Instead of a hard-coded boolean or a config file that requires a redeploy to change, the flag's value is determined by rules you manage centrally: turn it on for everyone, for 5% of users, for your QA team, for customers in Australia, or for a single account that reported a bug. Change the rule and every running instance of your application picks it up within seconds.

You'll also hear the terms feature toggle, feature switch, and feature gate - they all describe the same technique.

Deploying is not releasing

The core idea behind feature flags is that deployment and release are different events, even though most teams treat them as one.

• Deployment is a technical act: your code reaches production servers.
• Release is a business act: users can see and use the feature.

Without flags, the two are welded together - the moment code deploys, users get it, and the only undo is another deploy. With flags, code ships to production dark (off for everyone), and release becomes a separate, reversible decision made in a dashboard: who gets it, when, and how fast. Engineering keeps a fast, boring pipeline; product controls exposure. This is the foundation of continuous delivery and progressive delivery, and it's why feature flags have become standard practice at high-performing engineering organisations.

How feature flags work

A feature flag system has four moving parts:

1. A flag definition - a stable key like new-checkout with two or more variants. Most flags are boolean (on/off), but multivariate flags can serve any number of variants for experiments.
2. Targeting rules - managed in a dashboard, per environment. Rules match on user attributes (plan, country, role, account ID) and can split traffic by percentage. Percentage rollouts are deterministic: the same user hashes into the same bucket every time, so nobody flip-flops between variants mid-session.
3. An SDK in your application - evaluates flags where your code runs. Server-side SDKs (Node.js, Java) download the full ruleset once and evaluate every flag locally in memory - an evaluation is a function call, not a network round-trip. Client-side SDKs (JavaScript, React, mobile) fetch pre-evaluated results for the current user from an edge CDN, so no rules are exposed in the browser.
4. A real-time update channel - when someone changes a rule, connected SDKs receive the change via server-sent events within seconds. No restart, no redeploy, no cache flush.

Every evaluation also feeds analytics, so you can see which variant each user received, and every rule change is written to an audit trail - who changed what, where, and when.

The four types of feature flags

Not all flags are alike - they differ in how long they live and who controls them. Knowing which type you're creating tells you how to manage it:

The distinction matters most at cleanup time: release and experiment flags are temporary and should be deleted once they've served their purpose, while operational and permission flags are part of your product's permanent control surface. (If you find yourself building lots of permission flags, also read feature flags vs entitlements.)

Feature flags in Node.js

Here's what this looks like in practice with the Featureflow Node.js SDK. Install it, create a single shared client, and evaluate flags against a user:

npm install --save featureflow-node-sdk

import Featureflow from 'featureflow-node-sdk';

// One client for your whole app - it loads your environment's
// rules at startup and receives updates in real time.
const featureflow = new Featureflow.Client({
  apiKey: process.env.FEATUREFLOW_SERVER_KEY,
});

// Describe the current user so targeting rules can match them
const user = new Featureflow.UserBuilder('user-42')
  .withAttribute('country', 'AU')
  .withAttributes('roles', ['BETA_CUSTOMER'])
  .build();

// Evaluate - this is a local, in-memory check
if (featureflow.evaluate('new-checkout', user).isOn()) {
  renderNewCheckout();
} else {
  renderClassicCheckout();
}

For resilience you can pre-register flags with failover variants, so your code has a defined behaviour even if the SDK has never managed to connect:

const featureflow = new Featureflow.Client({
  apiKey: process.env.FEATUREFLOW_SERVER_KEY,
  withFeatures: [
    new Featureflow.Feature('new-checkout', 'off').build(),
  ],
});

Feature flags in React

On the client, the React SDK provides a provider and hooks. Wrap your app once, then evaluate flags in any component:

npm install --save react-featureflow-client

import {
  withFeatureflowProvider,
  useFeatureflow,
} from 'react-featureflow-client';

function Checkout() {
  const featureflow = useFeatureflow();

  if (featureflow.evaluate('new-checkout').isOn()) {
    return <NewCheckout />;
  }
  return <ClassicCheckout />;
}

// One provider at the top of your component tree
export default withFeatureflowProvider({
  apiKey: 'js-env-YOUR-CLIENT-KEY',
  user: {
    attributes: { tier: 'gold', country: 'australia' },
  },
})(App);

Components re-render automatically when a rule changes, so flipping a flag in the dashboard updates live sessions in real time. The same pattern is available for Java, JavaScript, Angular, React Native, and more, plus a REST API for everything else.

Common use cases