DEV Community: Domenico Giordano

A/B Testing with Feature Flags: Ship Experiments Without the Complexity

Domenico Giordano — Fri, 01 May 2026 23:43:44 +0000

This was originally published on rollgate.io/blog/ab-testing-feature-flags.

Why A/B Test with Feature Flags?

Most teams think A/B testing requires a dedicated experimentation platform — Optimizely, LaunchDarkly Experimentation, or Google Optimize (RIP). These tools cost thousands per month, add SDK bloat, and introduce yet another vendor into your stack.

Here's the thing: if you already have feature flags, you already have 80% of what you need for A/B testing.

A feature flag with percentage-based rollout is fundamentally an A/B test. The only missing pieces are:

Consistent assignment — same user always sees the same variant
Variant tracking — recording which variant each user saw
Metric collection — measuring outcomes per variant
Statistical analysis — determining if the difference is real

Let's build this step by step.

The Basics: Flags as Experiments

A traditional feature flag splits users into two groups: flag ON vs flag OFF. An A/B test does the same thing, but with intent — you're measuring which group performs better on a specific metric.

// This is a feature flag
const showNewPricing = rollgate.isEnabled('new-pricing-page', { userId });

// This is also an A/B test
// Same code, different intent
if (showNewPricing) {
  renderNewPricingPage(); // Variant B
  track('pricing_page_view', { variant: 'new' });
} else {
  renderCurrentPricingPage(); // Variant A (control)
  track('pricing_page_view', { variant: 'control' });
}

The code is identical. The difference is operational: you're tracking outcomes and making a data-driven decision.

Consistent User Assignment

The most important requirement for A/B testing is consistency — a user must always see the same variant for the duration of the experiment. If user #42 sees the new pricing page on Monday, they must see it on Tuesday too.

Feature flags handle this through sticky assignment. When you pass a userId (or any stable identifier) to the flag evaluation, the system hashes it deterministically:

// Rollgate SDK handles this automatically
const variant = rollgate.isEnabled('new-pricing-page', {
  userId: user.id, // Stable identifier
});

// Same userId always gets the same result
// No database lookup, no cookie required

This works because good feature flag systems use consistent hashing (like MurmurHash) on the user ID. The hash maps to a number between 0-100, and if your rollout is at 50%, users with hash < 50 get the variant, others get the control.

Why this matters: Cookie-based assignment breaks across devices. Server-side hashing on user ID works everywhere — web, mobile, API, email.

Designing Your Experiment

Before writing code, define three things:

1. Hypothesis

Bad: "Let's see if the new pricing page is better."

Good: "Changing the pricing page CTA from 'Start Free Trial' to 'Get Started Free' will increase trial signups by at least 10%."

A clear hypothesis tells you what to measure and when to stop.

2. Primary Metric

Pick one metric that determines success. Secondary metrics are fine for context, but having multiple primary metrics inflates your false positive rate.

Experiment	Bad Primary Metric	Good Primary Metric
New checkout flow	Page views	Completed purchases
Pricing page redesign	Time on page	Trial signups
Search algorithm	Searches performed	Click-through on first result

3. Sample Size

This is where most teams mess up. You need enough data to detect a meaningful difference. Running an experiment for 2 days with 100 users proves nothing.

Rule of thumb for a standard A/B test:

5% conversion rate baseline → need ~1,500 users per variant to detect a 20% relative change
2% conversion rate baseline → need ~4,000 users per variant
High-traffic pages → you might have enough data in days
Low-traffic pages → it might take weeks

Don't stop the experiment early because one variant "looks better." That's the statistical equivalent of flipping a coin 5 times, getting 4 heads, and concluding the coin is biased.

Implementation Pattern

Here's a practical implementation using feature flags:

Step 1: Create the Flag

Set up a boolean feature flag with percentage-based rollout:

Flag name: experiment-pricing-cta
Rollout: 50% (half see variant B, half see control)
Targeting: All logged-in users

Step 2: Instrument Your Code

// Server-side (Node.js example)
app.get('/pricing', async (req, res) => {
  const showNewCTA = rollgate.isEnabled('experiment-pricing-cta', {
    userId: req.user.id,
  });

  // Track exposure
  analytics.track('experiment_exposure', {
    experiment: 'pricing-cta',
    variant: showNewCTA ? 'new-cta' : 'control',
    userId: req.user.id,
  });

  res.render('pricing', { showNewCTA });
});

// Client-side (React example)
function PricingPage() {
  const showNewCTA = useFlag('experiment-pricing-cta');

  useEffect(() => {
    analytics.track('experiment_exposure', {
      experiment: 'pricing-cta',
      variant: showNewCTA ? 'new-cta' : 'control',
    });
  }, [showNewCTA]);

  return (
    <div>
      <h1>Choose your plan</h1>
      <Button onClick={handleSignup}>
        {showNewCTA ? 'Get Started Free' : 'Start Free Trial'}
      </Button>
    </div>
  );
}

Step 3: Track Conversions

// When the target action happens
function handleSignup(plan) {
  analytics.track('trial_signup', {
    experiment: 'pricing-cta',
    variant: rollgate.isEnabled('experiment-pricing-cta', { userId })
      ? 'new-cta'
      : 'control',
    plan: plan,
  });
}

Step 4: Analyze Results

After reaching your target sample size, pull the data:

-- Conversion rate per variant
SELECT
  variant,
  COUNT(DISTINCT user_id) as users,
  COUNT(DISTINCT CASE WHEN converted THEN user_id END) as conversions,
  ROUND(
    COUNT(DISTINCT CASE WHEN converted THEN user_id END)::numeric /
    COUNT(DISTINCT user_id) * 100, 2
  ) as conversion_rate
FROM experiment_events
WHERE experiment = 'pricing-cta'
GROUP BY variant;

variant	users	conversions	conversion_rate
control	12,847	411	3.20%
new-cta	12,903	658	5.10%

A 59% relative improvement looks great — but is it statistically significant? Use a chi-squared test or an online calculator. At these numbers, p < 0.001 — this is a real effect, not noise.

Multi-Variant Tests (A/B/n)

Sometimes you want to test more than two variants. Feature flags support this through string variants instead of boolean on/off:

// Flag returns a string variant instead of boolean
const ctaVariant = rollgate.getVariant('experiment-pricing-cta', {
  userId: user.id,
});

// ctaVariant could be: 'control', 'free-trial', 'get-started', 'try-now'
const ctaText = {
  'control': 'Start Free Trial',
  'free-trial': 'Try Free for 14 Days',
  'get-started': 'Get Started Free',
  'try-now': 'Try Now — No Card Required',
}[ctaVariant];

Warning: More variants means more traffic needed. With 4 variants, you need roughly 4x the sample size of a simple A/B test to reach significance.

Common Pitfalls

1. Peeking at Results Too Early

Looking at experiment data daily and stopping when you see significance is called optional stopping, and it dramatically inflates false positives. Set your sample size upfront and wait.

If you absolutely must peek, use sequential testing methods that account for multiple looks at the data.

2. Running Too Many Experiments Simultaneously

If experiments overlap (same user is in multiple experiments), interactions between them can pollute your results. Keep concurrent experiments on different parts of the product, or use mutually exclusive experiment groups.

3. Not Accounting for Novelty Effect

Users often engage more with anything new simply because it's new. A new UI might show higher engagement in week 1 that drops off by week 3. Run experiments long enough to capture steady-state behavior — typically 2-4 weeks.

4. Survivorship Bias

If your experiment only measures users who reach a certain point (e.g., checkout), you're missing the users who dropped off earlier. Always measure from the point of exposure, not from the point of conversion.

5. Ignoring Segments

An experiment might show no overall effect but have a strong positive effect on mobile users and a negative effect on desktop users. Check segment-level results for:

Device type (mobile vs desktop)
New vs returning users
Geography
Plan tier

When NOT to A/B Test

Not everything needs an experiment:

Bug fixes — just fix them
Legal/compliance changes — not optional
Performance improvements — measure, don't A/B test
Changes with < 1,000 weekly users exposed — you won't reach significance in a reasonable time
Obvious improvements — if the old version is clearly broken, skip the test

A/B testing is for decisions where the answer isn't obvious and the stakes justify the effort.

Feature Flags vs Dedicated A/B Testing Platforms

Capability	Feature Flags	Dedicated Platform
Traffic splitting	Yes	Yes
Consistent assignment	Yes	Yes
Multi-variant support	Yes	Yes
Built-in analytics	Basic	Advanced
Statistical engine	DIY or basic	Built-in
Bayesian analysis	No (usually)	Yes
Visual editor	No	Yes
Price	$0-99/mo	$1,000-10,000+/mo

Use feature flags when you run < 10 experiments per month, have engineers who can write code for variants, and want to keep your stack simple.

Use a dedicated platform when experimentation is a core competency, you run dozens of concurrent experiments, and you need non-engineers to create tests.

For most teams under 50 engineers, feature flags are more than enough.

Getting Started

Here's a practical checklist for your first A/B test with feature flags:

Pick a high-traffic page where you can reach sample size in 1-2 weeks
Define your hypothesis and primary metric before writing code
Calculate sample size using an online calculator
Create a flag with 50% rollout and user-based targeting
Instrument exposure and conversion events in your analytics
Wait for full sample size — don't peek and stop early
Analyze results and document the decision
Clean up — roll the winner to 100% and remove the flag

The best part? If you're already using feature flags for releases, you already have the infrastructure. You just need to add tracking and discipline.

Rollgate supports percentage-based rollouts with consistent user assignment out of the box — everything you need to run A/B tests without adding another vendor to your stack. Get started free.

Related reading: Learn the fundamentals in What Are Feature Flags?, see how to implement gradual rollouts step by step, or check out our SDK tutorials for React, Next.js, and Python. For pricing across platforms, see our feature flags pricing comparison.

Scheduled Feature Releases: Ship at 3am Without Staying Awake

Domenico Giordano — Fri, 01 May 2026 23:43:43 +0000

This was originally published on rollgate.io/blog/feature-flags-scheduled-releases.

The 3am Deploy Problem

Feature flags scheduled releases solve one of the most painful problems in software delivery: timed launches across time zones. Every developer has been there. The product launch is scheduled for Monday morning in Tokyo, which means Sunday night in Berlin and Sunday afternoon in San Francisco. Someone has to be online to press the button.

The usual options:

Someone stays awake. An engineer watches the terminal at 3am, runs the deploy, monitors for errors, and hopes nothing breaks. If it does, they're debugging production while sleep-deprived.
You write a cron job. A scheduled CI/CD pipeline that triggers at the right time. It works until it doesn't — and when it fails, there's no one watching.
You deploy early and hope. Ship the code on Friday, pray the feature doesn't leak over the weekend, and flip a config value Monday morning. Now you've added the risk of accidental exposure.

None of these are good. They're workarounds for a missing tool: the ability to schedule a feature flag change for a specific date and time, with automatic rollback if something goes wrong.

How Scheduled Feature Flags Work

Scheduled feature flags separate deployment from release. Your code ships to production behind a flag that's turned off. You then schedule the flag to enable at a specific time — no deploys, no cron jobs, no humans required.

The concept is simple:

Deploy code with the feature wrapped in a flag (disabled by default)
Set a schedule — enable_at: 2026-04-01T00:00:00Z
Optionally set a disable time — disable_at: 2026-04-01T06:00:00Z for maintenance windows
The system flips the flag at the scheduled time
If something breaks, roll back to the previous state in one click

The flag evaluation happens on the server side. When the scheduled time arrives, the flag's state changes in the database. SDKs pick up the change via SSE (real-time) or polling (typically within 30 seconds).

Scheduled Releases with Rollgate: A Practical Example

Let's walk through a real scenario. You're launching a new onboarding flow for your SaaS product. The launch is planned for April 1st at 9am CET.

Step 1: Deploy Behind a Flag

Your code ships with the new onboarding wrapped in a feature flag:

import { useFlag } from '@rollgate/sdk-react';

function OnboardingFlow() {
  const useNewOnboarding = useFlag('new-onboarding-v2', false);

  if (useNewOnboarding) {
    return <NewOnboarding />;
  }
  return <LegacyOnboarding />;
}

This code deploys to production days or weeks before launch. The flag is off, so all users see the old onboarding. Zero risk.

Step 2: Test with Internal Users

In the Rollgate dashboard, you create a segment for your QA team — a list-based segment with their user IDs. You enable the flag for this segment only. QA tests the new onboarding in production with real data, real integrations, real edge cases.

Step 3: Schedule the Launch

In the dashboard, you set:

Enable at: 2026-04-01T07:00:00Z (9am CET)
Percentage: 100% of users
Targeting: All users (remove QA-only restriction)

That's it. No one needs to be online at 9am. The flag enables automatically.

Step 4: Monitor and Roll Back if Needed

Your monitoring picks up a spike in errors 20 minutes after launch. The on-call engineer opens the Rollgate dashboard and clicks "Rollback." The flag reverts to its previous state — QA-only — in under 2 seconds. Users are back on the old onboarding while the team investigates.

On the backend, the same flag works with the Node.js SDK:

import { RollgateClient } from '@rollgate/sdk-node';

const client = new RollgateClient({
  apiKey: process.env.ROLLGATE_SERVER_KEY,
  enableSSE: true, // instant updates when the schedule triggers
});

await client.initialize();

app.post('/api/onboarding/start', async (req, res) => {
  const useNew = client.isEnabled('new-onboarding-v2', {
    id: req.user.id,
    attributes: {
      plan: req.user.plan,
      country: req.user.country,
    },
  });

  if (useNew) {
    return res.json(await startNewOnboarding(req.user));
  }
  return res.json(await startLegacyOnboarding(req.user));
});

When the scheduled time arrives, the SSE connection pushes the flag update to your server. The next request evaluates the flag as true, and the new onboarding is live — no restart, no redeploy.

Real-World Use Cases for Scheduled Feature Flags

Product Launches Across Time Zones

Schedule a flag to enable at 9am in each region. Use targeting rules to match users by country, so the feature rolls out at the right local time for each market.

Gradual Rollouts on a Schedule

Instead of manually increasing percentage rollout, schedule the stages:

Monday 10am: 5% of users
Wednesday 10am: 25% of users
Friday 10am: 100% of users

If metrics drop at any stage, roll back before the next one triggers.

Maintenance Windows

Schedule a maintenance banner to appear at midnight and disappear at 6am:

const showMaintenance = useFlag('maintenance-banner', false);
// enable_at: 2026-04-05T22:00:00Z
// disable_at: 2026-04-06T04:00:00Z

No code changes, no deploys, no one staying awake to turn it off.

Pricing Changes

Switching to new pricing? Schedule the flag for the start of the billing cycle. All users see the new pricing page simultaneously, and if something is wrong with the display, roll back instantly.

Time-Limited Promotions

Black Friday sale that runs for exactly 48 hours? Schedule the enable and disable times. The promotion starts and ends automatically, and there's no risk of forgetting to turn it off Monday morning.

Beta Expirations

Give beta users access to a feature for 30 days. Set enable_at for today and disable_at for 30 days from now. When the beta period ends, the feature disables automatically and users see an upgrade prompt instead.

Best Practices for Scheduled Feature Releases

1. Always Have a Rollback Plan

Never schedule a release without knowing how to undo it. With Rollgate, 1-click rollback is built in — it restores the exact previous state including targeting rules, percentage, and flag value.

2. Deploy Code Well Before the Schedule

Ship the code behind a disabled flag days before the scheduled release. This separates deployment risk from release risk. If the deploy breaks something, you catch it before launch day.

3. Use Gradual Rollout with Scheduling

Don't go from 0% to 100% in one step. Schedule a gradual increase: 5% → 25% → 50% → 100% over several days. Each stage gives you time to monitor metrics and catch issues before they affect all users.

4. Test with Internal Segments First

Before scheduling a public release, enable the flag for an internal segment (your team, beta testers, or a QA group). Catch bugs in a controlled environment, then schedule the public rollout.

5. Set Alerts on Flag Changes

Use webhooks to get notified when a scheduled flag change triggers. Rollgate sends flag.scheduled and flag_state.updated events to your webhook endpoint, so your monitoring pipeline knows when a flag changed state.

6. Document Your Schedules

Use flag descriptions in the dashboard to note why a schedule was set. "Launch new checkout — coordinated with marketing email campaign at 10am CET" gives context to the next engineer who sees the flag.

Stop Losing Sleep Over Releases

Scheduled feature flags eliminate the operational overhead of timed releases. No more 3am deploys, no more cron jobs that fail silently, no more "who's going to flip the flag?"

Rollgate includes scheduled changes on every paid plan, starting at €39/month. The free tier (500K requests/month) includes everything except scheduling and rollback — enough to evaluate the platform and start wrapping features in flags.

Get started at rollgate.io or explore the live demo.

For more on feature flags, read our guides on what feature flags are, gradual rollout strategies, A/B testing with feature flags, and our feature flags pricing comparison. Switching from another tool? See our LaunchDarkly alternative and ConfigCat alternative guides.

How We Test a Feature Flag Platform: 1,192 Tests Across 13 SDKs

Domenico Giordano — Fri, 01 May 2026 14:38:18 +0000

This was originally published on rollgate.io/blog/how-we-test-rollgate.

The Testing Problem No One Talks About

Building a feature flag platform means building something that sits in the critical path of every request your customers serve. If a flag evaluation returns the wrong result, your customer's checkout page shows the wrong UI. If the SDK crashes, your customer's app crashes. If the SSE connection drops, flags go stale.

The testing surface is enormous:

13 SDKs across 7 languages — React, Vue, Angular, Svelte, Node.js, Go, Python, Java, .NET, Flutter, React Native, Browser
A backend API handling flag evaluation in ~200μs P99
Real-time streaming via Server-Sent Events to thousands of concurrent connections
Consistent hashing that must produce identical results across every SDK

I built Rollgate solo over the past year. Here's how I test all of it with 1,192 test cases and what I learned along the way.

The Test Pyramid

           /\
          /  \     E2E (6)
         /    \    Playwright, real browser
        /------\
       /        \  Contract (124)
      /          \ Cross-SDK behavioral consistency
     /------------\
    /              \  Integration (58)
   /                \ SDK ↔ API server, resilience
  /------------------\
 /                    \  Unit (1,004)
/______________________\ Go API, React, SDKs, evaluation engine

Layer	Count	Run Time	What It Guarantees
Unit	1,004	under 1 min	Logic correctness
Integration	58	~2 min	Component interaction
Contract	124	~5 min	All 13 SDKs behave identically
E2E	6	~2 min	Full user flows work
Total	1,192	~10 min	—

Plus 5 load/stress harness scripts that aren't test cases but verified the system handles 28,000 concurrent SSE connections on a single node.

Layer 1: Unit Tests (1,004)

Unit tests cover the core logic without external dependencies. The most important area is the evaluation engine — the function that takes a flag configuration and a user context and returns a value.

Testing Consistent Hashing

The heart of percentage rollouts is consistent hashing. When you set a flag to 10% rollout, the system uses SHA-256(flagKey + userId) % 10000 to deterministically assign each user to a bucket. The same user must always get the same result.

This is easy to get wrong. The most common mistake is using Math.random() (or rand() in Go), which makes users flicker between variants across page loads.

Our test verifies three properties:

