Skip to Content
PlatformFeature Flags

Feature Flags

Feature flags allow you to control the behavior of your application without deploying new code. Instead of shipping features to all users at once, you can enable or disable functionality dynamically. In simple terms, a feature flag is a decision point in code. You deploy the code once, then decide when and for whom it activates.

Teams use feature flags to release features gradually, test changes safely in production, and quickly roll back problematic releases.

Feature flags help teams:

  • Reduce deployment risk by separating feature releases from code deployments
  • Roll out features gradually to a subset of users
  • Run experiments and A/B tests
  • Disable features instantly if something goes wrong
  • Target features to specific users, segments, or environments

How Supaship powers feature flags

Supaship turns raw “if/else flags” into a complete release control system. When your SDK requests a feature flag, Supaship evaluates:

  1. the feature flag configuration
  2. targeting rules in the selected environment
  3. user/application context (userId, appVersion, country, etc.)

Then it returns the correct variation in real time.

This gives you three practical superpowers:

  1. Controlled rollouts: Start with internal users, then 5%, 25%, 50%, and finally 100%. You can ramp safely while watching metrics.

  2. Precise targeting: Target by user attributes, segments, and environment rules. You avoid broad “everyone gets it” launches when only specific users should see a change.

  3. Instant recovery: If a feature causes problems, disable or narrow it immediately. No emergency redeploy required.

Create your first feature flag

  1. Go to your project and click “Create Feature Flag”
  2. Enter a clear key (for example new-checkout-flow)
  3. Choose a type: Boolean or JSON
  4. Click “Create”

After creation, configure targeting so only the intended audience sees it.

Feature Flag Creation

Flag Types

Boolean Flags

Use boolean flags for on/off product behavior. They are ideal when you want a binary decision: show new flow vs old flow.

const isEnabled = await client.getFeature('beta-banner')
 
if (isEnabled) {
  showBetaBanner()
}

Common use cases: gradual releases, kill switches, beta access.

JSON Flags (Remote Config)

Remote config lets you change feature behavior without redeploying. Instead of a simple on/off, you store structured configuration (JSON) that Supaship returns based on targeting rules. Adjust settings in the dashboard and they apply immediately.

Config structure

  • Key-value pairs: each config is a JSON object (string, number, array, or nested object)
  • Environment-specific: targeting rules can return different config per environment
  • Fallback: if no rule matches, Supaship returns the default value you define in code

Use cases

  • Basic config — Store feature-specific settings (e.g. { maxRetries: 3, timeout: 5000 }) and update them anytime
  • Multi-variant flags — Different payloads for A/B tests or experiments (e.g. variant-a vs variant-b)
  • Entitlements by tier — Return different config per plan: free vs premium vs enterprise get different limits or capabilities

How matching works

When your app requests a JSON flag, Supaship evaluates targeting rules in order. The first matching rule determines the returned config. If none match, your SDK fallback (defined in features) is used.

const config = await client.getFeature('api-config')
 
const apiClient = new ApiClient(config)

With the React SDK:

const { feature: config } = useFeature('ai-summarizer')
 
// config might be { model: 'gpt-4', maxTokens: 1000 } for premium users
// or { model: 'gpt-3.5', maxTokens: 500 } for free users
return config ? <AISummarizer model={config.model} maxTokens={config.maxTokens} /> : null

If you only need one numeric/string parameter, use a small object with one property and keep the contract explicit. Do not store secrets (API keys, passwords) in remote config.

Naming that stays maintainable

Good flag keys describe behavior and domain, not temporary implementation details.

  • Better: checkout.new-flow, billing.tax-v2, search.semantic-results
  • Avoid: test-flag, new-ui-final, feature-123

A stable naming scheme makes cleanup, ownership, and debugging much easier.

From release to insight

Supaship does not stop at evaluation. It helps you observe rollout impact so you can make better release decisions:

  • who received which variation
  • whether adoption improved
  • whether errors or key KPIs regressed

In practice, the release loop becomes: ship -> target -> measure -> ramp (or roll back).

Last updated on
Core conceptsSegments