v1.0.0 latest

Feature Flags

A feature flag is a runtime switch that controls whether a feature is active for a given user, environment, or context. Flagify supports several flag types to cover different use cases.

Flag types

Boolean flags

The simplest type. Returns true or false.

const isEnabled = flagify.isEnabled('dark-mode');

Use boolean flags for:

  • Showing or hiding a feature
  • Enabling or disabling a code path
  • Kill switches for production incidents
Example: Kill switch for a new payment provider 
// Quickly disable a problematic integration
const useNewPaymentProvider = flagify.isEnabled('new-payment-provider');

if (useNewPaymentProvider) {
  await processWithStripeV2(order);
} else {
  await processWithStripeLegacy(order);
}

If the new payment provider causes issues in production, disable the flag instantly from the CLI or dashboard — no deploy required.

Example: Feature gating by plan 
// User context is set at initialization time via options.user
const canExport = flagify.isEnabled('csv-export');

if (canExport) {
  showExportButton();
}

Gate premium features behind a flag and control access via targeting rules instead of hardcoding plan checks.

Multivariate flags

Returns one of several predefined string variants. Use getValue<string>() to read the variant:

const variant = flagify.getValue<string>('pricing-page');
// 'control' | 'variant-a' | 'variant-b'

In React, use the useVariant hook:

import { useVariant } from '@flagify/react';
const variant = useVariant('pricing-page', 'control');

Use multivariate flags for:

  • A/B/n testing
  • Phased UI migrations
  • Regional customization
Example: A/B test on a signup flow 
const signupVariant = flagify.getValue<string>('signup-flow');

switch (signupVariant) {
  case 'streamlined':
    return <StreamlinedSignup />;
  case 'social-first':
    return <SocialSignup />;
  case 'control':
  default:
    return <ClassicSignup />;
}

Each user is consistently assigned the same variant. Track conversion rates per variant to determine which flow performs best.

Example: Regional checkout experience 
const checkoutStyle = flagify.getValue<string>('checkout-layout');
// 'single-page' for US/UK, 'multi-step' for EU, 'mobile-first' for SEA
renderCheckout(checkoutStyle);

Use targeting rules to assign variants by region, then iterate on each experience independently.

Value flags (Remote Config)

Returns a typed value — string, number, or JSON object.

const maxRetries = flagify.getValue<number>('max-retries');
const config = flagify.getValue<OnboardingConfig>('onboarding-config');

Use value flags for:

  • Runtime configuration
  • Tuning thresholds without deploys
  • Dynamic content
Example: Dynamic rate limiting 
const rateLimit = flagify.getValue<number>('api-rate-limit', 100);

// Adjust rate limits in production without a deploy
rateLimiter.setMaxRequests(rateLimit);

Tune performance-sensitive values in real time. Useful during traffic spikes or incident response.

Example: Remote config for onboarding steps 
interface OnboardingConfig {
  steps: string[];
  showProgressBar: boolean;
  skipIfReturning: boolean;
}

const config = flagify.getValue<OnboardingConfig>('onboarding-config', {
  steps: ['welcome', 'profile', 'invite-team'],
  showProgressBar: true,
  skipIfReturning: false,
});

renderOnboarding(config);

Store complex configuration objects as flag values. Update the onboarding flow without code changes.

Flag evaluation

When you evaluate a flag, Flagify follows this process:

  1. Check if the flag exists — if not, return the fallback value (or false for isEnabled)
  2. Check the environment — only evaluate rules matching the current environment (determined by the API key)
  3. Check if the flag is enabled — if enabled is false, skip all rules and return the flag’s offValue
  4. Evaluate targeting rules — match the user context against rules in priority order; the first matching rule determines the value
  5. No match fallback — if targeting rules exist but none matched, return the flag’s offValue (user is not targeted)
  6. Default fallback — if no targeting rules are defined, return the flag’s defaultValue

Each flag has two fallback values:

  • offValue — returned when the flag is disabled, or when targeting rules exist but none matched the user.
  • defaultValue — returned when the flag is enabled and no targeting rules are defined.

This behavior is identical for all flag types (boolean, string, number, json):

if flag is disabled            → return offValue
if a rule matches              → return rule's valueOverride
if rules exist but none match  → return offValue
if no rules are defined        → return defaultValue

Flag lifecycle

A typical flag goes through these stages:

  1. Created — defined via the CLI or API with a name and type
  2. Configured — targeting rules and environment settings are added
  3. Deployed — the SDK evaluates it in your application
  4. Rolled out — gradually enabled for more users
  5. Permanent or removed — either kept as a long-term toggle or cleaned up after full rollout