Consistency: The same user + flag always returns the same boolean, 1,000 times in a row
Distribution: Over 10,000 users at 10% rollout, roughly 10% see true (within statistical tolerance)
Monotonicity: Increasing rollout from 10% to 20% never removes a user who was already in the 10%

func TestIsInRollout_Consistency(t *testing.T) {
    // Same user + same flag = same result, always
    results := make(map[bool]int)
    for i := 0; i < 1000; i++ {
        results[isInRollout("flag-1", "user-42", 10)] ++
    }
    // Should have exactly 1 unique result
    if len(results) != 1 {
        t.Error("Inconsistent rollout result for same user")
    }
}

func TestIsInRollout_Distribution(t *testing.T) {
    enabled := 0
    total := 10000
    for i := 0; i < total; i++ {
        if isInRollout("test-flag", fmt.Sprintf("user-%d", i), 10) {
            enabled++
        }
    }
    // Should be roughly 10% (allow 8-12% for statistical variance)
    ratio := float64(enabled) / float64(total) * 100
    if ratio < 8 || ratio > 12 {
        t.Errorf("Expected ~10%%, got %.1f%%", ratio)
    }
}

Property 3 (monotonicity) is what makes gradual rollouts actually "gradual" — when you increase from 10% to 20%, the 10% who already saw the feature continue to see it. New users are added, never removed.

Testing Targeting Rules

The targeting rule engine supports 18 operators: equals, notEquals, contains, notContains, startsWith, endsWith, in, notIn, greaterThan, greaterEqual, lessThan, lessEqual, regex, isSet, isNotSet, semverGt, semverLt, semverEq.

Each operator has its own test cases, including edge cases:

What happens when the attribute doesn't exist on the user?
What if the attribute value is a number but the rule expects a string?
What if the regex is invalid?
What if the semver string doesn't have a v prefix?

We have ~50 tests for the evaluation engine alone. These are the most important tests in the entire codebase because a bug here means every customer gets wrong flag values.

Testing the Web Frontend

The dashboard has 178 tests covering React components, hooks, and the API client. Most use React Testing Library:

describe('ConfirmDialog', () => {
  it('renders destructive variant with correct styling', () => {
    render(
      <ConfirmDialog
        open={true}
        title="Delete Flag"
        description="This cannot be undone."
        variant="destructive"
        onConfirm={jest.fn()}
        onCancel={jest.fn()}
      />
    );
    expect(screen.getByText('Delete Flag')).toBeInTheDocument();
    expect(screen.getByRole('button', { name: /confirm/i }))
      .toHaveClass('bg-red');
  });
});

The API client tests (34 cases) are particularly important because they verify error handling, authentication flow, and how the frontend reacts to various HTTP status codes from the backend.

Layer 2: Integration Tests (58)

Integration tests verify that components work together correctly. Each SDK has integration tests that exercise the full cycle: initialize → fetch flags → evaluate → receive updates.

The most interesting integration tests are the resilience tests in the Node SDK (25 tests). These simulate failure scenarios:

API server goes down → SDK falls back to cached values
API returns malformed JSON → SDK doesn't crash
SSE connection drops → SDK reconnects automatically
Circuit breaker opens after failures → SDK stops making requests temporarily
Circuit breaker recovers → SDK resumes normal operation

These tests use a mock HTTP server that can be programmed to fail in specific ways:

it('falls back to cache when API returns 500', async () => {
  // First request succeeds and populates cache
  mockServer.respondWith(200, { flags: { 'my-flag': true } });
  const client = createClient({ apiKey: 'test' });
  await client.initialize();

  // Second request fails
  mockServer.respondWith(500, 'Internal Server Error');
  await client.refresh();

  // Should still return cached value
  expect(client.isEnabled('my-flag')).toBe(true);
});

This is where most feature flag SDKs fail in practice. The SDK itself becomes a single point of failure — if it crashes on initialization or doesn't handle network errors gracefully, it takes down the customer's application. The circuit breaker pattern is critical: after N consecutive failures, the SDK stops trying and serves cached values until the API recovers.

Layer 3: Contract Tests (124) — The Most Important Layer

This is the layer that most feature flag platforms skip, and it's the one that matters most.

The Problem: SDK Drift

When you have 13 SDKs across 7 languages, behavioral drift is inevitable. A flag might evaluate to true in the Node SDK but false in Go for the same user — because the consistent hashing implementation used a different byte order, or the targeting rule engine parsed a numeric attribute differently.

The only way to prevent this is contract testing: run the exact same assertions against every SDK and verify they all produce identical results.

How It Works

The contract test harness is a Go program that:

Starts a real Rollgate API server with PostgreSQL and Redis
Seeds test flags with known configurations (boolean flags, string variants, percentage rollouts, targeting rules with every operator)
Starts each SDK's test service — a small HTTP server that wraps the SDK and exposes a uniform REST API:
- POST /evaluate → evaluates a flag for a given user
- POST /identify → changes the user context
- GET /health → verifies the SDK is connected
Runs 124 identical test cases against each SDK service
Compares results — every SDK must return the same value for the same flag + user combination

// This test runs against EVERY SDK adapter
func TestBooleanFlag_Enabled(t *testing.T) {
    flag := seedFlag(t, "test-boolean", FlagConfig{
        Type:    "boolean",
        Enabled: true,
        Rollout: 100,
    })

    for _, sdk := range sdkAdapters {
        t.Run(sdk.Name, func(t *testing.T) {
            result := sdk.Evaluate(flag.Key, testUser)
            assert.True(t, result.Enabled)
            assert.Equal(t, true, result.Value)
            assert.Equal(t, "FALLTHROUGH", result.Reason)
        })
    }
}

What Contract Tests Catch

In practice, contract tests have caught:

Hashing differences: Go's crypto/sha256 and Node's crypto.createHash('sha256') produce the same output, but the way we extracted 4 bytes from the hash differed between implementations. One SDK used big-endian, another used little-endian. Same user, different rollout bucket.
Operator inconsistencies: The contains operator was case-sensitive in the Go SDK but case-insensitive in the Node SDK. Without contract tests, a targeting rule like "country contains US" would match "us" in Node but not in Go.
Default value handling: When a flag is disabled, some SDKs returned null while others returned the configured default value. Both are "correct" depending on your perspective, but they must be consistent.
Evaluation reason strings: The Node SDK reported "RULE_MATCH" while the Go SDK reported "rule_match". The casing difference broke clients that parsed the reason string.

None of these bugs would have been caught by unit tests. They only surface when you compare two SDKs against the same input.

Why Not Just Test Each SDK Independently?

Because independent tests test the implementation, not the contract. Each SDK's test suite can pass while the SDKs disagree with each other. Contract tests are the only way to verify cross-SDK consistency.

The analogy: unit tests verify that each musician plays their part correctly. Contract tests verify that the orchestra is in tune.

Layer 4: E2E Tests (6)

End-to-end tests use Playwright to verify complete user flows in a real browser against production or staging:

OAuth login callback → authenticated redirect
Session cookie security flags (HttpOnly, SameSite, Secure)
SSE flag propagation (create account → create flag → toggle → verify real-time update)

We have only 6 E2E tests because they're slow, flaky by nature, and expensive to maintain. The contract tests handle most of what E2E would typically cover — verifying that the system works correctly from the SDK's perspective.

The Stress Test: 28,000 Concurrent SSE Connections

The most dramatic test isn't a test case at all — it's a stress harness written in Go:

// sse-stress.go - simplified
func main() {
    var connected int64
    for i := 0; i < 30000; i++ {
        go func() {
            resp, _ := http.Get(sseURL)
            atomic.AddInt64(&connected, 1)
            // Hold connection open
            io.Copy(io.Discard, resp.Body)
        }()
    }
    // Monitor connected count
    for {
        fmt.Printf("Connected: %d\n", atomic.LoadInt64(&connected))
        time.Sleep(time.Second)
    }
}

On a CX33 VPS (4 vCPU, 8GB RAM, €13/month), the system sustained 28,000 concurrent SSE connections before hitting kernel limits. At that point:

CPU: ~60%
Memory: ~4GB (mostly TCP buffers)
Flag evaluation latency: unchanged at ~200μs P99
Flag change propagation: under 500ms to all connected clients

This test informed our pricing tiers: the Growth plan allows 500 SSE connections per environment, which is far below what a single node can handle. We have headroom.

Lessons Learned

1. Contract Tests Are Non-Negotiable for Multi-SDK Products

If you build SDKs for multiple languages, contract tests are the single highest-value investment you can make. They catch bugs that no other test layer can find, and they give you confidence to ship SDK updates without breaking cross-SDK consistency.

2. Test the Failure Modes, Not Just the Happy Path

The resilience integration tests (circuit breaker, cache fallback, reconnection) have caught more production issues than any other test suite. When your SDK sits in someone else's critical path, graceful degradation is more important than feature completeness.

3. The Test Pyramid Is Real — Respect It

We have 1,004 unit tests, 58 integration tests, 124 contract tests, and 6 E2E tests. The ratio matters. Unit tests are fast and reliable. E2E tests are slow and flaky. Every time I've been tempted to add an E2E test, I've found a way to cover the same behavior at a lower layer.

4. Stress Tests Aren't Tests — They're Experiments

The SSE stress test doesn't have a pass/fail assertion. It's an experiment that reveals the system's limits. The result (28K connections on a €13/month VPS) became a selling point — but only because we actually measured it instead of guessing.

5. Count Your Tests Accurately

For months I told people we had "about 850 tests." When I actually counted, we had 1,192. The discrepancy came from not counting contract tests (124) and undertaking the Go API growth (294 → 452). If you're going to cite a number, make sure it's real.

The Full Breakdown

Area	Tests	Type
Go API (handlers, evaluation, middleware, models)	452	Unit
Web Frontend (components, hooks, API client)	178	Unit
SDK Core (cache, circuit breaker, retry, dedup)	53	Unit
SDK Node	166	Unit + Integration
SDK Go	100	Unit
SDK React	28	Unit + Integration
SDK Svelte	32	Unit + Integration
SDK Vue	22	Unit + Integration
SDK Angular	20	Unit
SDK Browser	11	Unit
Contract test harness	124	Contract
E2E (Playwright)	6	E2E
Total	1,192	—
Load/stress scripts	5	Harness

Every test runs on every PR via CI. The entire suite completes in under 10 minutes.

Rollgate is a feature flag platform with 13 SDKs and a free tier (500K requests/month). If you're interested in the architecture, see How I Built Rollgate. For gradual rollout strategies and how we compare to LaunchDarkly on pricing, check our pricing comparison. The SDKs are open source.

Feature Flags in Next.js: The Complete Guide (App Router)

Domenico Giordano — Fri, 01 May 2026 14:36:20 +0000

This was originally published on rollgate.io/blog/feature-flags-nextjs.

Why Feature Flags in Next.js?

Next.js is not a typical React app. With the App Router, your code runs in multiple environments — the server, the edge, and the browser — sometimes in the same request. This makes feature flags both more powerful and more complex than in a single-page application.

Here is why feature flags matter specifically for Next.js:

Server-Side Rendering creates a decision point. When a Server Component renders on the server, you need the flag value before sending HTML to the client. If you evaluate flags only on the client, users see a flash of the wrong content (or a loading spinner) before the correct variant appears.

Edge Middleware runs before rendering. Next.js middleware can redirect or rewrite requests at the edge, before any component renders. This is the ideal place for A/B testing entire pages — route users to /pricing-a or /pricing-b based on a flag, with zero layout shift.

Hybrid apps need a unified approach. A real Next.js application uses Server Components, Client Components, API routes, and middleware. You need feature flags that work consistently across all four, with the same flag key returning the same value for the same user regardless of where you evaluate it.

Feature flags in Next.js let you do gradual rollouts without redeploying, run A/B tests at the edge, and kill problematic features in seconds — all while keeping the performance benefits of server rendering.

Architecture: Where to Evaluate Flags

Before writing code, understand the four places you can evaluate feature flags in a Next.js App Router application:

Location	SDK	Runs On	Best For
Server Components	`@rollgate/sdk-node`	Server (Node.js)	Initial render, SEO content, data-dependent flags
Client Components	`@rollgate/sdk-react`	Browser	Interactive UI, real-time updates, user preferences
Middleware	`@rollgate/sdk-node`	Edge/Node	A/B testing pages, redirects, geo-targeting
API Routes	`@rollgate/sdk-node`	Server (Node.js)	Backend logic, rate limits, feature-gated endpoints

The general rule: evaluate flags as early as possible. If a flag controls what the user sees on page load, evaluate it on the server. If a flag controls interactive behavior after the page loads, evaluate it on the client.

Server-Side Feature Flags

Server Components in Next.js are async by default, which makes them a natural fit for feature flag evaluation. You fetch the flag value during rendering, and the user receives the correct HTML immediately — no loading state, no flash of wrong content.

Setup

Install the Node.js SDK:

npm install @rollgate/sdk-node

Create a shared Rollgate client that you can import anywhere on the server:

// lib/rollgate.ts
import { RollgateClient } from '@rollgate/sdk-node';

export const rollgate = new RollgateClient({
  apiKey: process.env.ROLLGATE_SERVER_KEY!,
  baseUrl: 'https://api.rollgate.io',
});

Using Flags in Server Components

// app/dashboard/page.tsx
import { rollgate } from '@/lib/rollgate';
import { getCurrentUser } from '@/lib/auth';

export default async function DashboardPage() {
  const user = await getCurrentUser();

  const showNewDashboard = await rollgate.isEnabled('new-dashboard', {
    userId: user.id,
    attributes: {
      plan: user.plan,
      email: user.email,
      createdAt: user.createdAt,
    },
  });

  if (showNewDashboard) {
    return <NewDashboard user={user} />;
  }

  return <LegacyDashboard user={user} />;
}

The userId ensures consistent evaluation — the same user always sees the same variant, even across multiple requests. The attributes enable targeting rules like "enable for Pro plan users" or "enable for users created after March 2026."

Server Components with Multiple Flags

When you need several flags in one component, evaluate them in parallel to avoid sequential waterfalls:

// app/settings/page.tsx
import { rollgate } from '@/lib/rollgate';
import { getCurrentUser } from '@/lib/auth';

export default async function SettingsPage() {
  const user = await getCurrentUser();

  const context = {
    userId: user.id,
    attributes: { plan: user.plan },
  };

  const [showBilling, showTeamSettings, showApiKeys] = await Promise.all([
    rollgate.isEnabled('settings-billing-v2', context),
    rollgate.isEnabled('team-management', context),
    rollgate.isEnabled('api-keys-section', context),
  ]);

  return (
    <div>
      <ProfileSettings />
      {showBilling && <BillingV2 />}
      {showTeamSettings && <TeamSettings />}
      {showApiKeys && <ApiKeysSection />}
    </div>
  );
}

Client-Side Feature Flags

Not everything runs on the server. Interactive components — modals, tooltips, dynamic forms, real-time features — live in Client Components. For these, use the React SDK, which provides a context provider and hooks.

Setup

Install the React SDK:

npm install @rollgate/sdk-react

Add the RollgateProvider in your root layout. Since providers require 'use client', create a wrapper component:

// components/providers.tsx
'use client';

import { RollgateProvider } from '@rollgate/sdk-react';

export function Providers({ children }: { children: React.ReactNode }) {
  return (
    <RollgateProvider
      apiKey={process.env.NEXT_PUBLIC_ROLLGATE_CLIENT_KEY!}
      baseUrl="https://api.rollgate.io"
    >
      {children}
    </RollgateProvider>
  );
}

// app/layout.tsx
import { Providers } from '@/components/providers';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>
        <Providers>{children}</Providers>
      </body>
    </html>
  );
}

Using Flags in Client Components

// components/feedback-widget.tsx
'use client';

import { useFlag } from '@rollgate/sdk-react';

export function FeedbackWidget() {
  const showFeedback = useFlag('feedback-widget');

  if (!showFeedback) return null;

  return (
    <div className="fixed bottom-4 right-4">
      <button className="rounded-full bg-blue-600 p-3 text-white shadow-lg">
        💬 Feedback
      </button>
    </div>
  );
}

The useFlag hook returns the flag's current value and automatically re-renders when the value changes (for example, if you toggle the flag in the Rollgate dashboard while the user has the page open).

User Context on the Client

To enable user targeting on the client, pass user context to the provider:

// components/providers.tsx
'use client';

import { RollgateProvider } from '@rollgate/sdk-react';

interface ProvidersProps {
  children: React.ReactNode;
  user?: {
    id: string;
    plan: string;
    email: string;
  };
}

export function Providers({ children, user }: ProvidersProps) {
  return (
    <RollgateProvider
      apiKey={process.env.NEXT_PUBLIC_ROLLGATE_CLIENT_KEY!}
      baseUrl="https://api.rollgate.io"
      context={user ? {
        userId: user.id,
        attributes: { plan: user.plan, email: user.email },
      } : undefined}
    >
      {children}
    </RollgateProvider>
  );
}

Middleware Feature Flags

Next.js middleware runs before any rendering happens. This makes it the ideal location for feature flag evaluations that control routing: A/B testing entire pages, geo-based redirects, or blocking access to unreleased sections.

// middleware.ts
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';
import { RollgateClient } from '@rollgate/sdk-node';

const rollgate = new RollgateClient({
  apiKey: process.env.ROLLGATE_SERVER_KEY!,
  baseUrl: 'https://api.rollgate.io',
});

export async function middleware(request: NextRequest) {
  // Use a cookie for consistent assignment
  const userId = request.cookies.get('visitor-id')?.value ?? crypto.randomUUID();

  const newPricingPage = await rollgate.isEnabled('new-pricing-page', {
    userId,
  });

  // A/B test: rewrite to a different page variant
  if (request.nextUrl.pathname === '/pricing' && newPricingPage) {
    const response = NextResponse.rewrite(new URL('/pricing-b', request.url));
    // Persist the visitor ID so they always see the same variant
    response.cookies.set('visitor-id', userId, { maxAge: 60 * 60 * 24 * 30 });
    return response;
  }

  // Gate access to unreleased features
  const betaEnabled = await rollgate.isEnabled('beta-access', { userId });

  if (request.nextUrl.pathname.startsWith('/beta') && !betaEnabled) {
    return NextResponse.redirect(new URL('/waitlist', request.url));
  }

  return NextResponse.next();
}

export const config = {
  matcher: ['/pricing', '/beta/:path*'],
};

This pattern is especially powerful for A/B testing landing pages. Users are routed to different page variants before any JavaScript runs, so there is zero layout shift and search engines see a complete page.

Combining Server and Client Flags

In many cases, you evaluate a flag on the server and pass the result to a Client Component. This avoids a second network request on the client and eliminates the loading state.

// app/page.tsx (Server Component)
import { rollgate } from '@/lib/rollgate';
import { getCurrentUser } from '@/lib/auth';
import { HeroBanner } from '@/components/hero-banner';

export default async function HomePage() {
  const user = await getCurrentUser();

  const showNewHero = await rollgate.isEnabled('new-hero-banner', {
    userId: user?.id,
  });

  return (
    <main>
      <HeroBanner variant={showNewHero ? 'new' : 'classic'} />
      {/* ... */}
    </main>
  );
}

// components/hero-banner.tsx (Client Component)
'use client';

import { useState } from 'react';

interface HeroBannerProps {
  variant: 'new' | 'classic';
}

export function HeroBanner({ variant }: HeroBannerProps) {
  const [email, setEmail] = useState('');

  if (variant === 'new') {
    return (
      <section className="bg-gradient-to-r from-blue-600 to-purple-600 py-20">
        <h1 className="text-5xl font-bold text-white">Ship Faster with Feature Flags</h1>
        <input
          type="email"
          value={email}
          onChange={(e) => setEmail(e.target.value)}
          placeholder="Enter your email"
          className="mt-6 rounded-lg px-4 py-3"
        />
      </section>
    );
  }

  return (
    <section className="bg-gray-900 py-16">
      <h1 className="text-4xl font-bold text-white">Feature Flag Management</h1>
    </section>
  );
}

This pattern gives you the best of both worlds: server-evaluated flags (fast, no flash) with client-side interactivity (state, event handlers).

Feature Flags in API Routes

Next.js Route Handlers are regular server-side code. Use @rollgate/sdk-node the same way you would in any Node.js backend:

// app/api/search/route.ts
import { NextResponse } from 'next/server';
import { rollgate } from '@/lib/rollgate';
import { getCurrentUser } from '@/lib/auth';

export async function GET(request: Request) {
  const user = await getCurrentUser();
  const { searchParams } = new URL(request.url);
  const query = searchParams.get('q') ?? '';

  const useNewSearchAlgorithm = await rollgate.isEnabled('search-v2', {
    userId: user?.id,
    attributes: { plan: user?.plan },
  });

  const results = useNewSearchAlgorithm
    ? await searchV2(query)
    : await searchV1(query);

  return NextResponse.json({ results });
}

This is useful for gating backend behavior: new algorithms, different rate limits per plan, or enabling experimental API responses.

// app/api/export/route.ts
import { NextResponse } from 'next/server';
import { rollgate } from '@/lib/rollgate';
import { getCurrentUser } from '@/lib/auth';

export async function POST(request: Request) {
  const user = await getCurrentUser();

  const csvExportEnabled = await rollgate.isEnabled('csv-export', {
    userId: user?.id,
    attributes: { plan: user?.plan },
  });

  if (!csvExportEnabled) {
    return NextResponse.json(
      { error: 'CSV export is not available for your account' },
      { status: 403 }
    );
  }

  const data = await request.json();
  const csv = await generateCsv(data);

  return new NextResponse(csv, {
    headers: { 'Content-Type': 'text/csv' },
  });
}

Performance Considerations

Feature flags add network requests. In a Next.js app with multiple rendering environments, this can become a bottleneck if you are not careful. Here is how to keep things fast.

Cache Flag Values

The Rollgate Node SDK caches flag evaluations by default. On the server, flag values are cached in memory and refreshed periodically, so subsequent isEnabled() calls for the same flag do not make additional API requests.

// lib/rollgate.ts
import { RollgateClient } from '@rollgate/sdk-node';

export const rollgate = new RollgateClient({
  apiKey: process.env.ROLLGATE_SERVER_KEY!,
  baseUrl: 'https://api.rollgate.io',
  cache: {
    ttl: 30_000, // Cache flag values for 30 seconds
  },
});

Avoid Waterfalls

Never evaluate flags sequentially when you can evaluate them in parallel:

// Bad: sequential — each flag waits for the previous one
const flagA = await rollgate.isEnabled('flag-a', ctx);
const flagB = await rollgate.isEnabled('flag-b', ctx);
const flagC = await rollgate.isEnabled('flag-c', ctx);

// Good: parallel — all flags evaluated at once
const [flagA, flagB, flagC] = await Promise.all([
  rollgate.isEnabled('flag-a', ctx),
  rollgate.isEnabled('flag-b', ctx),
  rollgate.isEnabled('flag-c', ctx),
]);

SSE for Real-Time Updates

The React SDK uses Server-Sent Events to receive flag changes in real time. When you toggle a flag in the Rollgate dashboard, connected clients update within seconds — without polling. This is particularly useful for kill switches, where you need to disable a feature across all active sessions immediately.

Minimize Client-Side Flag Checks

Evaluate flags on the server whenever possible. Each client-side flag check requires the browser to fetch flag values from the Rollgate API. If a flag controls static content that does not change after page load, evaluate it in a Server Component and pass the result as props.

Testing Feature Flags in Next.js

Feature flags introduce branching logic. Every flag creates two code paths, and both need testing.

Testing Server Components

Mock the Rollgate client in your tests to control flag values:

// __tests__/dashboard.test.tsx
import { render, screen } from '@testing-library/react';
import { rollgate } from '@/lib/rollgate';
import DashboardPage from '@/app/dashboard/page';

jest.mock('@/lib/rollgate', () => ({
  rollgate: {
    isEnabled: jest.fn(),
  },
}));

describe('DashboardPage', () => {
  it('renders the new dashboard when flag is enabled', async () => {
    (rollgate.isEnabled as jest.Mock).mockResolvedValue(true);

    const page = await DashboardPage();
    render(page);

    expect(screen.getByText('New Dashboard')).toBeInTheDocument();
  });

  it('renders the legacy dashboard when flag is disabled', async () => {
    (rollgate.isEnabled as jest.Mock).mockResolvedValue(false);

    const page = await DashboardPage();
    render(page);

    expect(screen.getByText('Legacy Dashboard')).toBeInTheDocument();
  });
});

Testing Client Components

The React SDK exports a MockRollgateProvider for tests:

// __tests__/feedback-widget.test.tsx
import { render, screen } from '@testing-library/react';
import { MockRollgateProvider } from '@rollgate/sdk-react/testing';
import { FeedbackWidget } from '@/components/feedback-widget';

describe('FeedbackWidget', () => {
  it('renders when flag is enabled', () => {
    render(
      <MockRollgateProvider flags={{ 'feedback-widget': true }}>
        <FeedbackWidget />
      </MockRollgateProvider>
    );

    expect(screen.getByText('💬 Feedback')).toBeInTheDocument();
  });

  it('does not render when flag is disabled', () => {
    render(
      <MockRollgateProvider flags={{ 'feedback-widget': false }}>
        <FeedbackWidget />
      </MockRollgateProvider>
    );

    expect(screen.queryByText('💬 Feedback')).not.toBeInTheDocument();
  });
});

Test Both Code Paths

A common mistake is only testing the "flag on" path. Always test both variants. Feature flags are temporary — when you remove a flag, you want confidence that the remaining code path works correctly.

FAQ

Can I use feature flags with Next.js Static Site Generation (SSG)?

Yes, but with a caveat. Statically generated pages are built at build time, so the flag value is baked into the HTML. If you change the flag after the build, the static page will not reflect the change until the next build (or ISR revalidation). For dynamic flags, use Server Components with dynamic rendering or evaluate flags on the client.

Do feature flags affect SEO?

When evaluated on the server, no. The search engine crawler sees the fully rendered HTML, just like any other page. When evaluated on the client, flags that control visible content can cause layout shift, which may impact Core Web Vitals. Prefer server-side evaluation for SEO-critical content.

How do I handle feature flags during build time?

Use environment variables to distinguish between build and runtime. For static pages, you can evaluate flags at build time using generateStaticParams or getStaticProps (Pages Router). For App Router, prefer runtime evaluation in Server Components with export const dynamic = 'force-dynamic'.

What happens if the Rollgate API is down?

The Rollgate SDKs include built-in resilience: circuit breakers, retry logic, and local caching. If the API is unreachable, the SDK serves the last known flag values from its cache. You can also configure default values that apply when no cached data is available. See the SDK documentation for configuration options.

How many feature flags should I use in one page?

There is no hard limit, but keep it practical. If you have more than five flags on a single page, consider whether some of them can be consolidated. Each flag is a maintenance cost — when you are done with a rollout, clean up the flag to reduce complexity.

Should I use server or client flags?

Use this decision tree:

Does the flag control content visible on initial page load? Server.
Does the flag control interactive behavior after load? Client.
Does the flag control routing or access? Middleware.
Does the flag control backend logic? API route.

Get Started

Implementing feature flags in Next.js does not require rethinking your architecture. The patterns above map directly to how Next.js App Router already works: async Server Components fetch data on the server, Client Components handle interactivity, middleware handles routing, and API routes handle backend logic. Feature flags slot into each of these naturally.

Rollgate gives you a single dashboard to manage flags across all these environments, with SDKs built specifically for each pattern.

Ready to add feature flags to your Next.js app?

ConfigCat Alternative: Why Developers Are Switching to Rollgate

Domenico Giordano — Sun, 26 Apr 2026 19:10:26 +0000

This was originally published on rollgate.io/blog/configcat-alternative.

ConfigCat Is Good. But It's Missing Key Features.

If you're evaluating a ConfigCat alternative, you're probably hitting one of two walls. ConfigCat has earned a solid reputation as a developer-friendly feature flag service — it's affordable, simple to set up, and gets the basics right. If all you need is boolean toggles with some targeting rules, ConfigCat works fine.

But as your team grows and your release process matures, the gaps become clear. The two biggest reasons teams switch from ConfigCat:

No scheduled releases — you can't set a flag to automatically enable at a specific date and time
No instant rollback — when something breaks, you have to manually recreate the previous flag state

These aren't edge cases. They're core workflows for any team shipping software on a regular cadence.

ConfigCat vs Rollgate: Feature-by-Feature Comparison

Feature	Rollgate	ConfigCat
Flag types	Boolean, string, number, JSON	Boolean, string, number, JSON
Targeting rules	18 operators, segments, percentage	Targeting rules, percentage
Scheduled changes	Yes (all paid plans)	No
1-click rollback	Yes (last 20 changes)	No
Real-time updates	SSE streaming	Polling only (10s-240s)
SDKs	13 official	12 official
Circuit breaker	Built into all SDKs	Not included
Retry with backoff	Built into all SDKs	Basic retry
Webhooks	7 event types, HMAC signed	Webhooks available
Audit log	3 days (Free) to 1 year (Growth)	Available on paid plans
EU hosting	Yes (Germany)	Yes (EU option)
Free tier	500K req/mo, 3 projects	10 flags, 1 project
Pricing model	Per request (flat tiers)	Per config fetches

Both tools cover the fundamentals well. The differences are in release management features and SDK resilience.

The Differentiator: Scheduled Changes + Instant Rollback

Scheduled Changes

Imagine you're launching a new pricing page on April 1st. With ConfigCat, someone has to be online to flip the flag at the right time. With Rollgate, you schedule it once and forget about it:

import { useFlag } from '@rollgate/sdk-react';

function PricingPage() {
  // This flag is scheduled to enable at 2026-04-01T00:00:00Z
  // No code change needed — the schedule is set in the dashboard
  const showNewPricing = useFlag('new-pricing-page', false);

  return showNewPricing ? <NewPricing /> : <CurrentPricing />;
}

From the Rollgate dashboard, you set enable_at: 2026-04-01T00:00:00Z on the flag. At midnight UTC on April 1st, the flag turns on automatically. Your SDK picks up the change via SSE in real-time, or on the next polling cycle (default: 30 seconds).

You can also schedule a disable time — perfect for time-limited promotions, maintenance windows, or beta periods that should expire automatically.

1-Click Rollback

ConfigCat tracks flag changes, but rolling back means manually editing the flag to match a previous state. Rollgate keeps the last 20 states of every flag. One click in the dashboard (or one API call) restores the exact previous configuration — targeting rules, percentage, value, everything.

# Rollback to previous state via API
curl -X POST https://api.rollgate.io/api/v1/projects/:id/flags/:flagId/rollback \
  -H "Authorization: Bearer $ROLLGATE_SERVER_KEY"

When your 3am release breaks the checkout flow, the on-call engineer doesn't need to understand the flag's targeting logic. They click "Rollback," and the flag reverts to its last known-good state. Downtime goes from minutes to seconds.

Practical Example: The Scheduled Release Workflow

Here's how a typical release looks with Rollgate:

Monday: Developer merges the new checkout flow behind a feature flag. Code deploys to production, but the flag is off.

import { RollgateClient } from '@rollgate/sdk-node';

const client = new RollgateClient({
  apiKey: process.env.ROLLGATE_SERVER_KEY,
  enableSSE: true,
});

await client.initialize();

// Flag is OFF — all users see old checkout
const useNewCheckout = client.isEnabled('new-checkout-v2', {
  id: user.id,
  attributes: { plan: user.plan }
});

Tuesday: QA tests internally by enabling the flag for the QA segment only (a list-based segment of QA team user IDs).

Wednesday: PM schedules the flag to enable for 10% of users on Thursday at 10am, and 100% on Friday at 10am.

Thursday 10am: Flag automatically enables for 10%. The team monitors error rates and conversion metrics.

Thursday 3pm: Error rate spikes. Engineer clicks "Rollback" — flag reverts to QA-only in under 2 seconds.

Friday: Bug fixed, schedule reset. Flag enables for 10% at 10am, 50% at 2pm, 100% Monday morning.

No deploys. No cron jobs. No one staying awake overnight.

ConfigCat Free Tier: What Are the Limits?

ConfigCat's free tier is widely used by indie developers and side projects because it genuinely works. But it's designed to push you toward paid plans sooner than Rollgate's free tier. Here's what you actually get:

Free tier limit	ConfigCat	Rollgate
Flags	10	Unlimited
Products/Projects	1	3
Environments	2	3
Team members	5	3
Config fetches / requests	~1M/mo	500K/mo
Audit log retention	Limited	3 days
Real-time updates (SSE)	No (polling only)	Yes
Scheduled changes	No	No (paid plan)
1-click rollback	No	No (paid plan)

The ConfigCat free tier wins on config fetches and team members. Rollgate wins on flags (unlimited vs 10), projects (3 vs 1), and real-time SSE updates. For a typical small team, the 10-flag limit is the first wall you hit with ConfigCat — and it happens fast.

Pricing: ConfigCat vs Rollgate

ConfigCat's paid plans have changed over time; check their current rates at configcat.com/pricing. Based on publicly available information, here's how the two compare:

Plan tier	ConfigCat (est.)	Rollgate
Free	10 flags, 1 product	500K req/mo, 3 projects, unlimited flags
Pro	~$99-120/mo	€39-45/mo (Starter) — 1M requests
Smart / Pro+	~$389-410/mo	€99-119/mo (Pro) — 3M requests
Enterprise	Custom	€299-349/mo (Growth) — 12M requests
Pricing unit	Config fetches	SDK requests

Disclaimer: Competitor pricing changes frequently. Always check the vendor's website for current rates.

At every tier, Rollgate is roughly 2-4x cheaper than ConfigCat's equivalent plan, and includes features (scheduled changes, 1-click rollback, real-time SSE) that ConfigCat doesn't offer at any tier.

Migration from ConfigCat to Rollgate

Switching from ConfigCat takes most teams 1-2 days for a small codebase. The SDK APIs are similar enough that the change is mostly find-and-replace. Here's the step-by-step:

Step 1: Export your ConfigCat flags

Audit your current ConfigCat flags in the dashboard. Note for each flag:

Flag key and type (boolean/string/number)
Current value
Targeting rules (user attributes, percentage rollouts)
Which environments use it

ConfigCat's dashboard lets you export flags via their Management API or CSV. Most teams find 20-40% of their flags are stale and can be deleted during migration.

Step 2: Recreate flags in Rollgate

Create a new Rollgate project and add each active flag through the dashboard or API. Rollgate supports the same flag types as ConfigCat — boolean, string, number, and JSON — plus targeting rules that map directly from ConfigCat's comparators.

Step 3: Swap the SDK

Replace ConfigCat SDK imports with the Rollgate equivalent:

ConfigCat SDK	Rollgate SDK	Registry
`configcat-js`	`@rollgate/sdk-browser`	npm (Browser)
`configcat-react`	`@rollgate/sdk-react`	npm (React)
`configcat-vue`	`@rollgate/sdk-vue`	npm (Vue)
`configcat-node`	`@rollgate/sdk-node`	npm (Node.js)
`configcat-go`	`github.com/rollgate/sdks/packages/sdk-go`	Go modules
`configcat-java-client`	`io.rollgate:rollgate-sdk`	Maven Central
`configcat-python`	`rollgate`	PyPI
`ConfigCat.Client`	`Rollgate.SDK`	NuGet (.NET)

Step 4: Update flag evaluation calls

The API surface is intentionally similar. Typical before/after:

ConfigCat (React):

import { useFeatureFlag } from 'configcat-react';

function MyComponent() {
  const { value: newCheckout } = useFeatureFlag('new-checkout', false);
  return newCheckout ? <NewCheckout /> : <OldCheckout />;
}

Rollgate (React):

import { useFlag } from '@rollgate/sdk-react';

function MyComponent() {
  const newCheckout = useFlag('new-checkout', false);
  return newCheckout ? <NewCheckout /> : <OldCheckout />;
}

The main difference: Rollgate returns the value directly, while ConfigCat wraps it in an object.

Step 5: Validate with parallel running (optional)

For critical flags, run both SDKs in parallel for a few days. Log any discrepancies between ConfigCat and Rollgate evaluations. Once you're confident the values match, remove the ConfigCat SDK and cancel the ConfigCat subscription.

Step 6: Clean up

Remove ConfigCat packages, delete environment variables, update CI/CD pipelines. Make sure to cancel your ConfigCat subscription before the next billing cycle.

When to Switch from ConfigCat to Rollgate

Switch if:

You need scheduled flag changes (release planning, maintenance windows, timed launches)
You want instant rollback without manually recreating flag states
You need real-time updates via SSE instead of polling
Your free tier needs exceed 10 flags
You want SDKs with built-in circuit breakers and graceful degradation
You want per-request pricing instead of per-config-fetch

Stay with ConfigCat if:

You only use simple boolean toggles with no scheduling needs
Polling-based updates (not real-time) are acceptable
You have fewer than 10 flags and want to stay on the free tier
You're already happy with your current plan

FAQ

Is there a free alternative to ConfigCat?

Yes. The most generous free tiers among feature flag tools are:

Rollgate: 500K requests/month, unlimited flags, 3 projects, 3 environments, all 13 SDKs, no credit card required
Flagsmith cloud: 50K requests/month on the free plan
Unleash self-hosted: Free (requires your own infrastructure)
GrowthBook self-hosted: Free (requires your own infrastructure)

For teams that want a managed service without hitting the flag count wall (ConfigCat's 10-flag limit), Rollgate's free tier is the most generous cloud-hosted option.

Does ConfigCat support scheduled releases?

No. ConfigCat does not offer scheduled flag changes at any tier. You cannot program a flag to automatically enable or disable at a specific date and time — someone has to manually toggle it. This is one of the most common reasons teams outgrow ConfigCat and look for alternatives.

Rollgate includes scheduled changes on all paid plans (Starter, Pro, Growth).

Does ConfigCat have real-time updates?

No. ConfigCat uses polling-based updates with configurable intervals (10 seconds to 240 seconds depending on plan). Changes made in the dashboard reach your application after the next polling cycle, which introduces delay.

Rollgate supports real-time updates via Server-Sent Events (SSE). Flag changes propagate to connected clients within seconds, without waiting for the next poll.

Can I use ConfigCat for A/B testing?

ConfigCat supports percentage-based rollouts and multivariate flags, which enable basic A/B testing. However, it doesn't include statistical analysis, conversion tracking, or experiment results dashboards. You'll need to pair it with a separate analytics tool (Mixpanel, Amplitude, GA4) to measure experiment outcomes.

Rollgate provides similar A/B testing functionality (variant flags with percentage distribution) and includes basic evaluation tracking. For teams that need advanced statistical analysis, both tools benefit from integration with a dedicated analytics platform.

What is the difference between ConfigCat and Rollgate?

The core differences:

Aspect	ConfigCat	Rollgate
Scheduled releases	No	Yes (all paid)
1-click rollback	No	Yes
Real-time updates	Polling only	SSE streaming
Free tier flags	10 max	Unlimited
Free tier projects	1	3
SDK resilience	Basic	Circuit breaker + retry + local cache
Pricing unit	Config fetches	SDK requests (flat tiers)

Both tools cover the fundamentals (targeting, percentage rollouts, multi-environment, audit log). Rollgate differentiates on release management features and SDK resilience.

How do I migrate from ConfigCat without downtime?

The safest approach is parallel running: keep ConfigCat active while adding the Rollgate SDK to your application. Evaluate flags from both services and log any discrepancies. Once you've verified the values match, remove the ConfigCat SDK.

For non-critical flags, you can migrate directly — the SDK APIs are similar enough (boolean/string/number flags, targeting rules, percentage rollouts) that the code change is mostly find-and-replace plus adjusting the return value shape.

Is ConfigCat GDPR compliant?

Yes. ConfigCat offers EU data residency and is GDPR compliant. Rollgate is also GDPR compliant and hosted in Germany (Hetzner), which simplifies data processing agreements for European teams.

If EU data residency is a hard requirement, both tools work — but Rollgate's single-region EU hosting means there's no ambiguity about where your flag evaluations are processed.

What are ConfigCat's limitations?

The most common limitations developers hit with ConfigCat:

No scheduled flag changes — You can't program a flag to enable/disable at a future date
No 1-click rollback — Reverting a flag requires manually recreating the previous state
Polling only — No real-time flag updates via SSE; clients receive changes with 10s-240s delay depending on plan
10-flag free tier limit — Most small teams outgrow this in the first week
Per-config-fetch pricing — Can be surprising if you have many clients or short polling intervals
No built-in circuit breaker — SDKs don't have the same resilience features (circuit breaker, retry with backoff) as Rollgate

None of these are dealbreakers for teams with simple needs. But for any team doing real release management (scheduled launches, staged rollouts, rapid rollbacks), they add up.

Try Rollgate Free

Rollgate's free tier includes everything you need to evaluate: 500K requests per month, all 13 SDKs, unlimited flags, and 3 projects.

Sign up at rollgate.io — no credit card required. Or try the live demo to see the dashboard, scheduled changes, and rollback in action.

For a broader comparison of feature flag tools, see our feature flags pricing comparison, LaunchDarkly alternative guide, and our honest product audit. If you're new to feature flags, start with What Are Feature Flags? or check our gradual rollouts guide.

How to Add Feature Flags to React in 5 Minutes

Domenico Giordano — Fri, 24 Apr 2026 21:27:30 +0000

This was originally published on rollgate.io/blog/feature-flags-react.

Why Feature Flags in React?

Every React application reaches a point where you need to control what users see — without redeploying. Maybe you want to test a new checkout flow with 10% of users. Maybe you need a kill switch for a feature that's causing performance issues. Maybe your PM wants to launch a feature on Tuesday at 9am, not whenever the deploy pipeline finishes.

Feature flags in React solve all of these problems. They let you wrap components, routes, or entire features behind a toggle that you control from a dashboard — no code changes, no redeployment, no downtime.

If you've ever used an environment variable like NEXT_PUBLIC_ENABLE_NEW_UI and redeployed just to flip it, you already understand the concept. Feature flags are the same idea, but dynamic: you change the value in a dashboard, and every connected client picks it up in real time.

In this guide, we'll go from zero to production-ready React feature flags in 5 minutes. We'll start with the simplest possible approach (environment variables), show its limitations, and then implement a proper solution with Rollgate that supports gradual rollouts, A/B testing, and user targeting.

The Simplest Approach: Environment Variables

Before reaching for a library, many teams start with environment variables:

// feature-flags.ts
export const flags = {
  newPricing: process.env.NEXT_PUBLIC_NEW_PRICING === 'true',
  darkMode: process.env.NEXT_PUBLIC_DARK_MODE === 'true',
};

// PricingPage.tsx
import { flags } from './feature-flags';

export function PricingPage() {
  if (flags.newPricing) {
    return <NewPricingTable />;
  }
  return <LegacyPricingTable />;
}

This works for simple cases, but it has serious limitations:

Requires a redeploy to change any flag value
No gradual rollouts — it's all-or-nothing for every user
No user targeting — you can't enable a feature for beta testers only
No instant kill switch — if a feature breaks, you need to redeploy to disable it
No audit trail — who changed what, when?

For anything beyond the simplest use case, you need a feature flag library. Let's set one up.

Quick Start: React Feature Flags in 5 Minutes

We'll use @rollgate/sdk-react, which gives you a React-native API with hooks and providers. The entire setup takes three steps.

Step 1: Install the SDK

npm install @rollgate/sdk-react

Step 2: Wrap Your App with RollgateProvider

// app.tsx (or _app.tsx, layout.tsx — wherever your root component lives)
import { RollgateProvider } from '@rollgate/sdk-react';

export default function App({ children }: { children: React.ReactNode }) {
  return (
    <RollgateProvider
      apiKey="YOUR_API_KEY"
      user={{ id: currentUser.id, email: currentUser.email, plan: currentUser.plan }}
    >
      {children}
    </RollgateProvider>
  );
}

The RollgateProvider connects to Rollgate's edge API, fetches your flag configuration, and makes it available to every component in the tree via React context. It also opens an SSE connection for real-time updates — when you toggle a flag in the dashboard, every connected client picks it up within seconds.

The user object is optional but recommended. It enables targeting rules (e.g., "enable this flag for users on the Pro plan") and consistent rollout assignments (the same user always sees the same variant).

Step 3: Use the useFlag Hook

import { useFlag } from '@rollgate/sdk-react';

export function CheckoutPage() {
  const showNewCheckout = useFlag('new-checkout', false);

  if (showNewCheckout) {
    return <NewCheckout />;
  }
  return <LegacyCheckout />;
}

That's it. Three steps, five minutes, and you have feature flags in React. The useFlag hook returns the flag's current value and re-renders the component when it changes.

Now let's go deeper.

The useFlag Hook

The useFlag hook is the primary way to read feature flag values in React components. It accepts two arguments: the flag key and a default value.

const value = useFlag('flag-key', defaultValue);

Boolean Flags

The most common type. Returns true or false:

const isEnabled = useFlag('dark-mode', false);

String Flags

Useful for A/B testing and multivariate experiments:

const variant = useFlag('checkout-layout', 'control');
// variant: 'control' | 'single-page' | 'multi-step'

Number Flags

For numeric configuration like rate limits or thresholds:

const maxItems = useFlag('cart-max-items', 10);

JSON Flags

For complex configuration objects:

const config = useFlag('pricing-config', { currency: 'USD', showAnnual: true });

Default Values Matter

The default value serves two purposes:

Fallback — if the flag doesn't exist or the SDK can't reach the server, your app uses this value instead of crashing
Type inference — TypeScript infers the return type from the default value, so useFlag('dark-mode', false) returns boolean and useFlag('variant', 'control') returns string

Always choose a safe default. If your flag controls a new, untested feature, default to false. If it controls a critical flow, default to the value that keeps the existing behavior.

The useFlags Hook

If you need multiple flags at once, useFlags returns all flags as an object:

import { useFlags } from '@rollgate/sdk-react';

export function Dashboard() {
  const flags = useFlags();

  return (
    <div>
      {flags['new-sidebar'] && <NewSidebar />}
      {flags['analytics-v2'] && <AnalyticsV2 />}
    </div>
  );
}

Conditional Rendering with Feature Flags

React feature flags shine in conditional rendering. Here are the most common patterns.

Component-Level Gating

The simplest pattern — show or hide an entire component:

function SettingsPage() {
  const showBetaFeatures = useFlag('beta-features', false);

  return (
    <div>
      <GeneralSettings />
      <SecuritySettings />
      {showBetaFeatures && <BetaFeatures />}
    </div>
  );
}

Route-Level Gating

Control access to entire pages based on a flag:

import { useFlag } from '@rollgate/sdk-react';
import { Navigate } from 'react-router-dom';

function AnalyticsPage() {
  const analyticsEnabled = useFlag('analytics-page', false);

  if (!analyticsEnabled) {
    return <Navigate to="/dashboard" replace />;
  }

  return <AnalyticsDashboard />;
}

Prop-Level Gating

Pass flag values as props to control component behavior without the child knowing about feature flags:

function ProductPage() {
  const showReviews = useFlag('product-reviews', false);
  const maxImages = useFlag('product-gallery-max', 4);

  return (
    <ProductDetail
      showReviews={showReviews}
      maxGalleryImages={maxImages}
    />
  );
}

Wrapper Component Pattern

For reusable gating, create a wrapper:

import { useFlag } from '@rollgate/sdk-react';

function FeatureGate({
  flag,
  fallback = null,
  children,
}: {
  flag: string;
  fallback?: React.ReactNode;
  children: React.ReactNode;
}) {
  const isEnabled = useFlag(flag, false);
  return isEnabled ? <>{children}</> : <>{fallback}</>;
}

// Usage
<FeatureGate flag="new-header" fallback={<OldHeader />}>
  <NewHeader />
</FeatureGate>

Gradual Rollouts in React

Gradual rollouts let you release a feature to a percentage of users instead of everyone at once. This is one of the most powerful feature flag patterns and the primary reason teams adopt feature flags.

How It Works

When you create a flag in Rollgate with a percentage rollout (e.g., 20%), the SDK uses consistent hashing to determine whether a specific user should see the feature. The hash is based on the user ID and the flag key, which means:

The same user always gets the same result for a given flag (no flickering between sessions)
Different flags hash independently (being in the 20% for flag A doesn't mean you're in the 20% for flag B)
The distribution is uniform — 20% means roughly 20% of users, not exactly 20% of requests

Setting Up a Gradual Rollout

In the Rollgate dashboard, set your flag's rollout to a percentage. In your React code, nothing changes:

function CheckoutPage() {
  // This might return true for 20% of users and false for the rest
  const useNewCheckout = useFlag('new-checkout', false);

  return useNewCheckout ? <NewCheckout /> : <LegacyCheckout />;
}

The SDK handles everything. When you increase the rollout from 20% to 50%, users who were already seeing the feature continue to see it (no disruption), and new users are added to the cohort.

Why User IDs Matter

For consistent hashing to work, the SDK needs a stable user identifier. This is why passing a user object to RollgateProvider is important for rollouts:

<RollgateProvider
  apiKey="YOUR_API_KEY"
  user={{ id: user.id }}
>
  {children}
</RollgateProvider>

Without a user ID, the SDK generates a random identifier per session, which means the same person might see the feature in one session and not in another.

A/B Testing with React Feature Flags

A/B testing with feature flags takes gradual rollouts a step further. Instead of just on/off, you assign users to named variants and measure which performs better.

Setting Up an A/B Test

Create a flag in Rollgate with string variants:

control — 50% of users (the existing experience)
variant-a — 25% of users
variant-b — 25% of users

Then use it in React:

function PricingPage() {
  const variant = useFlag('pricing-experiment', 'control');

  switch (variant) {
    case 'variant-a':
      return <PricingAnnualFirst />;
    case 'variant-b':
      return <PricingCompact />;
    default:
      return <PricingDefault />;
  }
}

Tracking Conversions

To measure the impact of your experiment, track events when users convert:

import { useFlag, useRollgate } from '@rollgate/sdk-react';

function PricingPage() {
  const variant = useFlag('pricing-experiment', 'control');
  const { track } = useRollgate();

  function handleSubscribe(userId: string) {
    track({
      flagKey: 'pricing-experiment',
      eventName: 'subscription-started',
      userId,
      variationId: variant,
    });
  }

  return (
    <PricingTable
      variant={variant}
      onSubscribe={handleSubscribe}
    />
  );
}

The Rollgate dashboard shows conversion rates per variant, so you can see which pricing layout drives more subscriptions.

Feature Flags with Next.js

Next.js adds complexity with Server Components, server-side rendering, and middleware. Here's how to handle each.

Client Components

For client components, the setup is identical to standard React. Wrap your layout with RollgateProvider and use hooks:

// app/layout.tsx
import { RollgateProvider } from '@rollgate/sdk-react';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html>
      <body>
        <RollgateProvider apiKey={process.env.NEXT_PUBLIC_ROLLGATE_KEY!}>
          {children}
        </RollgateProvider>
      </body>
    </html>
  );
}

Server Components

For Next.js Server Components, use the Node.js SDK instead of the React SDK. The Node SDK evaluates flags server-side, which means no client-side flash of content:

// app/dashboard/page.tsx (Server Component)
import { createClient } from '@rollgate/sdk-node';

const rollgate = createClient({ serverKey: process.env.ROLLGATE_SERVER_KEY! });

export default async function DashboardPage() {
  const showNewDashboard = await rollgate.isEnabled('new-dashboard', {
    user: { id: getCurrentUserId() },
  });

  return showNewDashboard ? <NewDashboard /> : <LegacyDashboard />;
}

Middleware Pattern

For route-level gating in Next.js middleware:

// middleware.ts
import { createClient } from '@rollgate/sdk-node';

const rollgate = createClient({ serverKey: process.env.ROLLGATE_SERVER_KEY! });

export async function middleware(request: NextRequest) {
  const userId = getUserIdFromCookie(request);
  const betaEnabled = await rollgate.isEnabled('beta-access', {
    user: { id: userId },
  });

  if (request.nextUrl.pathname.startsWith('/beta') && !betaEnabled) {
    return NextResponse.redirect(new URL('/dashboard', request.url));
  }
}

This pattern lets you gate entire routes before they render, which is cleaner than checking flags inside every page component.

Feature Flags with React Native

If you're building a mobile app with React Native, Rollgate provides @rollgate/sdk-react-native:

npm install @rollgate/sdk-react-native

import { RollgateProvider, useFlag } from '@rollgate/sdk-react-native';

function App() {
  return (
    <RollgateProvider
      apiKey="YOUR_API_KEY"
      user={{ id: user.id, platform: 'ios' }}
    >
      <MainNavigator />
    </RollgateProvider>
  );
}

function HomeScreen() {
  const showNewOnboarding = useFlag('mobile-onboarding-v2', false);
  // ...
}

The API is nearly identical to @rollgate/sdk-react. The React Native SDK handles mobile-specific concerns like background/foreground state, offline caching, and network reconnection. See the React Native SDK docs for details.

Best Practices for React Feature Flags

1. Keep Flag Checks Out of Hot Render Paths

Feature flag evaluation is fast, but in components that render hundreds of times per second (e.g., list items, animation frames), avoid calling useFlag inside the loop:

// Bad — evaluates the flag on every list item render
function ProductList({ products }: { products: Product[] }) {
  return products.map((p) => {
    const showBadge = useFlag('new-badge', false); // Called N times
    return <ProductCard key={p.id} showBadge={showBadge} product={p} />;
  });
}

// Good — evaluate once, pass as prop
function ProductList({ products }: { products: Product[] }) {
  const showBadge = useFlag('new-badge', false); // Called once
  return products.map((p) => (
    <ProductCard key={p.id} showBadge={showBadge} product={p} />
  ));
}

2. Memoize Components Behind Flags

When a flag controls which component renders, use React.memo or useMemo to prevent unnecessary re-renders when the flag value hasn't changed:

function Dashboard() {
  const variant = useFlag('dashboard-layout', 'default');

  const content = useMemo(() => {
    switch (variant) {
      case 'compact': return <CompactDashboard />;
      case 'wide': return <WideDashboard />;
      default: return <DefaultDashboard />;
    }
  }, [variant]);

  return <Layout>{content}</Layout>;
}

3. Test Both Flag Paths

Every feature flag creates two code paths. Test both:

// __tests__/CheckoutPage.test.tsx
import { render, screen } from '@testing-library/react';
import { useFlag } from '@rollgate/sdk-react';
import { CheckoutPage } from './CheckoutPage';

jest.mock('@rollgate/sdk-react', () => ({
  ...jest.requireActual('@rollgate/sdk-react'),
  useFlag: jest.fn(),
}));

describe('CheckoutPage', () => {
  it('renders new checkout when flag is on', () => {
    (useFlag as jest.Mock).mockReturnValue(true);
    render(<CheckoutPage />);
    expect(screen.getByText('New Checkout')).toBeInTheDocument();
  });

  it('renders legacy checkout when flag is off', () => {
    (useFlag as jest.Mock).mockReturnValue(false);
    render(<CheckoutPage />);
    expect(screen.getByText('Legacy Checkout')).toBeInTheDocument();
  });
});

Mocking useFlag directly lets you control flag values in tests without hitting the network.

4. Clean Up Stale Flags

Feature flags are temporary. Once a feature is fully rolled out, remove the flag and the conditional logic. Stale flags create confusion, increase code complexity, and make your flag dashboard cluttered. Set a review date when you create each flag.

5. Name Flags Descriptively

Use kebab-case and be specific about what the flag controls:

Good: checkout-single-page, pricing-annual-toggle, onboarding-v2
Bad: flag1, test, new-feature, temp

Common Patterns

Feature-Gated Routes

Combine React Router with feature flags to gate entire sections of your app:

import { useFlag } from '@rollgate/sdk-react';

function AppRoutes() {
  const analyticsEnabled = useFlag('analytics-module', false);
  const reportsEnabled = useFlag('reports-module', false);

  return (
    <Routes>
      <Route path="/dashboard" element={<Dashboard />} />
      {analyticsEnabled && (
        <Route path="/analytics/*" element={<AnalyticsModule />} />
      )}
      {reportsEnabled && (
        <Route path="/reports/*" element={<ReportsModule />} />
      )}
      <Route path="*" element={<NotFound />} />
    </Routes>
  );
}

Permission-Based Rendering

Combine feature flags with user permissions for fine-grained access control:

function AdminPanel() {
  const advancedAdmin = useFlag('advanced-admin-tools', false);
  const { user } = useAuth();

  return (
    <div>
      <UserManagement />
      {user.role === 'admin' && advancedAdmin && <AdvancedTools />}
      {user.role === 'superadmin' && <SystemConfig />}
    </div>
  );
}

Beta Programs

Let users opt into beta features, then use feature flags to control the experience:

function BetaOptIn() {
  const betaAvailable = useFlag('beta-program-open', false);
  const { user, updateUser } = useAuth();

  if (!betaAvailable) return null;

  return (
    <Card>
      <CardHeader>
        <CardTitle>Beta Program</CardTitle>
      </CardHeader>
      <CardContent>
        <p>Get early access to new features.</p>
        <Switch
          checked={user.betaOptIn}
          onCheckedChange={(checked) => updateUser({ betaOptIn: checked })}
        />
      </CardContent>
    </Card>
  );
}

When a user opts in, their betaOptIn attribute is sent to Rollgate via the user context, and targeting rules can enable beta features specifically for them.

Loading States

Handle the initial SDK load gracefully:

import { useRollgate } from '@rollgate/sdk-react';

function App() {
  const { isReady } = useRollgate();

  if (!isReady) {
    return <Skeleton className="h-screen w-full" />;
  }

  return <MainApp />;
}

The isReady flag becomes true once the SDK has fetched the initial flag configuration. This prevents a flash of default values before the real values arrive.

FAQ

How do React feature flags affect bundle size?

The @rollgate/sdk-react package is lightweight — under 5 KB gzipped. It uses the browser SDK under the hood and adds only the React-specific bindings (provider, hooks). There is no impact on your build time, and tree-shaking removes any unused exports.

Do feature flags cause a flash of content?

By default, the SDK renders with default values until the flag configuration is fetched. This can cause a brief flash. To prevent it, use the isReady check from useRollgate() to show a loading state, or use server-side evaluation with the Node SDK in Next.js Server Components.

Can I use feature flags with React Server Components?

Yes. Use @rollgate/sdk-node for Server Components and @rollgate/sdk-react for Client Components. See the Next.js section above.

How do feature flags work with SSR?

For server-side rendering, evaluate flags on the server with @rollgate/sdk-node and pass the results as props to your client components. This ensures the initial HTML matches the flag state and prevents hydration mismatches.

What happens if the Rollgate API is unavailable?

The SDK uses local caching and a circuit breaker pattern. If the API is unreachable, it falls back to the last known flag values (cached in memory and optionally in localStorage). Your app continues to work with the most recent flag configuration. The default value you pass to useFlag is used only on the very first load if no cached values exist.

Are feature flag evaluations counted per render?

No. Flag evaluation happens when the SDK fetches the configuration, not on each useFlag call. The hook simply reads from an in-memory cache, so calling it is essentially free — comparable to reading from React context.

What's Next?

You now have everything you need to implement feature flags in React. To recap:

Install @rollgate/sdk-react
Wrap your app with RollgateProvider
Use useFlag to read flag values
Use the dashboard to control rollouts, run A/B tests, and target users

If you're new to feature flags, start with the fundamentals: What Are Feature Flags? covers the core concepts, Gradual Rollouts Guide explains percentage-based releases in depth, and A/B Testing with Feature Flags walks through experimentation patterns.

For the full React SDK API reference, see the React SDK documentation.

Ready to get started? Create a free Rollgate account — it takes 30 seconds, no credit card required.

Feature Flags in Go: A Practical Guide with Examples

Domenico Giordano — Thu, 23 Apr 2026 22:57:45 +0000

This was originally published on rollgate.io/blog/feature-flags-golang.

Why Feature Flags in Go?

Go is the language of choice for microservices, API backends, CLI tools, and infrastructure software. Teams shipping Go code in production face the same challenge: how do you release features safely without redeploying your entire service?

Feature flags in Go solve this by decoupling deployment from release. You deploy code to production behind a flag, then control who sees it — without touching your CI/CD pipeline or restarting your binary.

Here is why feature flags are particularly useful in Go applications:

Microservices: Roll out a new endpoint or algorithm to 5% of traffic, monitor error rates, then gradually increase. If something breaks, disable the flag instantly — no redeployment across your fleet.
API backends: Ship a v2 of your API handler behind a flag. Route beta users to v2 while everyone else stays on v1. Migrate at your own pace.
CLI tools: Enable experimental commands for internal testers before exposing them to all users.
Infrastructure: Toggle between database backends, caching strategies, or queue implementations without code changes.

If you are not familiar with the concept yet, check out our complete guide to feature flags for the fundamentals.

Quick Start: Feature Flags in Go

Let's get a feature flag running in Go in under two minutes. Install the Rollgate Go SDK:

go get github.com/rollgate/sdk-go

Then use it in your application:

package main

import (
    "context"
    "fmt"
    "log"

    rollgate "github.com/rollgate/sdk-go"
)

func main() {
    client, err := rollgate.NewClient(rollgate.Config{
        APIKey: "your-api-key",
    })
    if err != nil {
        log.Fatal(err)
    }
    defer client.Close()

    if err := client.Init(context.Background()); err != nil {
        log.Fatal(err)
    }

    if client.IsEnabled("new-pricing-page", false) {
        fmt.Println("Showing new pricing page")
    } else {
        fmt.Println("Showing old pricing page")
    }
}

That is the entire setup. The SDK fetches flags from Rollgate's API, caches them locally, and keeps them updated via background polling. The second argument to IsEnabled is the default value — what to return if the flag does not exist or the client is not ready.

The DIY Approach

Before reaching for a feature flag service, you might try building your own. Here is the simplest version using a config file:

package featureflags

import (
    "encoding/json"
    "os"
    "sync"
)

type Flags struct {
    mu    sync.RWMutex
    flags map[string]bool
}

func New(path string) (*Flags, error) {
    data, err := os.ReadFile(path)
    if err != nil {
        return nil, err
    }

    var flags map[string]bool
    if err := json.Unmarshal(data, &flags); err != nil {
        return nil, err
    }

    return &Flags{flags: flags}, nil
}

func (f *Flags) IsEnabled(key string) bool {
    f.mu.RLock()
    defer f.mu.RUnlock()
    return f.flags[key]
}

With a flags.json file:

{
  "new-search": true,
  "dark-mode": false,
  "v2-api": true
}

This works for prototypes. But it hits a wall quickly:

No real-time updates: Changing a flag requires editing the file and restarting the process. In a fleet of 20 microservices, that means 20 restarts.
No targeting: You cannot enable a flag for specific users, segments, or percentages. It is all-or-nothing.
No audit trail: Who changed what, when? Config files do not track that.
No gradual rollouts: You cannot roll out to 5% of users, then 25%, then 100%.
No kill switch: When production is on fire, you want to disable a feature in seconds, not minutes.

For anything beyond a side project, you need a proper feature flag system. Let's look at how the Rollgate Go SDK handles all of these cases.

Using the Rollgate Go SDK

The Rollgate Go SDK is designed for Go idioms: context.Context for cancellation, interfaces for testability, functional options for flexibility, and proper error handling.

Full Setup

package main

import (
    "context"
    "log"
    "os"
    "time"

    rollgate "github.com/rollgate/sdk-go"
)

func main() {
    client, err := rollgate.NewClient(rollgate.Config{
        APIKey:          os.Getenv("ROLLGATE_API_KEY"),
        BaseURL:         "https://api.rollgate.io",
        Timeout:         5 * time.Second,
        RefreshInterval: 30 * time.Second,
        EnableStreaming:  true, // Real-time updates via SSE
        Cache: rollgate.CacheConfig{
            TTL:      5 * time.Minute,
            StaleTTL: 1 * time.Hour,
            Enabled:  true,
        },
    })
    if err != nil {
        log.Fatal(err)
    }
    defer client.Close()

    ctx := context.Background()
    if err := client.Init(ctx); err != nil {
        log.Fatal(err)
    }

    // Identify a user for targeted evaluations
    err = client.Identify(ctx, &rollgate.UserContext{
        ID:    "user-123",
        Email: "alice@example.com",
        Attributes: map[string]any{
            "plan":    "pro",
            "country": "DE",
        },
    })
    if err != nil {
        log.Printf("identify failed: %v", err)
    }

    // Check a flag
    if client.IsEnabled("new-dashboard", false) {
        showNewDashboard()
    }
}

Per-Evaluation User Context

Sometimes you need to evaluate a flag for a different user without changing the client-level identity. The SDK supports functional options for this:

// Evaluate for a specific user without changing client state
enabled := client.IsEnabled("beta-feature", false,
    rollgate.WithUser("user-456"),
    rollgate.WithAttributes(map[string]any{
        "plan": "enterprise",
    }),
)

Evaluation Details

When you need to know why a flag returned a specific value (for debugging or logging), use IsEnabledDetail:

detail := client.IsEnabledDetail("checkout-v2", false)
log.Printf("flag=%s value=%v reason=%s",
    "checkout-v2", detail.Value, detail.Reason.Kind)

This returns the evaluation reason: whether the flag matched a targeting rule, a percentage rollout, or fell through to the default value.

Feature Flags in HTTP Handlers

Go's HTTP ecosystem (Chi, Gin, standard net/http) makes it easy to integrate feature flags at the handler level. Since Rollgate's own API is built with Chi, here are examples for all three.

Chi Router (Recommended)

package main

import (
    "net/http"

    "github.com/go-chi/chi/v5"
    rollgate "github.com/rollgate/sdk-go"
)

func main() {
    r := chi.NewRouter()

    // Route based on feature flag
    r.Get("/api/search", func(w http.ResponseWriter, r *http.Request) {
        userID := r.Context().Value("userID").(string)

        if flagClient.IsEnabled("search-v2", false,
            rollgate.WithUser(userID),
        ) {
            searchV2Handler(w, r)
        } else {
            searchV1Handler(w, r)
        }
    })

    http.ListenAndServe(":8080", r)
}

Standard net/http

func featureFlagHandler(w http.ResponseWriter, r *http.Request) {
    userID := getUserID(r)

    if flagClient.IsEnabled("new-endpoint", false,
        rollgate.WithUser(userID),
    ) {
        w.WriteHeader(http.StatusOK)
        json.NewEncoder(w).Encode(newResponse())
    } else {
        w.WriteHeader(http.StatusOK)
        json.NewEncoder(w).Encode(legacyResponse())
    }
}

Feature Flags in gRPC Services

For gRPC services, feature flags work naturally as unary interceptors:

package main

import (
    "context"

    rollgate "github.com/rollgate/sdk-go"
    "google.golang.org/grpc"
    "google.golang.org/grpc/metadata"
)

func featureFlagInterceptor(flagClient *rollgate.Client) grpc.UnaryServerInterceptor {
    return func(
        ctx context.Context,
        req interface{},
        info *grpc.UnaryServerInfo,
        handler grpc.UnaryHandler,
    ) (interface{}, error) {
        // Extract user ID from gRPC metadata
        var userID string
        if md, ok := metadata.FromIncomingContext(ctx); ok {
            if values := md.Get("x-user-id"); len(values) > 0 {
                userID = values[0]
            }
        }

        // Inject flag values into context
        flags := map[string]bool{
            "search-v2":    flagClient.IsEnabled("search-v2", false, rollgate.WithUser(userID)),
            "new-ranking":  flagClient.IsEnabled("new-ranking", false, rollgate.WithUser(userID)),
        }
        ctx = context.WithValue(ctx, flagsContextKey, flags)

        return handler(ctx, req)
    }
}

// In your gRPC service implementation
func (s *SearchService) Search(ctx context.Context, req *pb.SearchRequest) (*pb.SearchResponse, error) {
    flags := ctx.Value(flagsContextKey).(map[string]bool)

    if flags["search-v2"] {
        return s.searchV2(ctx, req)
    }
    return s.searchV1(ctx, req)
}

Gradual Rollouts in Go

Gradual rollouts let you release a feature to a percentage of users, increasing over time. This is the safest way to ship changes in production. For a deep dive on rollout strategies, see our gradual rollouts guide.

The Rollgate SDK handles rollout percentages server-side using consistent hashing. This means:

The same user always gets the same result for a given flag (no flickering).
Users in the 5% rollout are always included in the 25% rollout.
Distribution is statistically uniform.

// In the Rollgate dashboard, set "new-checkout" to 10% rollout.
// In your code, just check the flag:

func checkoutHandler(w http.ResponseWriter, r *http.Request) {
    userID := getUserID(r)

    // The SDK evaluates the rollout percentage using consistent
    // hashing of flagKey + userID. No extra code needed.
    if flagClient.IsEnabled("new-checkout", false,
        rollgate.WithUser(userID),
    ) {
        newCheckoutFlow(w, r)
    } else {
        currentCheckoutFlow(w, r)
    }
}

You control the percentage from the Rollgate dashboard. Start at 1%, monitor your metrics, bump to 10%, then 50%, then 100%. If errors spike at any stage, set it back to 0% — instantly, without redeploying.

Feature Flags with User Targeting

Beyond percentage rollouts, you can target specific users, segments, or attributes. This is useful for beta programs, enterprise features, or regional launches.

Attribute-Based Targeting

Set up targeting rules in the Rollgate dashboard. For example: enable advanced-analytics for users where plan equals pro or enterprise.

// Identify the user with attributes
err := client.Identify(ctx, &rollgate.UserContext{
    ID:    userID,
    Email: user.Email,
    Attributes: map[string]any{
        "plan":       user.Plan,        // "free", "starter", "pro", "enterprise"
        "country":    user.Country,     // "US", "DE", "JP"
        "created_at": user.CreatedAt,   // signup date
        "team_size":  user.TeamSize,    // number
    },
})
if err != nil {
    log.Printf("identify error: %v", err)
}

// Now flag evaluations consider these attributes
if client.IsEnabled("advanced-analytics", false) {
    // Only users matching the targeting rules see this
    showAdvancedAnalytics()
}

Segment Examples

Common targeting patterns you can configure in the dashboard:

Beta testers: email ends with @yourcompany.com
Enterprise features: plan equals enterprise
Regional rollout: country in US, CA, GB
Power users: team_size greater than 50
New users: created_at after a specific date

The SDK evaluates targeting rules locally after the initial fetch, so there is no per-evaluation API call.

Testing with Feature Flags

Testability is a first-class concern in Go. The Rollgate SDK is designed around interfaces, making it easy to mock in tests.

Define a Flag Client Interface

// featureflags.go
package featureflags

// Client defines the interface for feature flag evaluation.
type Client interface {
    IsEnabled(flagKey string, defaultValue bool) bool
    Close()
}

Mock Implementation for Tests

// featureflags_test.go
package featureflags

type MockClient struct {
    Flags map[string]bool
}

func (m *MockClient) IsEnabled(flagKey string, defaultValue bool) bool {
    if val, ok := m.Flags[flagKey]; ok {
        return val
    }
    return defaultValue
}

func (m *MockClient) Close() {}

Test Both Paths

Always test both the enabled and disabled paths. Feature flags that are never tested in both states are bugs waiting to happen.

func TestCheckoutHandler(t *testing.T) {
    tests := []struct {
        name       string
        flagValue  bool
        wantStatus int
        wantBody   string
    }{
        {
            name:       "new checkout enabled",
            flagValue:  true,
            wantStatus: http.StatusOK,
            wantBody:   `{"version":"v2"}`,
        },
        {
            name:       "new checkout disabled",
            flagValue:  false,
            wantStatus: http.StatusOK,
            wantBody:   `{"version":"v1"}`,
        },
    }

    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            mock := &MockClient{
                Flags: map[string]bool{
                    "new-checkout": tt.flagValue,
                },
            }

            handler := NewCheckoutHandler(mock)
            req := httptest.NewRequest("GET", "/checkout", nil)
            w := httptest.NewRecorder()

            handler.ServeHTTP(w, req)

            if w.Code != tt.wantStatus {
                t.Errorf("got status %d, want %d", w.Code, tt.wantStatus)
            }
        })
    }
}

This is a pattern we use heavily in Rollgate's own API. See feature flags vs feature branches for more on how flags improve your testing workflow.

Feature Flag Middleware Pattern

For applications that check multiple flags across many handlers, a middleware pattern keeps your code DRY. Evaluate flags once per request and inject the results into context.Context:

package middleware

import (
    "context"
    "net/http"

    rollgate "github.com/rollgate/sdk-go"
)

type contextKey string

const FlagsKey contextKey = "feature-flags"

// FeatureFlags is a map of flag keys to their boolean values.
type FeatureFlags map[string]bool

// WithFeatureFlags evaluates a set of flags for each request
// and stores the results in the request context.
func WithFeatureFlags(client *rollgate.Client, flags []string) func(http.Handler) http.Handler {
    return func(next http.Handler) http.Handler {
        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
            userID := getUserIDFromRequest(r)

            evaluated := make(FeatureFlags, len(flags))
            for _, flag := range flags {
                evaluated[flag] = client.IsEnabled(flag, false,
                    rollgate.WithUser(userID),
                )
            }

            ctx := context.WithValue(r.Context(), FlagsKey, evaluated)
            next.ServeHTTP(w, r.WithContext(ctx))
        })
    }
}

// GetFlags retrieves the evaluated flags from the request context.
func GetFlags(ctx context.Context) FeatureFlags {
    flags, ok := ctx.Value(FlagsKey).(FeatureFlags)
    if !ok {
        return FeatureFlags{}
    }
    return flags
}

// IsEnabled is a convenience function to check a single flag from context.
func IsEnabled(ctx context.Context, flagKey string) bool {
    return GetFlags(ctx)[flagKey]
}

Use it with Chi:

r := chi.NewRouter()

// Apply middleware — flags are evaluated once per request
r.Use(middleware.WithFeatureFlags(flagClient, []string{
    "search-v2",
    "new-pricing",
    "dark-mode",
}))

r.Get("/api/search", func(w http.ResponseWriter, r *http.Request) {
    if middleware.IsEnabled(r.Context(), "search-v2") {
        searchV2(w, r)
    } else {
        searchV1(w, r)
    }
})

This pattern evaluates all flags once at the middleware layer, avoiding repeated IsEnabled calls throughout your handlers. It also makes testing straightforward: just inject a context with the flags you want to test.

Performance: Local Evaluation vs API Calls

A common concern with feature flags in Go is latency. The Rollgate SDK is built for performance-critical services with multiple layers of optimization.

How the SDK Works

Initial fetch: On Init(), the SDK fetches all flag values from the API in a single HTTP request.
Local evaluation: After initialization, IsEnabled() reads from an in-memory map. There is no network call per evaluation. This means sub-microsecond flag checks.
Background updates: The SDK keeps flags fresh via either polling (default: every 30 seconds) or SSE streaming (real-time, sub-second updates).
Multi-layer caching: Flags are cached in memory with configurable TTL. If the API is unreachable, stale cache values are used as fallback.

SSE Streaming for Real-Time Updates

For applications where flag changes must propagate instantly (kill switches, incident response), enable SSE streaming:

client, _ := rollgate.NewClient(rollgate.Config{
    APIKey:         os.Getenv("ROLLGATE_API_KEY"),
    EnableStreaming: true, // Real-time updates via Server-Sent Events
})

With streaming enabled, flag changes propagate to your Go service in under one second. No polling delay.

Circuit Breaker

The SDK includes a built-in circuit breaker that protects your service when the Rollgate API is down:

After 5 consecutive failures, the circuit opens and the SDK stops making requests.
Cached flag values are used as fallback during the outage.
After 30 seconds, the circuit enters half-open state and tests with a single request.
After 3 successful requests, the circuit closes and normal operation resumes.

// Monitor circuit breaker state
client.OnCircuitOpen(func() {
    log.Warn("rollgate circuit breaker opened — using cached flags")
    metrics.Increment("rollgate.circuit_open")
})

client.OnCircuitClosed(func() {
    log.Info("rollgate circuit breaker closed — back to normal")
})

This means your Go service never fails because of a feature flag service outage. Flags degrade gracefully to cached values.

Performance Summary

Operation	Latency
`IsEnabled()` call	< 1 microsecond (in-memory lookup)
Initial flag fetch	~50-100ms (single HTTP request)
Background refresh (polling)	Every 30s, non-blocking
SSE update propagation	< 1 second
Fallback to cache	Automatic, zero-latency

FAQ

How do feature flags affect Go binary size?

The Rollgate Go SDK adds minimal overhead to your binary. It has zero external dependencies beyond the Go standard library. Typical binary size increase is around 2-3 MB.

Can I use feature flags in Go without a third-party service?

Yes. You can start with the DIY approach using config files or environment variables. However, you will quickly need targeting, gradual rollouts, and real-time updates — which require a service like Rollgate.

How do feature flags work with Go's concurrency model?

The Rollgate SDK is fully goroutine-safe. The internal flag store is protected by sync.RWMutex, so multiple goroutines can call IsEnabled() concurrently without contention. Background polling and SSE streaming run in separate goroutines.

What happens if the Rollgate API is unreachable?

The SDK uses a multi-layer fallback strategy: retry with exponential backoff, circuit breaker to prevent cascading failures, and stale cache as a last resort. Your service continues to operate with the last known flag values.

Should I use polling or SSE streaming?

Use polling (the default) for most services. It is simpler and works well when flag changes can take up to 30 seconds to propagate. Use SSE streaming when you need real-time updates, such as kill switches or incident response flags.

How do I clean up old feature flags?

Remove the flag from your code first, deploy, then archive it in the Rollgate dashboard. Never remove a flag from the dashboard before removing the code — you would get the default value instead of the intended behavior.

Next Steps

Ready to add feature flags to your Go application?

Create a free Rollgate account — no credit card required
Read the Go SDK docs — full API reference and advanced configuration
Learn about gradual rollouts — ship features safely with percentage-based rollouts

Feature flags in Go let you ship faster, roll back instantly, and target specific users — all without redeploying your service. Start with a simple boolean flag and expand to gradual rollouts and user targeting as your needs grow.

Feature Flags in Python: Django, FastAPI & Flask Guide

Domenico Giordano — Thu, 23 Apr 2026 22:57:25 +0000

This was originally published on rollgate.io/blog/feature-flags-python.

Why Feature Flags in Python?

Python powers everything from web applications and REST APIs to data pipelines and machine learning systems. Across all of these, you face the same challenge: how do you ship new features safely without risky deployments?

Feature flags solve this by decoupling deployment from release. You deploy code with the feature wrapped in a conditional, then control who sees it — without touching your codebase.

Here is where feature flags shine in Python projects:

Web applications — Roll out new UI components or API endpoints to a subset of users in Django, FastAPI, or Flask.
REST APIs — Version API behavior dynamically without maintaining separate endpoints.
Data pipelines — Toggle new ETL logic or processing steps without redeploying Airflow DAGs.
ML model rollouts — A/B test model versions in production, compare accuracy, and roll back instantly if metrics degrade.

If you have ever been burned by a production deploy that broke something for all users at once, feature flags are the safety net you need.

Quick Start: Feature Flags with the Rollgate Python SDK

The fastest way to add feature flags to any Python application is with the Rollgate Python SDK. Install it with pip:

pip install rollgate-python

Initialize the client and start evaluating flags:

from rollgate import RollgateClient

# Initialize once at application startup
client = RollgateClient(
    sdk_key="your-sdk-key",
    options={
        "poll_interval": 30,  # refresh flags every 30 seconds
    }
)

# Evaluate a boolean flag
if client.is_enabled("new-dashboard", default=False):
    show_new_dashboard()
else:
    show_legacy_dashboard()

# Evaluate with user context for targeting
user_context = {
    "key": "user-123",
    "email": "alice@example.com",
    "plan": "pro",
    "country": "IT",
}

if client.is_enabled("beta-feature", context=user_context):
    enable_beta(user_context["key"])

The client fetches flag configurations from Rollgate and caches them locally. Evaluations happen in-memory with no network calls, so they add virtually zero latency to your application.

You can get your SDK key by creating a free Rollgate account.

The Simple Approach: Environment Variables

Before reaching for a feature flag service, many teams start with environment variables:

import os

NEW_CHECKOUT = os.getenv("FF_NEW_CHECKOUT", "false").lower() == "true"

def process_order(order):
    if NEW_CHECKOUT:
        return new_checkout_flow(order)
    return legacy_checkout_flow(order)

This works for simple on/off switches, but it hits limitations fast:

Requires a redeploy to change a flag value.
No gradual rollouts — it is all-or-nothing for every user.
No user targeting — you cannot enable a feature for specific users or segments.
No audit trail — who changed what and when?
No instant rollback — reverting means changing the env var and redeploying.

Environment variables are fine for infrastructure configuration (DATABASE_URL, LOG_LEVEL). For feature releases, you need something more flexible.

Feature Flags in Django

Django applications benefit from feature flags at multiple layers: middleware, views, templates, and Django REST Framework serializers.

Middleware

Apply feature flags globally across all requests:

# myapp/middleware.py
from rollgate import RollgateClient

client = RollgateClient(sdk_key="your-sdk-key")

class FeatureFlagMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        context = {}
        if request.user.is_authenticated:
            context = {
                "key": str(request.user.id),
                "email": request.user.email,
                "plan": getattr(request.user, "plan", "free"),
            }

        request.feature_flags = {
            "new_nav": client.is_enabled("new-nav", context=context),
            "dark_mode": client.is_enabled("dark-mode", context=context),
        }

        return self.get_response(request)

View Decorator

Create a reusable decorator for protecting views behind flags:

# myapp/decorators.py
from functools import wraps
from django.http import Http404

def feature_required(flag_name: str):
    def decorator(view_func):
        @wraps(view_func)
        def wrapper(request, *args, **kwargs):
            context = {"key": str(request.user.id)} if request.user.is_authenticated else {}
            if not client.is_enabled(flag_name, context=context):
                raise Http404
            return view_func(request, *args, **kwargs)
        return wrapper
    return decorator

# Usage
@feature_required("new-analytics")
def analytics_view(request):
    return render(request, "analytics/new.html")

Template Tags

Expose flags directly in Django templates:

# myapp/templatetags/feature_flags.py
from django import template

register = template.Library()

@register.simple_tag(takes_context=True)
def feature_enabled(context, flag_name: str) -> bool:
    request = context.get("request")
    if request and hasattr(request, "feature_flags"):
        return request.feature_flags.get(flag_name, False)
    return False

{% load feature_flags %}

{% feature_enabled "new-nav" as show_new_nav %}
{% if show_new_nav %}
    {% include "nav/new_nav.html" %}
{% else %}
    {% include "nav/legacy_nav.html" %}
{% endif %}

Django REST Framework

Use flags in DRF views and serializers to control API behavior:

# myapp/views.py
from rest_framework.views import APIView
from rest_framework.response import Response

class ProductListView(APIView):
    def get(self, request):
        context = {"key": str(request.user.id), "plan": request.user.plan}

        if client.is_enabled("v2-product-response", context=context):
            serializer = ProductV2Serializer(products, many=True)
        else:
            serializer = ProductV1Serializer(products, many=True)

        return Response(serializer.data)

Feature Flags in FastAPI

FastAPI's dependency injection system makes feature flags clean and testable.

Dependency Injection Pattern

# app/dependencies.py
from fastapi import Depends, HTTPException, Request
from rollgate import RollgateClient

client = RollgateClient(sdk_key="your-sdk-key")

def get_flag_context(request: Request) -> dict:
    user = request.state.user if hasattr(request.state, "user") else None
    if user:
        return {"key": user.id, "email": user.email, "plan": user.plan}
    return {}

def require_feature(flag_name: str):
    def dependency(context: dict = Depends(get_flag_context)):
        if not client.is_enabled(flag_name, context=context):
            raise HTTPException(status_code=404, detail="Not found")
        return True
    return dependency

# app/routes/search.py
from fastapi import APIRouter, Depends
from app.dependencies import require_feature, get_flag_context, client

router = APIRouter()

@router.get("/search")
async def search(
    query: str,
    context: dict = Depends(get_flag_context),
):
    if client.is_enabled("ai-search", context=context):
        results = await ai_powered_search(query)
    else:
        results = await keyword_search(query)

    return {"results": results}

@router.get(
    "/search/semantic",
    dependencies=[Depends(require_feature("semantic-search"))],
)
async def semantic_search(query: str):
    """This entire endpoint is gated behind a feature flag."""
    return {"results": await run_semantic_search(query)}

Middleware

# app/middleware.py
from starlette.middleware.base import BaseHTTPMiddleware

class FeatureFlagMiddleware(BaseHTTPMiddleware):
    async def dispatch(self, request, call_next):
        context = {}
        if hasattr(request.state, "user"):
            context = {"key": request.state.user.id}

        request.state.flags = {
            "maintenance_mode": client.is_enabled("maintenance-mode", context=context),
        }

        if request.state.flags.get("maintenance_mode"):
            return JSONResponse(
                status_code=503,
                content={"message": "We are performing scheduled maintenance."},
            )

        return await call_next(request)

Feature Flags in Flask

Flask's simplicity pairs well with decorator-based feature flags.

Decorator Pattern

# app/flags.py
from functools import wraps
from flask import abort, g
from rollgate import RollgateClient

client = RollgateClient(sdk_key="your-sdk-key")

def feature_required(flag_name: str):
    def decorator(f):
        @wraps(f)
        def wrapped(*args, **kwargs):
            context = {"key": str(g.user.id)} if hasattr(g, "user") else {}
            if not client.is_enabled(flag_name, context=context):
                abort(404)
            return f(*args, **kwargs)
        return wrapped
    return decorator

# Usage
@app.route("/experiments")
@feature_required("experiments-page")
def experiments():
    return render_template("experiments.html")

before_request Hook

Evaluate flags once per request and make them available globally:

# app/__init__.py
from flask import Flask, g

app = Flask(__name__)

@app.before_request
def load_feature_flags():
    context = {}
    if hasattr(g, "user") and g.user:
        context = {
            "key": str(g.user.id),
            "email": g.user.email,
        }

    g.flags = {
        "new_pricing": client.is_enabled("new-pricing", context=context),
        "export_csv": client.is_enabled("export-csv", context=context),
    }

<!-- templates/pricing.html -->
{% if g.flags.new_pricing %}
    {% include "pricing/new.html" %}
{% else %}
    {% include "pricing/legacy.html" %}
{% endif %}

Gradual Rollouts

Instead of flipping a feature on for everyone, gradual rollouts let you increase exposure incrementally.

Percentage-Based Rollouts

Configure a rollout percentage in the Rollgate dashboard (for example, 10%), and the SDK handles consistent user assignment:

# The SDK uses consistent hashing on the user key.
# The same user always gets the same result for a given percentage.

context = {"key": f"user-{user_id}"}

if client.is_enabled("new-checkout", context=context):
    # This user is in the rollout group
    return new_checkout(cart)
else:
    return legacy_checkout(cart)

A typical rollout schedule:

Day 1:   5%  → internal team + early adopters
Day 3:  25%  → monitor error rates and latency
Day 5:  50%  → check support tickets
Day 7: 100%  → full release

If error rates spike at any stage, set the rollout back to 0% instantly from the dashboard.

User Targeting with Attributes

Target specific users or segments by passing attributes in the context:

context = {
    "key": str(user.id),
    "email": user.email,
    "plan": user.subscription.plan,       # "free", "starter", "pro"
    "country": user.profile.country,       # "US", "IT", "DE"
    "created_at": user.created_at.isoformat(),
}

# In the Rollgate dashboard, you can create rules like:
# - Enable for plan = "pro"
# - Enable for country IN ["US", "DE"]
# - Enable for 20% of free plan users

if client.is_enabled("advanced-analytics", context=context):
    return full_analytics(user)
else:
    return basic_analytics(user)

Feature Flags for ML Model Rollouts

Machine learning models in production need careful rollout strategies. A new model might have better accuracy on your test set but degrade on edge cases in production. Feature flags let you A/B test model versions safely.

A/B Test Model Versions

from rollgate import RollgateClient

client = RollgateClient(sdk_key="your-sdk-key")

def predict(user_id: str, input_data: dict) -> dict:
    context = {"key": user_id}

    if client.is_enabled("recommendation-model-v2", context=context):
        model = load_model("recommendation_v2")
        prediction = model.predict(input_data)
        log_prediction(user_id, model="v2", prediction=prediction)
    else:
        model = load_model("recommendation_v1")
        prediction = model.predict(input_data)
        log_prediction(user_id, model="v1", prediction=prediction)

    return prediction

Start the recommendation-model-v2 flag at 5%, monitor prediction quality metrics, and increase gradually.

Shadow Mode

Run both models simultaneously, serve the old one, and log the new one for comparison:

def predict_with_shadow(user_id: str, input_data: dict) -> dict:
    context = {"key": user_id}

    # Always run the current production model
    v1_model = load_model("recommendation_v1")
    v1_result = v1_model.predict(input_data)

    # Shadow mode: run v2 in parallel, log results, but don't serve them
    if client.is_enabled("shadow-model-v2", context=context):
        v2_model = load_model("recommendation_v2")
        v2_result = v2_model.predict(input_data)

        log_shadow_comparison(
            user_id=user_id,
            v1=v1_result,
            v2=v2_result,
            match=v1_result == v2_result,
        )

    return v1_result  # always serve v1 during shadow mode

Once shadow mode data confirms v2 performs well, switch to the A/B test approach to serve v2 to real users.

Testing with Feature Flags

Feature flags should not make your test suite unpredictable. Use fixtures and mocks to control flag state in tests.

Pytest Fixtures

# conftest.py
import pytest
from unittest.mock import MagicMock

@pytest.fixture
def mock_rollgate():
    client = MagicMock()
    client.is_enabled.return_value = False
    return client

@pytest.fixture
def mock_rollgate_all_enabled():
    client = MagicMock()
    client.is_enabled.return_value = True
    return client

Testing Both Code Paths

# test_checkout.py
from unittest.mock import patch

def test_legacy_checkout(mock_rollgate):
    mock_rollgate.is_enabled.return_value = False

    with patch("myapp.checkout.client", mock_rollgate):
        result = process_checkout(cart)

    assert result.flow == "legacy"

def test_new_checkout(mock_rollgate):
    mock_rollgate.is_enabled.return_value = True

    with patch("myapp.checkout.client", mock_rollgate):
        result = process_checkout(cart)

    assert result.flow == "new"

Flag-Specific Mocking

def test_partial_flags(mock_rollgate):
    def side_effect(flag_name, **kwargs):
        enabled_flags = {"new-checkout": True, "dark-mode": False}
        return enabled_flags.get(flag_name, False)

    mock_rollgate.is_enabled.side_effect = side_effect

    with patch("myapp.views.client", mock_rollgate):
        response = app_client.get("/checkout")
        assert response.status_code == 200

Async Support

Modern Python applications often use asyncio. The Rollgate Python SDK supports async evaluation for non-blocking flag checks:

import asyncio
from rollgate import RollgateClient

client = RollgateClient(sdk_key="your-sdk-key")

async def handle_request(user_id: str):
    context = {"key": user_id}

    # Flag evaluation is local (cached), so it's fast even in sync mode.
    # For async initialization and polling:
    if client.is_enabled("async-feature", context=context):
        result = await async_new_logic()
    else:
        result = await async_legacy_logic()

    return result

Since flag evaluations happen against locally cached data, they are inherently fast. The async support is primarily useful for the initial flag fetch and background polling, ensuring they do not block your event loop.

# FastAPI example with async
from fastapi import FastAPI

app = FastAPI()

@app.on_event("startup")
async def startup():
    # Initialize the client at startup
    global client
    client = RollgateClient(sdk_key="your-sdk-key")

@app.get("/api/recommendations")
async def recommendations(user_id: str):
    context = {"key": user_id}

    if client.is_enabled("ml-recommendations-v2", context=context):
        return await get_ml_recommendations_v2(user_id)
    return await get_ml_recommendations_v1(user_id)

Frequently Asked Questions

Do feature flags add latency to my Python app?

No. The Rollgate SDK fetches flag configurations on startup and polls for updates in the background. All flag evaluations happen locally in memory, adding microseconds of overhead — not milliseconds.

Can I use feature flags with Celery tasks?

Yes. Initialize the Rollgate client once in your Celery worker startup, and evaluate flags inside tasks just like you would in a view:

from celery import Celery
from rollgate import RollgateClient

app = Celery("tasks")
client = RollgateClient(sdk_key="your-sdk-key")

@app.task
def process_report(user_id: str):
    context = {"key": user_id}
    if client.is_enabled("new-report-format", context=context):
        generate_new_report(user_id)
    else:
        generate_legacy_report(user_id)

How do I handle flags in database migrations?

Do not use feature flags in migrations. Migrations should be deterministic and repeatable. Instead, use flags in application code to control which schema or logic path is active.

What happens if the Rollgate service is unreachable?

The SDK caches the last known flag state locally. If it cannot reach Rollgate to poll for updates, it continues using cached values. You can also set default values that apply when a flag has never been fetched.

Can I use feature flags with Django's test client?

Yes. Mock the Rollgate client in your Django test setup, or use the middleware approach and override request.feature_flags directly in tests.

Start Using Feature Flags in Python

Feature flags transform how you ship Python applications. Whether you are building a Django web app, a FastAPI microservice, or a Flask API, the pattern is the same: wrap new code in a flag check, deploy safely, and control the rollout from your dashboard.

Ready to get started?

Create a free Rollgate account
Install the SDK: pip install rollgate-python
Read the Python SDK documentation for the full API reference

No credit card required. Free tier includes 500K requests/month and unlimited flags.

Feature Flag Platform Comparison 2026: An Honest Self-Audit

Domenico Giordano — Thu, 23 Apr 2026 22:57:09 +0000

This was originally published on rollgate.io/blog/rollgate-product-audit-2026.

Why We're Publishing Our Own Product Audit

Most SaaS companies publish comparison pages that make them look perfect. We're doing something different: a brutally honest audit of our own platform, scored by the same criteria we'd use to evaluate any feature flag tool.

We built Rollgate because we were tired of paying five figures for a configuration service. But being cheaper isn't enough — you need to be good. So we asked ourselves: if a senior product owner with 10 years of experience building feature flag platforms evaluated Rollgate today, what would they say?

Here's the result. Every feature area scored 1-5, compared against LaunchDarkly, Flagsmith, ConfigCat, and GrowthBook. No cherry-picking, no spin.

Core Feature Flags — 4.5/5

What we built: Four flag types (boolean, string, number, JSON), four categories (release, experiment, kill switch, ops), full lifecycle management with scheduling, 1-click rollback, history, tags, and multi-environment support.

What's strong: Scheduled changes are available on every paid plan. LaunchDarkly restricts scheduling to Enterprise tier. Our rollback system stores the last 20 states per flag — one click restores the exact previous configuration including targeting rules, percentage, and variations.

What's missing: Flag dependencies (enable flag B only if flag A is enabled). Stale flag detection (warn when a flag has been at 100% for weeks). Approval workflows for critical flags. These are enterprise features that matter at scale but aren't critical for our current target market.

vs competitors: On par with Flagsmith and ConfigCat for core flag management. Below LaunchDarkly for enterprise workflows (approval gates, change requests). Ahead of GrowthBook, which treats flags as secondary to experimentation. For a detailed comparison, see our LaunchDarkly alternative guide.

Targeting & Segmentation — 4/5

What we built: 18 targeting operators including semver comparison, regex, numeric ranges, and list membership. Two segment types: rule-based (define conditions) and list-based (explicit user lists). Segments are reusable across flags. Percentage rollouts use consistent hashing so the same user always sees the same variant.

The 18 operators:
equals, not_equals, contains, not_contains, starts_with, ends_with, in, not_in, gt, gte, lt, lte, regex, is_set, is_not_set, semver_gt, semver_lt, semver_eq

What's strong: Semver targeting is rare — most competitors don't offer it. This matters for mobile teams doing version-based rollouts. Rule-based segments with reuse across flags reduce duplication.

What's missing: Segment match count preview ("this rule matches ~2,340 users" before saving). CSV import for list-based segments. Nested rule groups (currently AND/OR, but not nested groups of groups).

vs competitors: On par with ConfigCat and Flagsmith. LaunchDarkly has more sophisticated targeting with prerequisites and custom attributes indexing. GrowthBook has strong experimentation targeting but simpler flag targeting.

A/B Testing & Experimentation — 3/5

This is our most honest score. A/B testing works, but it's not yet where it needs to be for data-driven product teams.

What we built: Full experiment lifecycle (draft → running → paused → ended). Per-variation statistics with exposures, conversions, and conversion rates. Z-test statistical significance with confidence intervals. Lift calculation. Winner declaration with optional auto-rollout to the winning variation. Event tracking integrated into all 13 SDKs.

What's strong: Auto-rollout of the winning variation is a genuine time-saver — declare a winner and the flag automatically updates to serve the winning variant to 100% of users. Event tracking is built into every SDK, not bolted on.

What's missing: Mutual exclusion between experiments (critical when running overlapping tests). Sample size calculator (users don't know how much traffic they need for statistical significance). Guardrail metrics (automatically stop an experiment if a critical metric degrades). Bayesian statistics as an alternative to frequentist testing. Experiment report export.

These gaps matter. Without mutual exclusion, overlapping experiments can produce invalid results. Without sample size estimation, teams either run experiments too short (inconclusive) or too long (wasted time).

vs competitors: Below GrowthBook, which is experimentation-first and offers Bayesian stats, sequential testing, and warehouse integration. On par with Flagsmith (which has no native A/B testing). Below LaunchDarkly's Experimentation add-on. Above ConfigCat, which has zero A/B capability.

What we're building next: Mutual exclusion layers and a sample size calculator are our top experimentation priorities.

Real-Time & Performance — 5/5

What we built: Server-Sent Events (SSE) streaming across 12 of 13 SDKs (Flutter uses polling). Redis caching with 60-second TTL. ETag and Last-Modified conditional requests. Cache invalidation on flag changes. Bulk flag fetching. Per-plan SSE connection limits. Local evaluation mode — server SDKs download the full ruleset via SSE and evaluate flags locally without network round-trips.

What's strong: Local evaluation is the same architecture LaunchDarkly uses with their Relay Proxy, but we built it directly into the SDK. Flag evaluation happens in-memory with sub-microsecond latency. The API responds in 2-3ms server-side. Circuit breakers in every SDK ensure your application never fails because the flag service is down.

Every SDK ships with:

Circuit breaker (CLOSED → OPEN → HALF_OPEN state machine)
Exponential backoff with jitter
Request deduplication
Stale-while-revalidate caching
ETag support for bandwidth efficiency
Distributed tracing (W3C Trace Context)

What's missing: Flutter SSE (currently polling-only). Edge evaluation via CDN workers.

vs competitors: On par with LaunchDarkly (SSE + local eval). Ahead of ConfigCat (polling only, no local eval). Ahead of GrowthBook (local eval but no SSE). On par with Flagsmith (SSE support). The resilience features (circuit breaker, retry, tracing in every SDK) are a differentiator — most competitors add these as optional plugins, not defaults. For implementation details, see our gradual rollouts guide.

SDK Experience — 4.5/5

What we built: 13 SDKs, all published and production-ready:

SDK	Registry	Version	SSE	Unit tests
Core (shared)	npm	1.2.3	—	53
Node.js	npm	1.2.3	Yes	166
Browser	npm	1.2.3	Yes	11
React	npm	1.2.3	Yes	28
Vue	npm	1.2.3	Yes	22
Angular	npm	1.2.3	Yes	20
Svelte	npm	1.2.3	Yes	32
React Native	npm	1.2.3	No	0*
Go	Go modules	1.2.3	Yes	59
Python	PyPI	1.2.3	Yes	93
Java	Maven	1.2.3	Yes	91
.NET	NuGet	1.2.3	Yes	0*
Flutter	pub.dev	1.2.3	No	0*

*These SDKs rely on the 124 cross-SDK contract tests for behavior verification instead of individual unit test suites.

Architecture: All TypeScript SDKs share a common sdk-core package that implements caching, circuit breaker, retry, metrics, events, and tracing. Framework SDKs (React, Vue, Angular, Svelte) wrap sdk-browser, which wraps sdk-core. Native SDKs (Go, Java, Python, .NET, Flutter) implement the same patterns independently.

What's strong: 13 SDKs is more than GrowthBook (8) and on par with ConfigCat (12). Every SDK — not just the popular ones — ships with circuit breaker, retry, caching, event tracking, and distributed tracing. The consistent API surface means switching languages doesn't mean learning a new SDK.

What's missing: OpenFeature provider (the emerging vendor-neutral standard for feature flags). Offline-first mode for mobile SDKs.

vs competitors: Below LaunchDarkly (25+ SDKs) but with better feature parity across SDKs. On par with Flagsmith (18 SDKs). Ahead of GrowthBook (8). On par with ConfigCat (12). See our SDK tutorials for React, Next.js, Go, and Python.

Dashboard UX — 4/5

What we built: Complete flag management with search, filter, sort, and bulk actions. Six-step onboarding checklist that auto-tracks progress. Command palette (Cmd+K) for quick navigation. Drag-and-drop rules editor. Audit log with entity and action filtering. Usage monitoring with progress bars against plan limits. Dark mode. Fully responsive for mobile. Keyboard shortcuts.

What's strong: The onboarding checklist is better than what LaunchDarkly, Flagsmith, or ConfigCat offer for new users. It tracks actual progress (did you create a project? create a flag? make an SDK call?) rather than just showing a tutorial. The command palette is a power-user feature that none of our competitors have.

What's missing: Rule simulation ("if I save this rule, would user X see the flag?"). Environment diff view (compare flag state between staging and production side by side). Collaborative editing awareness (two people editing the same flag don't see each other's changes). In-app help tooltips on complex features.

vs competitors: On par with or ahead of ConfigCat and Flagsmith for UX quality. Below LaunchDarkly for enterprise features (approval workflows, change requests, scheduled approvals).

Billing & Packaging — 4.5/5

What we built: Paddle as Merchant of Record (automatic VAT/tax handling). Four plans (Free, Starter €39-45/mo, Pro €99-119/mo, Growth €299-349/mo) plus custom Enterprise. Monthly and annual billing with 15-18% annual discount. Full usage tracking with monthly history. Plan limit enforcement with fail-open design. Complete checkout, cancel, resume, and plan change flows.

	Free	Starter	Pro	Growth
SDK requests/mo	500K	1M	3M	12M
SSE connections	1	25	100	500
Projects	3	5	10	Unlimited
Team members	3	5	15	50
Flags	Unlimited	Unlimited	Unlimited	Unlimited
Scheduled changes	—	Yes	Yes	Yes
Rollback	—	Yes	Yes	Yes
Audit log	3 days	14 days	90 days	1 year

What's strong: The free tier (500K requests/month, unlimited flags) is the most generous in the market. ConfigCat limits you to 10 flags on free. The fail-open design means SDK calls never hard-fail when you exceed limits — they return cached values and the API returns proper rate limit headers. Pricing is transparent and public, unlike LaunchDarkly's "contact sales" model.

What's missing: Free trial for paid plans (14-day Pro trial would help conversion). Proactive email alerts when approaching usage limits.

vs competitors: Pricing is our strongest competitive advantage against LaunchDarkly. A team at 100K MAU pays ~€99/month on Rollgate vs ~$4,000/month on LaunchDarkly. That's a 40x difference. See our detailed pricing comparison and ConfigCat comparison.

Operational — 3.5/5

What we built: Seven webhook event types with HMAC signing, delivery tracking, and automatic retry. Partial OpenAPI specification (~40 of 114 endpoints). Redis-based rate limiting with sliding window. Complete audit log with IP tracking. Health, readiness, and liveness endpoints. Prometheus metrics endpoint.

What's strong: The webhook system is production-grade — HMAC signing prevents spoofing, delivery history with response codes aids debugging, and retry with backoff handles transient failures.

What's missing: Complete OpenAPI spec (only 35% of endpoints documented). CLI tool for flag management from terminal. Terraform/Pulumi provider for infrastructure-as-code workflows. Native Slack/Teams notifications. Data export (flag configurations, audit log).

vs competitors: Below LaunchDarkly and Flagsmith (both have CLI tools and Terraform providers). On par with ConfigCat. The incomplete OpenAPI spec is our biggest operational gap — developers evaluating the API want complete, interactive documentation.

The Scorecard

Area	Score	vs LD	vs Flagsmith	vs ConfigCat	vs GrowthBook
Core Flags	4.5/5	Below	Even	Even	Above
Targeting	4/5	Below	Even	Even	Even
A/B Testing	3/5	Below	Above	Above	Below
Real-Time	5/5	Even	Even	Above	Above
SDKs	4.5/5	Below*	Even	Even	Above
Dashboard	4/5	Below	Even	Above	Above
Billing	4.5/5	Above	Even	Even	Even
Operational	3.5/5	Below	Below	Even	Even

*LaunchDarkly has more SDKs (25+) but Rollgate has better feature parity across all 13.

Overall: 4.1/5

What We're Building Next

Based on this audit, here are our priorities ordered by impact:

High Priority

Free trial for Pro plan — 14 days, no credit card. Let users experience scheduled changes and rollback before committing.
Mutual exclusion for A/B tests — Without this, overlapping experiments produce invalid data.
Sample size calculator — Show users how much traffic they need before starting an experiment.
Complete OpenAPI spec — Cover all 114 endpoints with interactive documentation.

Medium Priority

Rule simulation — "Test this targeting rule against user X" before saving.
CLI tool — Manage flags from terminal, integrate with CI/CD pipelines.
Slack notifications — Alert channels when flags change.
Environment diff view — Compare flag state across environments side by side.

Quick Wins (In Progress)

Stale flag detection banner
Usage warning indicators
Contextual upgrade prompts
Environment diff badges

FAQ

Is Rollgate a good alternative to LaunchDarkly?

For teams under 50 developers, yes. Rollgate covers the same core use cases (feature flags, targeting, rollouts, kill switches) at a fraction of the cost. The main gaps are enterprise features like approval workflows and SSO SAML. See our detailed LaunchDarkly comparison.

How does Rollgate compare to open-source tools like Flagsmith and GrowthBook?

Rollgate scores higher on real-time infrastructure (SSE + local evaluation) and SDK resilience (circuit breakers in every SDK). Flagsmith has more SDKs (18 vs 13) and a self-hosted option. GrowthBook has stronger A/B testing with Bayesian statistics. Rollgate sits between them — stronger than Flagsmith on experimentation, stronger than GrowthBook on feature flag management.

What are Rollgate's biggest weaknesses?

A/B testing (3/5) and operational tooling (3.5/5). Specifically: no mutual exclusion between experiments, no sample size calculator, incomplete OpenAPI documentation, and no CLI tool. We're actively building all of these.

Is Rollgate production-ready?

Yes. 13 published SDKs, all with circuit breakers and graceful degradation. The API runs on Hetzner in Germany (EU data residency) with PostgreSQL and Redis. The fail-open design means your application continues working even if the Rollgate API is temporarily unreachable.

How much does Rollgate cost compared to competitors?

A team with 100K monthly active users pays ~€99/month on Rollgate vs ~$4,000/month on LaunchDarkly. That's a 40x difference. See the full pricing breakdown.

The Honest Summary

Rollgate is a solid 4/5 platform that covers the core feature flag use case better than most alternatives, at a fraction of the cost. Our real-time infrastructure and SDK resilience are best-in-class. Our A/B testing and operational tooling need work.

If you're a team of 2-50 developers who need feature flags, gradual rollouts, and basic experimentation without spending $25K+/year, Rollgate is built for you. If you need enterprise approval workflows, a 25-SDK ecosystem, or advanced statistical experimentation, LaunchDarkly or GrowthBook might be better fits today.

We're shipping improvements every week. This audit will be updated quarterly — follow our changelog or join the Discord to stay in the loop.

Try Rollgate free — 500K requests/month, all 13 SDKs, no credit card required.

How to Implement Gradual Rollouts Without Breaking Production

Domenico Giordano — Thu, 23 Apr 2026 22:56:49 +0000

This was originally published on rollgate.io/blog/gradual-rollouts-guide.

What Is a Gradual Rollout?

A gradual rollout (also called progressive delivery or incremental rollout) is the practice of releasing a feature to a small subset of users first, then progressively expanding to the full user base. Instead of going from 0% to 100% in one step, you control the pace.

Day 1: 1% of users → Monitor
Day 2: 5% of users → Monitor
Day 3: 25% of users → Monitor
Day 5: 100% of users → Done

If something goes wrong at any stage, you roll back to 0% instantly. No code changes, no redeployment, no downtime.

Why Gradual Rollouts Matter

Reduce Blast Radius

A bug that affects 1% of users is very different from a bug that affects 100%. Gradual rollouts contain the impact of issues, giving you time to detect and fix problems before they reach everyone.

Build Confidence

Shipping a big feature to all users at once is stressful. Gradual rollouts let you validate in production with real traffic, real data, and real user behavior — at a safe scale.

Enable Data-Driven Decisions

By monitoring metrics at each stage (error rates, latency, conversion), you make rollout decisions based on data, not gut feeling.

Instant Rollback

Traditional rollbacks require reverting code, running CI, and redeploying. With feature flags, rollback is a single toggle that takes effect in seconds.

Rollout Strategies

1. Percentage-Based Rollout

The most common approach. You specify a percentage of users who should see the new feature. The feature flag service uses consistent hashing to ensure the same users always see the same variant (so a user at 5% who sees the feature will still see it at 25%).

// In your feature flag dashboard:
// new-search-algorithm: 10% rollout

const useNewSearch = rollgate.isEnabled('new-search-algorithm', {
  userId: user.id
});

Best for: General feature releases, UI changes, algorithm updates.

2. Canary Release

Start with a tiny group (0.1–1%) of users. These are your "canaries in the coal mine." If metrics look good after a set period, expand to a larger group.

Typical canary schedule:

0.1% for 1 hour → Check error rates
1% for 4 hours → Check performance
10% for 24 hours → Check user feedback
50% for 24 hours → Final validation
100% → Full release

Best for: Backend changes, infrastructure updates, anything with high risk.

3. Ring Deployment

Expand through predefined rings of users, from least to most critical:

Ring 0: Internal team (dogfooding)
Ring 1: Beta users / early adopters
Ring 2: 10% of general users
Ring 3: 50% of general users
Ring 4: All users

This approach is popular at Microsoft and gives you structured checkpoints.

Best for: Enterprise software, B2B platforms, features with compliance requirements.

4. User Segment Targeting

Instead of random percentages, target specific user segments first:

Enable for users on the "Pro" plan first
Enable for users in a specific region
Enable for users who opted into the beta program

// Rollgate supports targeting rules:
// If user.plan == "pro" → enable
// Else → 10% rollout

const showAdvancedAnalytics = rollgate.isEnabled('advanced-analytics', {
  userId: user.id,
  attributes: {
    plan: user.plan,
    region: user.region
  }
});

Best for: Tiered features, regional launches, B2B features.

Implementing Gradual Rollouts: Step by Step

Step 1: Create the Feature Flag

In your feature flag dashboard, create a flag with a clear name and description:

Key: new-checkout-flow
Description: Redesigned checkout with one-page form
Type: Boolean
Default: false

Step 2: Add the Flag to Your Code

Wrap the new feature behind the flag check:

import { Rollgate } from '@rollgate/sdk-node';

const rollgate = new Rollgate({ apiKey: process.env.ROLLGATE_API_KEY });

app.get('/checkout', async (req, res) => {
  const useNewCheckout = await rollgate.isEnabled('new-checkout-flow', {
    userId: req.user.id,
    attributes: { plan: req.user.plan }
  });

  if (useNewCheckout) {
    return res.render('checkout-v2');
  }
  return res.render('checkout-v1');
});

Step 3: Deploy with Flag Off

Merge and deploy your code. The flag is off, so all users see the old checkout. Nothing changes.

Step 4: Enable for Internal Team

Set a targeting rule: enable for users with email ending in @yourcompany.com. Test the full flow with real production data.

Step 5: Expand Gradually

Once internal testing passes:

Enable for 5% of users
Monitor for 24 hours: error rates, latency, conversion rate
If metrics are healthy, increase to 25%
Monitor for another 24 hours
Increase to 100%

Step 6: Clean Up

After successful full rollout:

Remove the flag check from your code
Delete the old code path
Archive the flag in your dashboard
Update documentation

What to Monitor During Rollout

Error Rates

Compare error rates between users with the flag on vs off. A spike in errors for the flag-on group means something is wrong.

Performance

Measure p50, p95, and p99 latency. New features sometimes introduce unexpected performance regressions.

Business Metrics

Track conversion rates, engagement, or whatever KPI the feature is meant to improve. If the new checkout reduces conversion, you want to know at 5%, not at 100%.

User Feedback

Watch support tickets and feedback channels. Sometimes metrics look fine but users are confused or frustrated.

Common Mistakes to Avoid

Rolling Out Too Fast

Going from 1% to 100% in one jump defeats the purpose. Give each stage enough time to surface issues. A 24-hour soak period at each stage is a good default.

Not Having a Rollback Plan

Before starting a rollout, define your rollback criteria. "If error rate increases by more than 2%, disable the flag." Don't wait to decide in the middle of an incident.

Ignoring Sticky Sessions

Users should consistently see the same variant. If a user sees the new checkout on Monday but the old one on Tuesday, the experience is confusing and your metrics are unreliable. Use consistent hashing on user ID.

Forgetting to Clean Up

A gradual rollout that reaches 100% is not done until the flag is removed from code. Schedule flag cleanup as part of your rollout plan, not as an afterthought.

No Monitoring

A gradual rollout without monitoring is just a slow release. The entire point is to observe metrics at each stage and make informed decisions.

Conclusion

Gradual rollouts are one of the highest-leverage practices in modern software delivery. They let you ship faster with less risk, validate changes with real production traffic, and roll back instantly when things go wrong.

The key ingredients are simple: a feature flag service, percentage-based rollout rules, and disciplined monitoring. Start with your next feature — create a flag, roll out to 5%, watch the metrics, and expand from there.

Try Rollgate free and implement your first gradual rollout in minutes.

Related reading: New to feature flags? Start with What Are Feature Flags?. Already using flags? Learn about A/B testing with feature flags, scheduled releases, and how feature flags compare to feature branches. For SDK-specific guides, see React, Go, or Python.

Feature Flags at the Edge: What Cloudflare Flagship Means for the Category

Domenico Giordano — Thu, 23 Apr 2026 22:56:19 +0000

This was originally published on rollgate.io/blog/cloudflare-flagship-edge-feature-flags.

Cloudflare Just Entered the Feature Flag Market

On April 17, 2026, Cloudflare announced Flagship, a native feature flag service evaluated at the edge. The pitch is simple and, technically, hard to argue with: if your code already runs inside a Cloudflare Worker, why would you pay a third-party SaaS to evaluate a boolean for you over HTTP?

For teams that live on Cloudflare, Flagship is a genuinely compelling product. For everyone else — and for the category as a whole — the announcement is more interesting than the product itself. It signals that feature flags are finishing their slow transition from "specialized SaaS" to "commoditized infrastructure primitive," the same path that caching, DNS, and logging walked before them.

I build Rollgate, an independent feature flag platform, so I have an obvious bias here. But I want to write about this honestly: what Flagship gets right, where it narrows the market, and where independent platforms still fit.

What Flagship Actually Is

Strip out the marketing, and Flagship is a pragmatic piece of engineering:

Control plane on Durable Objects. Flag configuration is stored authoritatively in Durable Objects and fanned out to Workers KV for global read distribution.
Evaluation at the edge. Flag values are evaluated inside the same Worker isolate that is already processing the request. No outbound HTTP call, no external dependency on the request path.
Sub-millisecond evaluation. Because there is no network hop, latency is measured in microseconds. Cloudflare positions this as essentially free on a per-request basis.
OpenFeature-native. Flagship is built on OpenFeature, the CNCF standard. You write evaluation code against the OpenFeature API and swap providers via configuration.
Multi-runtime client. The provider works on Workers (with direct bindings), Node.js, Bun, Deno, and browsers — though the best performance is obviously on Workers.
Private beta. No public pricing yet. General availability and pricing will come "as we approach GA."

The framing in the announcement leans heavily on AI-generated code and agentic workflows: autonomous systems that ship, test, and iterate without a human in the loop need kill switches, and kill switches are feature flags. That framing is smart marketing — it ties Flagship to Cloudflare's broader AI-platform story — but the underlying product works just as well for boring use cases: gradual rollouts, A/B tests, killswitches, scheduled releases.

Where Flagship Is Genuinely Great

Let me be direct: if your production traffic all terminates in Workers, Flagship is probably the right choice. Here's why.

Zero evaluation latency

Even a well-tuned independent SDK has to do something: either call the API (30–150ms round trip depending on region) or evaluate locally from a cached ruleset (still a few microseconds of hashing and rule walking). Flagship collapses the second case into a native Workers binding. It is hard to beat "the flag value is already in memory next to your code."

For most applications this difference is invisible — a well-designed SDK evaluates flags in around 1–5μs locally after the initial config fetch. But at extreme scale, or on latency-critical edge APIs, "invisible" and "zero" are not the same thing.

OpenFeature-first

The most important line in the Flagship announcement is "built on OpenFeature." This is the feature flag category finally picking a standard. OpenFeature is to feature flags what OpenTelemetry was to observability: a common API that lets you swap vendors by changing a provider, not by rewriting evaluation code.

OpenFeature being a first-class citizen in Cloudflare's product is a net positive for every feature flag platform, including independent ones. It pressures the whole market toward the standard and away from proprietary SDK lock-in.

No data plane to operate

For small teams running entirely on Cloudflare, Flagship removes a dependency. No third-party SDK to monitor, no availability SLA to track for a non-Cloudflare vendor, no secondary bill. One throat to choke is a real operational win, even if it comes at the cost of vendor concentration.

Where Flagship Narrows The Market

Flagship is a strong product for Cloudflare-native teams. For teams that are not Cloudflare-native — which, despite Cloudflare's footprint, is still the majority of production systems — the picture is more complicated.

It is Cloudflare-only infrastructure

Flagship's killer feature is its proximity to your code. That killer feature only exists when your code runs in Workers. If your backend is Go on a Hetzner VPS, Python on AWS Lambda, Java on GKE, or Node on Fly.io, Flagship's client SDK becomes just another HTTP client talking to Cloudflare's edge — and suddenly the latency advantage evaporates. You are back to the same evaluation model as any other third-party flag provider.

This is not a criticism of Cloudflare; it is an honest observation about the product's target. Flagship optimizes for the Cloudflare stack and does not pretend otherwise. But the feature flag problem does not end at the boundary of any one cloud, and most production systems span at least two.

Vendor lock-in, quietly

Because Flagship is built on OpenFeature, swapping providers is straightforward — that is the whole point of the standard. What is not straightforward is swapping infrastructure. If a significant share of your feature flag logic assumes it executes inside a Worker — cheap evaluation, bindings, edge-side targeting — migrating off Cloudflare means rewriting assumptions, not just configuration.

This is the same lock-in pattern as any cloud-native primitive. AWS Feature Flags locks you to AWS. Vercel's Edge Config locks you to Vercel. Cloudflare's Flagship locks you to Cloudflare. That is a reasonable trade-off — you pay in portability for deep integration — but it is a trade-off worth naming.

Private beta, no pricing

As of this writing, Flagship is invite-only with no public pricing. Teams evaluating a feature flag vendor today cannot choose Flagship. That is not a dig; every product starts somewhere. But it means the immediate market impact is limited, and the real impact depends entirely on what the pricing looks like at GA.

The Bigger Trend: Flags Are Becoming Infrastructure

Zoom out from Cloudflare specifically and a pattern becomes obvious. In 2024 Vercel shipped Edge Config as a low-latency key-value store explicitly positioned for feature flags. In 2026 Cloudflare ships Flagship. AWS has had AppConfig Feature Flags for years, though it is rarely the first choice for teams. Netlify, Fastly, and the rest will not be far behind.

The category is following the well-worn path of every "specialized SaaS" that became a commodity:

Early: a hard problem, solved by specialists who charge enterprise prices. (LaunchDarkly, Split.)
Middle: cheaper independent alternatives appear, pricing becomes transparent. (Flagsmith, ConfigCat, GrowthBook, Rollgate.)
Late: hyperscalers ship native versions as platform primitives, differentiated by proximity to the runtime rather than by flag logic itself. (Flagship, Edge Config, AppConfig.)

Feature flags are not going away. The opposite — more people and more code will use them than ever, especially as AI-generated code pushes the industry toward more aggressive rollout and rollback strategies. What is changing is the shape of the market: the "feature flags as a $100K/year enterprise SaaS" tier is being squeezed from below by commoditized platform options, and from the side by cheaper independents.

Where Independent Platforms Still Fit

"Commoditized" does not mean "solved." There are real categories of team for which neither Flagship nor its equivalents will be the right answer, and they are not small.

Multi-runtime and multi-cloud teams

A meaningful share of real production systems span at least two of: a Go/Python/Java backend, a React/Vue/Angular frontend, a mobile app (Flutter or React Native), and sometimes a .NET service. None of those are Workers. For these teams, the natural choice is a platform with SDKs in every language they actually use, not one optimized for a specific runtime.

This is the explicit positioning of most independent platforms: portability across stacks, not deep integration with one. As long as heterogeneous stacks are the norm — which, in my experience, they still are — this niche is durable.

Predictable, transparent pricing

Enterprise feature flag tools typically price per Monthly Active User (MAU), which is a metric that scales with product success rather than with flag complexity. A viral signup spike can turn your flag bill into a six-figure line item without you changing a single flag. Flat-tier or per-request pricing is much easier to reason about for teams with actual budgets (see pricing comparison).

We do not yet know how Flagship will price. If it is priced as a Workers primitive (cheap, request-based), it will put serious downward pressure on the market. If it is priced like a product-ized SaaS, the independent-alternative case stays strong.

Vendor neutrality as a governance stance

For some organizations — public sector, regulated industries, companies with explicit multi-cloud mandates — being locked into a single cloud for a primitive like feature flags is not just an engineering trade-off but a compliance or procurement one. Independent, self-hostable, or cloud-agnostic flag platforms will continue to have a captive audience here regardless of what Cloudflare, Vercel, or AWS ship.

Feature depth

Feature flags start as booleans and quickly become a platform: targeting rules, A/B testing, audit logs, scheduled releases, approvals, environment promotion, cohort analysis. The hyperscaler-primitive versions tend to start narrow and deep-integrated; the independent platforms have been building the surrounding product surface for years. That gap will close over time, but it exists today.

What This Means If You Are Choosing Today

If you are evaluating feature flag platforms in 2026, the decision tree is actually clearer now than it was a year ago:

You run fully on Cloudflare Workers and value the deep integration more than portability → Flagship (when it exits beta).
You run fully on Vercel → Edge Config for cheap cases, a full-featured vendor for complex flag logic.
You run on AWS and are already using AppConfig → extend AppConfig for basic cases.
Your stack spans clouds, languages, or includes mobile → an independent, multi-SDK platform is the natural fit.
You need enterprise governance (SSO, audit, approvals) and flat pricing → an independent platform with an enterprise tier.
You have a LaunchDarkly bill you cannot justify → a cheaper independent alternative will almost certainly do the job.

The honest read is that Flagship does not kill the feature flag category; it clarifies it. Cloudflare-native teams have a strong new option. Everyone else has the same options they had yesterday — just with the quiet reassurance that the category matters enough for a $50B infrastructure company to build a native version of it.

A Note From Someone Building In This Space

I will be transparent: I read Cloudflare's announcement and my first reaction was a nervous one. Building an independent product in a category that a hyperscaler just entered is not a comfortable position. But the more I sat with it, the more I thought it was net-good.

Cloudflare shipping Flagship is the strongest possible signal that feature flags are not a niche dev-tool curiosity but essential infrastructure. More developers will learn what they are. More teams will adopt them. The total addressable market grows. Some of those teams will fit Flagship; most will not. The interesting platforms — the ones that will still matter in five years — are the ones that pick a defensible position inside this expanding market, not the ones that try to beat Cloudflare on Cloudflare's home turf.

For Rollgate, the position has been the same since I started: portable across every runtime developers actually ship to, priced flat instead of per-MAU, and opinionated about the product surface around the flag itself (targeting, rollouts, scheduling, audit). Flagship does not change that position. If anything, it sharpens it.

If you are thinking about how feature flags fit into your stack in 2026, you now have more good options than you did last month. That is a good thing — even for those of us who have to compete with one of them.

Want to see how an independent, multi-runtime feature flag platform works? Rollgate has SDKs for Node.js, Go, Python, Java, .NET, Flutter, React, Vue, Angular, Svelte, React Native, and the browser, with flat pricing and a generous free tier. Create a free account or read the docs.

Feature Flags in Node.js: Express and Fastify Guide

Domenico Giordano — Wed, 22 Apr 2026 20:29:56 +0000

This was originally published on rollgate.io/blog/feature-flags-nodejs.

Why Feature Flags in Node.js?

Node.js powers a huge slice of production backends — REST APIs, GraphQL gateways, background workers, BFF layers, real-time services. All of them share the same release problem: you want to ship code continuously, but you do not want every deploy to be a product change.

Feature flags in Node.js decouple deployment from release. You push code to production behind a flag and decide later who sees the new behavior, when, and under what conditions. If something breaks, you flip the flag off in the dashboard — no redeploy, no rollback PR, no pager at 3am.

This guide covers the practical side: how to wire feature flags into Express and Fastify applications, how to target specific users, how to roll out gradually, and the production gotchas that every team hits sooner or later.

Quick Start: Feature Flags in Node.js

Let us get a flag running end-to-end. Install the SDK:

npm install @rollgate/sdk-node

Then wire it up:

import { RollgateClient } from '@rollgate/sdk-node';

const rollgate = new RollgateClient({
  apiKey: process.env.ROLLGATE_API_KEY!,
  enableStreaming: true, // real-time updates over SSE
});

await rollgate.init();

if (rollgate.isEnabled('new-checkout', false)) {
  console.log('New checkout flow enabled');
} else {
  console.log('Legacy checkout');
}

That is the whole setup. The SDK pulls rules from the API, caches them in memory, and keeps them fresh in the background. With enableStreaming: true the client keeps a Server-Sent Events connection open and applies changes within ~50ms of a flag flip. The second argument to isEnabled is the default value returned if the client is not yet initialized or the flag does not exist.

Evaluation is local, in-process. No network hop per flag check — the rules are already in memory, so you can evaluate thousands of flags per request without adding latency to the hot path.

The DIY Approach (and Its Limitations)

Before reaching for a dedicated platform, most teams start with environment variables:

const flags = {
  newCheckout: process.env.NEW_CHECKOUT === 'true',
  darkMode: process.env.DARK_MODE === 'true',
};

if (flags.newCheckout) {
  // ...
}

This works, for exactly one week. Then you hit the limitations:

Every flag change requires a redeploy — the whole point of flags is to avoid that
No gradual rollouts — it is all-or-nothing for every user
No targeting — you cannot enable a feature for beta testers, enterprise plans, or a specific region
No kill switch — if the new code breaks, rolling back means another deploy cycle
No audit trail — you do not know who flipped what, when, or why

The next evolution is usually a config file or a database table. You solve the redeploy problem but inherit a new one: keeping the config in sync across every instance of your Node.js service, and refreshing it without restarts. That is where a purpose-built feature flag platform earns its keep.

Using Rollgate with Express

Express is still the workhorse of the Node.js backend ecosystem. Here is a clean pattern: attach the Rollgate client to the request via middleware, then evaluate flags inside route handlers with the user context from the request.

import express from 'express';
import { RollgateClient } from '@rollgate/sdk-node';

const app = express();
const rollgate = new RollgateClient({
  apiKey: process.env.ROLLGATE_API_KEY!,
  enableStreaming: true,
});

await rollgate.init();

app.use((req, res, next) => {
  const userId = req.headers['x-user-id'] as string | undefined;
  req.flags = {
    isEnabled: (key: string, fallback = false) =>
      rollgate.isEnabled(key, fallback, userId ? { userId } : undefined),
  };
  next();
});

app.get('/checkout', (req, res) => {
  if (req.flags.isEnabled('new-checkout')) {
    return res.json({ version: 'v2', flow: 'stripe-elements' });
  }
  return res.json({ version: 'v1', flow: 'legacy-form' });
});

app.listen(3000);

The EvalContext you pass as the third argument lets you evaluate a flag for a specific user without mutating client-level state. Each request gets its own targeting evaluation based on userId and any attributes you forward (plan, region, role, anything your targeting rules reference).

Remember to shut the client down cleanly on SIGTERM so the SSE connection and telemetry buffers drain properly:

process.on('SIGTERM', async () => {
  await rollgate.close();
  process.exit(0);
});

Using Rollgate with Fastify

Fastify is the faster, more opinionated alternative. The pattern is the same — a plugin that decorates the request — but with Fastify's decorator API:

import Fastify from 'fastify';
import { RollgateClient } from '@rollgate/sdk-node';

const fastify = Fastify({ logger: true });
const rollgate = new RollgateClient({
  apiKey: process.env.ROLLGATE_API_KEY!,
  enableStreaming: true,
});

await rollgate.init();

fastify.decorateRequest('flags', null);

fastify.addHook('onRequest', async (request) => {
  const userId = request.headers['x-user-id'] as string | undefined;
  request.flags = {
    isEnabled: (key: string, fallback = false) =>
      rollgate.isEnabled(key, fallback, userId ? { userId } : undefined),
  };
});

fastify.get('/api/experiments', async (request) => {
  return {
    pricing: request.flags.isEnabled('new-pricing-ui'),
    search: request.flags.isEnabled('semantic-search'),
  };
});

fastify.addHook('onClose', async () => {
  await rollgate.close();
});

await fastify.listen({ port: 3000 });

One thing to watch: if you are running Fastify with logger: true and want the flag value in every log line, add it to the request context with request.log.child({ flags: [...] }) inside the onRequest hook. Observability on which flags evaluated for which request is the kind of detail that saves you hours in an incident.

Gradual Rollouts and User Targeting

Once flags are wired, the real value kicks in: turning a feature on for 1% of traffic, watching error rates for an hour, then bumping it to 10% the next day. Rollgate handles this with sticky, deterministic bucketing — the same user always lands in the same bucket, so a user who sees the new feature at 5% keeps seeing it when you move to 50%.

You do not need to change your Node.js code when you change the rollout percentage. The rules live in the dashboard; your SDK pulls the new rules and evaluates them locally.

const showNewFlow = rollgate.isEnabled('checkout-v2', false, {
  userId: user.id,
  attributes: {
    plan: user.plan,
    region: user.region,
    signupDate: user.signupDate,
  },
});

The attributes you pass feed into targeting rules. A common pattern for B2B SaaS: enable a feature for all plan = "enterprise" users plus 10% of plan = "pro" users, with no rollout for free-tier. That is three rules in the dashboard, zero code changes.

If you are using flags for experimentation rather than safe releases, pair them with event tracking. The Node SDK exposes client.track() for conversion events, which plugs into A/B testing workflows.

Production Considerations

A flag system sits in the hot path of every request. That changes how you think about it.

Caching and evaluation mode. The SDK evaluates locally by default — rules are cached in memory and refreshed via SSE or polling. There is no network call on each isEnabled(). In a Node.js process with a hot path that evaluates flags thousands of times per second, this matters: network-dependent flag checks would wreck your P99.

Resilience. The SDK ships with a circuit breaker, retry-with-backoff, and a stale cache fallback. If the Rollgate API becomes unreachable, your service keeps serving flag evaluations using the last known rules — it does not hard-fail. You can subscribe to circuit-open and flags-stale events to surface this in your own monitoring:

rollgate.on('circuit-open', () => {
  metrics.increment('rollgate.circuit.open');
});
rollgate.on('flags-stale', () => {
  metrics.increment('rollgate.flags.stale');
});

Kill switches in production. Wrap risky code paths — a new payment provider, a rewritten algorithm, an external API integration — in a flag you can flip instantly. When something breaks, you want the shortest possible path from "we are paging" to "traffic is back on the old code." A flag flip takes under a second; a rollback deploy takes tens of minutes.

Process lifecycle. Always call rollgate.close() on shutdown. It closes the SSE connection, flushes pending telemetry, and lets Kubernetes or your PaaS roll pods cleanly. Skipping this leaks file descriptors and loses the last batch of evaluation analytics.

One client per process, not per request. The SDK is thread-safe and reusable. Do not instantiate a new RollgateClient per request — you will hit the API hard, leak connections, and lose the benefit of local caching. One long-lived client at app start, shut down on SIGTERM.

Best Practices

Name flags by feature, not by team. new-checkout ages better than backend-team-q2-project. Future you will thank present you.
Always pass a sensible default. rollgate.isEnabled('feature', false) — false is usually the safe default (do not ship the new thing if we cannot decide). Explicit is better than surprising.
Retire flags. Once a rollout hits 100% and has been stable for a week, remove the flag from code. Zombie flags are a maintenance tax.
Log the evaluated value for high-stakes flags. If isEnabled('new-payment-provider') returned true for a user whose transaction failed, you want that in the log line, not inferred from the timestamp.
Separate experimentation flags from release flags. A kill switch for production should not expire when an experiment wraps up. Use different naming prefixes so they are easy to tell apart.

Next Steps

Feature flags in Node.js are a small change with an outsized impact. You stop shipping features and start shipping code, which means faster deploys, safer releases, and a rollback story that takes seconds instead of a pager rotation.

The Rollgate Node.js SDK is open source, 2KB gzipped, and works identically in Express, Fastify, Koa, NestJS, and any other Node.js framework. Local evaluation, SSE streaming, circuit breaker, and kill switches come in the box.

Read the full version with internal links to related guides on rollgate.io/blog/feature-flags-nodejs.