Forem: Domenico Giordano

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.

Feature Flags Pricing Comparison 2026: Stop Paying Per Seat

Domenico Giordano — Fri, 03 Apr 2026 12:55:17 +0000

I recently spent a weekend calculating the actual cost of feature flags across every major platform. The difference between the cheapest and most expensive option for the same workload? Over 100x. Here's the full breakdown so you don't have to do the math yourself.

The Enterprise Pricing Problem

Feature flags pricing has become absurdly complex. The core concept is simple — a conditional check that's controlled remotely — yet the industry has converged on pricing models that charge five or six figures per year for what is fundamentally a key-value store with targeting rules.

LaunchDarkly charges per Monthly Active User (MAU). Statsig charges per event. Optimizely bundles feature flags into a full experimentation platform you might not need. For a team of 10 developers with a growing product, the annual cost of feature flags can exceed what you pay for your entire cloud infrastructure.

This isn't sustainable. And the market is responding — new tools with transparent, predictable pricing are gaining traction precisely because developers are tired of "contact sales" being the only way to find out what something costs.

Feature Flags Pricing Models Explained

There are four main pricing models in the feature flags market:

Per Seat (Per Developer)

You pay for each team member who accesses the dashboard. Simple to understand, but it creates a perverse incentive: teams limit who can manage flags, which slows down the release process.

Who uses it: GrowthBook, some Flagsmith plans

Per MAU (Monthly Active Users)

You pay based on how many unique users evaluate flags in your application. This punishes success — the more users you acquire, the more you pay for feature flags, even if your flag usage stays constant.

Who uses it: LaunchDarkly, Statsig

Per Config Fetch / Event

You pay per API call or flag evaluation. More predictable than MAU, but can still surprise you if you increase polling frequency or add more clients.

Who uses it: ConfigCat (config fetches)

Flat Tier (Per Request Bands)

You pick a plan based on request volume. The price is fixed within each tier, so you know exactly what you'll pay. No surprises when you add users, team members, or flags.

Who uses it: Rollgate

Feature Flags Pricing Comparison Table

	Rollgate	LaunchDarkly	Flagsmith	ConfigCat	GrowthBook
Free tier	500K req/mo, 3 projects, unlimited flags	Limited trial	50K req/mo	10 flags	Free (self-hosted)
Entry plan	€39/mo (Starter)	~$700/mo (est.)	~$45/mo	~$84/mo	$99/mo
Mid plan	€99/mo (Pro)	Custom quote	~$125/mo	Custom	$199/mo
Enterprise	€299/mo (Growth)	$25K-150K/yr	Custom	Custom	Custom
Pricing unit	SDK requests	MAU	Requests + seats	Config fetches	Seats
Price scales with	API traffic	User growth	Traffic + team size	Polling frequency	Team size

Disclaimer: Competitor pricing changes frequently. The figures above are estimates based on publicly available information as of March 2026. Always check each vendor's pricing page for current rates.

What's Included at Each Rollgate Tier

Feature	Free	Starter (€39-45/mo)	Pro (€99-119/mo)	Growth (€299-349/mo)
SDK requests/mo	500K	1M	3M	12M
Flag evaluations/mo	5M	10M	30M	120M
Projects	3	5	10	Unlimited
Flags	Unlimited	Unlimited	Unlimited	Unlimited
Environments	3	5	Unlimited	Unlimited
Team members	3	5	15	50
SSE connections	1	25	100	500
Audit log retention	3 days	14 days	90 days	1 year
Scheduled changes	--	Yes	Yes	Yes
1-click rollback	--	Yes	Yes	Yes
RBAC	--	--	Yes	Yes
SLA	--	--	--	99.9%

The annual billing option saves roughly 15-18% on each paid plan.

The Real Cost: A 10-Developer Team with 2M Requests/Month

Let's make this concrete. Your team:

10 developers with dashboard access
50,000 Monthly Active Users
2 million SDK requests per month (polling every 30 seconds across web + mobile)
3 environments (dev, staging, production)
15 active feature flags

Rollgate: €99/month (Pro)

The Pro plan covers 3M requests/month, 10 projects, 15 team members, and unlimited flags. All environments included. Scheduled changes and rollback included.

Annual: €99 x 12 = €1,188/year (or €1,068 with annual billing)

LaunchDarkly: Estimated $8,000-12,000/month

LaunchDarkly prices by MAU. At 50K MAU, you're well past the starter tier. Enterprise contracts typically start at $25K/year for small teams and scale significantly with MAU growth. With 50K MAU, expect quotes in the $100K-150K/year range.

Annual: $96,000-$150,000/year (estimated, check their sales team for exact pricing)

Flagsmith: Estimated $125-250/month

Flagsmith's cloud pricing includes per-seat and per-request components. For 10 seats and 2M requests, expect mid-tier pricing.

Annual: ~$1,500-$3,000/year (estimated)

ConfigCat: Estimated $150-300/month

ConfigCat charges per config fetch. With 2M requests/month and 10 team members, you'll likely need a mid-to-high tier plan.

Annual: ~$1,800-$3,600/year (estimated)

GrowthBook: $199/month (Pro)

GrowthBook charges per seat. The Pro plan at $199/month covers up to 20 seats with premium features.

Annual: $2,388/year

Cost Summary

Tool	Estimated Annual Cost	Cost vs Rollgate
Rollgate	~€1,100/year	--
Flagsmith	~$1,500-3,000/year	1.4-2.7x
ConfigCat	~$1,800-3,600/year	1.6-3.3x
GrowthBook	~$2,400/year	2.2x
LaunchDarkly	~$96,000-150,000/year	87-136x

These are rough estimates for comparison purposes. Actual costs depend on your specific usage patterns, negotiated contracts, and plan selection. Rollgate's pricing is publicly listed; for other tools, check their websites or contact their sales teams.

The gap is largest with LaunchDarkly because MAU-based pricing fundamentally scales differently than request-based pricing. As your product grows from 50K to 500K users, your LaunchDarkly bill grows 10x. Your Rollgate bill stays the same — or moves one tier up if your request volume increases.

Why Request-Based Pricing Makes More Sense

MAU-based pricing charges you for users who might evaluate a flag once per session. Request-based pricing charges you for actual API usage. The difference matters because:

Your user count grows faster than your flag usage. When you go from 10K to 100K users, your feature flag evaluation patterns don't change 10x. You still have the same polling intervals, the same SDKs, the same flags. Your request volume grows, but not linearly with users — especially with local caching and SSE.

You can control request volume. Increase polling interval from 30s to 60s, and you cut requests in half. Enable SSE, and you eliminate most polling requests entirely. You can't control how many users sign up.

It's predictable. A polling client at 30s intervals generates approximately 86K requests per month. Multiply by your client count and you know your tier. With MAU pricing, a viral marketing campaign can triple your bill overnight.

Here's a typical integration — the SDK handles polling and caching automatically:

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

function App() {
  return (
    <RollgateProvider
      apiKey="rg_client_your_key"
      options={{
        pollingInterval: 30000, // 30s default
        enableSSE: true,        // real-time updates, reduces polling
      }}
    >
      <FeatureFlaggedApp />
    </RollgateProvider>
  );
}

function FeatureFlaggedApp() {
  const showNewUI = useFlag('redesigned-ui', false);
  const maxUploadSize = useFlag('max-upload-mb', 10);

  return (
    <div>
      {showNewUI ? <NewUI maxUpload={maxUploadSize} /> : <CurrentUI />}
    </div>
  );
}

One SDK connection, one polling interval, all flags cached locally. Whether you have 1,000 or 1,000,000 users, each client makes the same number of requests.

How to Calculate Your Feature Flags Cost

Before you commit to a tool, estimate your actual usage:

Count your SDK clients: How many servers, browser instances, or mobile apps will connect? Each one polls independently.
Determine your polling interval: Default is usually 30 seconds. At 30s, one client = ~86K requests/month. At 60s = ~43K. With SSE, polling is minimal.
Multiply: clients x requests_per_client = monthly_requests
Pick the tier that covers your volume.

Example: You have 3 API servers + 1 web frontend. With 30s polling, that's 4 x 86K = 344K requests/month. Rollgate Free (500K) covers this. You pay nothing.

Scaling example: Your product grows to 20 API servers + 5 frontend instances. That's 25 x 86K = 2.15M requests/month. Rollgate Pro (3M) at €99/month covers this. On LaunchDarkly, the cost would depend on how many end users those 20 servers handle — potentially tens of thousands of dollars per month.

Stop Overpaying for Feature Flags

Feature flags should be a line item, not a line of the budget. The core technology — flag evaluation, targeting rules, SDK communication — isn't complex enough to justify enterprise pricing for most teams.

Rollgate offers transparent, flat-tier pricing with no surprises. The free tier (500K requests/month) is generous enough for small teams and side projects. Paid plans start at €39/month and include scheduled releases and instant rollback.

Check the full pricing at rollgate.io or try the live demo.

For more context on choosing a feature flag tool, see our LaunchDarkly alternative comparison and gradual rollout strategies.

I'm building Rollgate, a feature flag platform for developers. If you have questions about feature flags, drop them in the comments — happy to help!

Feature Flags vs Feature Branches: When to Use Each

Domenico Giordano — Fri, 03 Apr 2026 12:55:16 +0000

I used to think feature branches were the only way to manage releases. Then I joined a team that used feature flags with trunk-based development, and I never looked back. Turns out, the "feature flags vs feature branches" debate is a false dichotomy — here's how to think about it.

The False Dichotomy

Developers often frame feature flags vs feature branches as an either/or choice. In reality, they solve different problems and work best together. Feature branches manage code integration. Feature flags manage feature release. Understanding this distinction is key to a healthy deployment workflow.

Whether you call them feature flags, feature toggles, or feature switches, the core idea is the same: decouple deployment from release. And whether you use Git Flow, GitHub Flow, or trunk-based development, branches are about managing code changes. Once you internalize that these tools operate at different layers, the "feature branch vs feature toggle" debate dissolves.

Feature Flags vs Feature Toggles: Are They the Same?

Before we go deeper, let's clear up a common source of confusion. You'll see "feature flags," "feature toggles," "feature switches," and "feature gates" used across blog posts, documentation, and conference talks. They all refer to the same concept: a conditional check in your code that controls whether a piece of functionality is active.

Martin Fowler popularized the term "feature toggle" in his 2010 article. The term "feature flag" gained traction in the DevOps community and is more common today, especially in SaaS tooling. Some teams use "toggle" for simple on/off switches and "flag" when targeting rules and percentage rollouts are involved, but this distinction isn't universal.

Throughout this article, we use "feature flag" and "feature toggle" interchangeably. If you've been searching for "feature branch vs feature toggle," you're in the right place.

For a complete introduction to the concept, see our guide on what feature flags are and how they work.

What Are Feature Branches?

Feature branches are a Git workflow where each new feature is developed on a separate branch. When the feature is ready, the branch is merged into the main branch (usually main or develop).

git checkout -b feature/new-payment-flow
# ... work on the feature ...
git push origin feature/new-payment-flow
# Create a pull request, get reviews, merge

Advantages of Feature Branches

Isolation: Changes are isolated until the branch is merged
Code review: Pull requests enable structured review
CI checks: Automated tests run on each branch before merging
Familiar: Every developer knows Git branching

Problems with Feature Branches

Long-lived branches diverge: The longer a branch lives, the harder the merge. Conflicts accumulate, and integration becomes painful.
Delayed feedback: You don't know if your feature works in production until it's merged and deployed.
All-or-nothing releases: Merging a feature branch means releasing it. There's no way to deploy the code but hide the feature.
Merge conflicts: Large branches touching many files create merge hell, especially on active codebases.

The Hidden Cost of Long-Lived Feature Branches

The problems above aren't theoretical. Long-lived feature branches impose real, measurable costs on engineering teams.

Merge Conflict Escalation

Research from DORA (DevOps Research and Assessment) consistently shows that teams practicing trunk-based development with short-lived branches ship faster and with fewer failures. The reason is compounding: every day a branch stays open, the probability of a merge conflict increases non-linearly. A branch open for 2 days might have a 10% chance of conflict. At 2 weeks, that number can exceed 80%, depending on team size and codebase activity.

Context Switching Tax

When a developer opens a PR for a 3-week-old branch and receives 47 review comments, the original context is gone. The developer has moved on to other work. Rebuilding mental context to address feedback on stale code is one of the most expensive activities in software development. Studies suggest context switching can cost 20-25 minutes per interruption.

Integration Risk Compounds

Consider a team of 6 developers, each working on a separate feature branch for 2 weeks. When all six branches merge in the same sprint, the integration surface is enormous. Features that worked in isolation break when combined. This "merge day" anti-pattern is why many teams dread release weeks.

Delayed Bug Discovery

A bug introduced on a feature branch stays hidden until merge. If your branch diverged from main 10 days ago, the bug has had 10 days to become entangled with other changes. Compare this to trunk-based development where the same bug would surface within hours, when it's cheap to fix and the context is fresh.

The alternative is clear: keep branches short (hours to days, not weeks) and use feature flags for long-running features that span multiple merges.

What Are Feature Flags?

Feature flags wrap new functionality in a conditional check. The code is deployed to production but only activated when the flag is enabled. This decouples deployment from release.

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

function PaymentPage({ user }) {
  const showNewPayment = useFlag('new-payment-flow');

  if (showNewPayment) {
    return <NewPaymentFlow />;
  }
  return <CurrentPaymentFlow />;
}

On the backend, the same pattern works in any language. Here's Go:

package main

import (
    "net/http"
    rollgate "github.com/rollgate/sdk-go"
)

func paymentHandler(w http.ResponseWriter, r *http.Request) {
    user := getUserFromContext(r)
    ctx := rollgate.NewContext(rollgate.WithUserID(user.ID))

    if rollgate.IsEnabled("new-payment-flow", ctx) {
        handleNewPaymentFlow(w, r)
        return
    }
    handleCurrentPaymentFlow(w, r)
}

Advantages of Feature Flags

Deploy anytime: Code goes to production even if the feature isn't ready for users
Gradual rollout: Enable for 1% of users, then 10%, then 100% — learn more in our gradual rollouts guide
Instant rollback: Disable a flag in seconds, no redeployment needed
Targeting: Show features to specific users, teams, or segments
Trunk-based development: Everyone commits to main, reducing merge conflicts
Scheduled releases: Combine flags with time-based rules for scheduled feature releases

Problems with Feature Flags

Code complexity: Two code paths mean more logic to maintain
Stale flags: Unused flags accumulate as technical debt
Testing surface: You need to test both flag states
Requires discipline: Flags need to be cleaned up after full rollout

How Companies Like Google and Netflix Use Trunk-Based Development

Trunk-based development with feature flags isn't a niche practice. It's how the world's most productive engineering organizations ship software.

Google

Google operates one of the largest monorepos in existence, with over 80,000 engineers committing to a single repository. Long-lived feature branches would be impossible at this scale. Instead, Google uses trunk-based development where all engineers commit to head. Incomplete features are guarded by flags (internally called "experiments" or "flags") that keep them invisible until ready. This approach allows Google to make over 60,000 commits per day without breaking the build.

Netflix

Netflix deploys hundreds of times per day across its microservices architecture. Their engineering blog describes how every feature is wrapped in a flag before reaching production. This allows them to test new recommendation algorithms, UI changes, and encoding pipelines with real traffic at controlled percentages. When a new video player feature caused buffering issues in 2019, they disabled it for all users in under 30 seconds — something a rollback deployment would have taken minutes or longer.

Meta (Facebook)

Meta ships code to production twice daily using a system called Gatekeeper, their internal feature flag platform. Every new feature — from News Feed ranking changes to Messenger updates — goes through a flag-controlled rollout. Engineers can target by geography, device type, employee status, or custom segments. This system handles billions of flag evaluations per day.

Spotify

Spotify uses feature flags extensively for their "controlled rollout" process. New features are first exposed to internal employees ("dogfooding"), then to a small percentage of users in a single market, then expanded globally. This layered approach catches issues at each stage before they reach the full 500+ million user base.

The pattern is consistent across these organizations: short-lived branches for code management, feature flags for release management.

When to Use Feature Branches

Feature branches are the right choice when:

Short-lived work (1-3 days): Bug fixes, small features, refactors that can be reviewed and merged quickly
Code review is essential: You want a structured PR workflow with approvals
No production risk: The change doesn't need gradual rollout or targeting
Open-source contributions: External contributors need isolated branches for PRs

When to Use Feature Flags

Feature flags are the right choice when:

Gradual rollout needed: You want to release to a percentage of users first
Long-running features: Work that spans multiple sprints or weeks
Production testing: You need to verify behavior in production before full release
Kill switch required: The feature could impact system stability
User targeting: Different users should see different experiences
A/B testing: You're running experiments between variants

The Best Approach: Use Both

The most effective teams use short-lived feature branches combined with feature flags:

Create a short-lived branch for a small piece of work (1-2 days)
Wrap new UI or behavior behind a feature flag
Merge to main quickly — the flag is off, so nothing changes for users
Deploy to production — the code is there but hidden
Enable the flag gradually when the full feature is ready
Clean up the flag once the feature is at 100%

This gives you the best of both worlds:

Short branches avoid merge conflicts and integration pain
Feature flags give you release control without deployment pressure
Trunk-based development keeps the main branch always deployable
Continuous delivery becomes natural, not scary

Trunk-Based Development with Feature Flags

Trunk-based development (TBD) is the practice of keeping branches short (hours to days) and merging to main frequently. Feature flags are what make TBD safe for large features:

Day 1: Merge backend API behind flag -> Deploy -> Flag off
Day 2: Merge UI component behind flag -> Deploy -> Flag off
Day 3: Merge integration tests -> Deploy -> Flag off
Day 4: Enable flag for internal team -> Test in production
Day 5: Rollout to 10% -> Monitor metrics
Day 7: Rollout to 100% -> Remove flag

Each merge is small, easy to review, and safe to deploy. The feature grows incrementally in production without affecting users until you decide it's ready.

Here's a concrete Node.js example of a flag-guarded API endpoint that you can merge to main safely on Day 1:

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

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

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

  if (useNewCheckout) {
    return handleNewCheckout(req, res);
  }
  return handleLegacyCheckout(req, res);
});

Migration Guide: From Feature Branches to Feature Flags

If your team currently relies on long-lived feature branches, migrating to a flag-based workflow doesn't have to happen overnight. Here's a practical step-by-step approach.

Step 1: Pick One Feature as a Pilot

Don't try to convert your entire workflow at once. Choose a medium-complexity feature that's about to start development. This gives you a real scenario to learn from without risking critical work.

Step 2: Set Up Your Flag Service

You need a way to create and manage flags. You can start with environment variables or a config file, but a dedicated service like Rollgate gives you a dashboard, targeting rules, and audit logs from day one.

Step 3: Adopt the Branch + Flag Pattern

Instead of a single long-lived feature/new-dashboard branch, break the work into small PRs (each 1-2 days):

# PR 1: Add the flag and the empty shell
git checkout -b add-dashboard-flag
# Create the flag in Rollgate, add the conditional check
# Merge to main -- flag is OFF, no user impact

# PR 2: Build the data layer
git checkout -b dashboard-data-layer
# Add API endpoints behind the flag
# Merge to main -- still invisible to users

# PR 3: Build the UI
git checkout -b dashboard-ui
# Add components behind the flag
# Merge to main -- still invisible

# Ready? Enable the flag for your team first, then gradually roll out.

Step 4: Establish Flag Hygiene Rules

Agree on team conventions before flags accumulate:

Naming: Use a consistent pattern like feature.dashboard-v2 or release.new-checkout
Ownership: Every flag has an owner responsible for cleanup
TTL: Set an expected removal date when creating the flag
Cleanup sprint: Dedicate time each sprint to removing fully-rolled-out flags

Step 5: Expand to the Full Team

Once the pilot is complete, share lessons learned and repeat the pattern. Most teams report that within 2-3 sprints, the flag-based workflow feels natural and the benefits are obvious: fewer merge conflicts, faster releases, and fewer incidents.

Real-World Comparison

Aspect	Feature Branches Only	Feature Branches + Flags
Branch lifetime	Days to weeks	Hours to days
Merge conflicts	Frequent	Rare
Release control	None (merge = release)	Full (gradual, targeted)
Rollback speed	Minutes (redeploy)	Seconds (toggle flag)
Production testing	Not possible	Easy
A/B testing	Not possible	Built-in

FAQ

Can I use feature flags without a feature flag service?

Yes. The simplest feature flag is an if statement checking an environment variable:

if (process.env.ENABLE_NEW_DASHBOARD === 'true') {
  showNewDashboard();
}

This works for basic use cases, but it has limitations. Changing a flag requires redeployment, there's no gradual rollout, no user targeting, and no audit trail. As your team grows and you manage more flags, a dedicated service pays for itself in reduced deployment risk and developer time. Most teams start with env vars and upgrade to a flag service once they hit 5-10 flags.

Do feature flags slow down my application?

A well-implemented feature flag adds negligible overhead. The flag evaluation itself is a simple conditional check — microseconds at most. Modern SDKs cache flag values locally and sync in the background, so evaluations don't make network requests on the hot path.

In Go, a cached flag evaluation looks like this:

// This reads from local cache -- no network call
enabled := rollgate.IsEnabled("new-feature", ctx)
// Typical evaluation time: <1 microsecond

The performance concern is valid only if your implementation makes a remote API call on every evaluation — which no production-grade SDK does.

How do I handle database migrations with feature flags?

Database migrations are one of the trickier aspects of flag-based development. The key principle is: your database schema must support both code paths simultaneously.

Here's a practical approach:

Additive migrations only: Add new columns or tables, never remove or rename existing ones while the flag is active
Dual-write pattern: When the flag is on, write data to both the old and new schema. When off, write only to the old schema
Backfill after full rollout: Once the flag is at 100% and removed, run a migration to clean up the old schema

async function saveOrder(order: Order) {
  // Always write to the existing table
  await db.orders.insert(order);

  // When the flag is on, also write to the new normalized tables
  if (await rollgate.isEnabled('normalized-orders')) {
    await db.orderHeaders.insert(order.header);
    await db.orderLines.insertMany(order.lines);
  }
}

This approach avoids the scenario where you roll back a flag and lose access to data written in a new format. Both code paths can read from the same source during the transition.

Conclusion

Feature branches and feature flags aren't competing approaches — they're complementary tools. Use feature branches for code management and review. Use feature flags for release management and safety. Together, they enable fast, safe, continuous delivery.

If you're still doing long-lived feature branches with big-bang releases, consider adding feature flags to your workflow. Start with one flag on your next feature and experience the difference. The teams at Google, Netflix, and Spotify didn't adopt this pattern because it was trendy — they adopted it because it works.

Get started with Rollgate — free tier, no credit card required.

I'm building Rollgate, a feature flag platform for developers. If you have questions about feature flags, drop them in the comments — happy to help!

How I Built a Feature Flags SaaS as a Solo Developer

Domenico Giordano — Fri, 03 Apr 2026 12:55:15 +0000

I spent a year building a feature flags SaaS from scratch. No co-founder, no VC, just me, Go, and a Hetzner VPS. This post covers the full technical journey — the stack I chose, the features I built, the mistakes I made, and the real numbers behind a solo SaaS. If you're thinking about building your own developer tool, I hope this helps.

How I Built Rollgate: From Side Project to Feature Flags SaaS

Over the past year, I built Rollgate, a SaaS platform for feature flag management. The goal was simple: offer the same capabilities as LaunchDarkly — gradual rollouts, user targeting, A/B testing, kill switches — without the $70k/year enterprise price tag.

In this article, I share the technical journey: architectural decisions, all the features I implemented, mistakes made, and the real numbers behind a SaaS built by a single developer.

The Problem

Anyone who has worked in a development team knows the situation: you want to release a feature, but you're not sure it works for all users. Traditional deployment is a binary event — either the feature is live for everyone, or for no one.

Feature flags solve this by separating deployment from release. You can deploy code to production and enable it gradually: first 1% of users, then 5%, then 25%, and so on. If something goes wrong, you turn off the flag in a second — no rollback, no hotfix, no downtime.

Tools like LaunchDarkly do exactly this, but cost $25k to $150k per year. For a startup or mid-size team, that's prohibitive. I thought: can I build something equivalent and offer it at a fraction of the price?

Choosing the Tech Stack

The first fundamental decision was the stack. I had two non-negotiable requirements: low latency (feature flags are evaluated on every request) and operational simplicity (fewer moving parts means fewer things to break).

Backend: Go

I chose Go for the backend API for three reasons:

Performance — A flag evaluation must happen in microseconds. Go compiles to native binary, has no significant GC pauses, and handles thousands of concurrent connections with goroutines.
Simple deployment — A single static binary. No runtime, no dependencies. The final Docker image weighs 20MB.
Excellent stdlib — HTTP server, JSON encoding, crypto, testing — all built-in. Fewer external dependencies means less surface area for bugs.

The router is Chi, lightweight and net/http-compatible. No heavy frameworks — I prefer composition over convention.

Frontend: Next.js

For the dashboard, I chose Next.js with React and Tailwind CSS. It provides SSR/SSG for marketing pages (SEO), API routes for backend proxying, and a smooth dev experience.

Database: PostgreSQL + Redis

PostgreSQL for persistence: JSONB for flag metadata, partial indexes, LISTEN/NOTIFY for cache invalidation. 29 tables, 67 indexes, 29 foreign keys.

Redis as cache layer for flag evaluations. When an SDK asks "is flag X enabled for user Y?", Redis serves the answer in milliseconds, updated in real-time via pub/sub.

Rollgate's Feature Set

Rollgate isn't a simple toggle on/off. I implemented a complete set of features covering the entire software release lifecycle.

Feature Flags with Multiple Types

Flags support four value types:

Boolean — Classic on/off. Perfect for kill switches and feature toggles.
String — Returns text. Ideal for A/B testing ("variant-a", "variant-b") or dynamic messages.
Number — Returns a numeric value. Useful for configuring limits, percentages, or algorithm parameters.
JSON — Returns a structured object. For complex configurations like layouts, plan-specific feature sets, or business rules.

Gradual Rollouts

Percentage rollout enables a flag for a specific percentage of users. Distribution uses consistent hashing (MurmurHash3) on the user ID, so the same user always gets the same result without saving state:

hash = MurmurHash3(flagKey + userId) % 10000
isEnabled = hash < rolloutPercentage * 100

Precision to 0.01%. You can go from 1% to 5% to 25% to 100% gradually, monitoring metrics at each step.

User Targeting and Segments

Targeting enables flags for specific user groups based on attributes:

User attributes — Email, plan, country, app version, any custom attribute
Operators — equals, contains, startsWith, endsWith, regex, in, greaterThan, lessThan
Reusable segments — Define "Beta Users" or "Enterprise Customers" once, use in all flags
Combined rules — AND/OR logic across multiple conditions

Kill Switches

The kill switch is the most critical production feature. When something goes wrong — a bug, a performance issue, a third-party integration down — you need to disable a feature instantly.

In Rollgate, every flag has a toggle that takes effect in seconds via real-time SSE propagation. No deploy needed, no server access required, you don't even need to be a developer. A product manager can kill a feature from the dashboard on their phone.

I've seen enterprise teams take 30-45 minutes for a traditional rollback (revert commit, CI, deploy, verify). With a kill switch, it's 2 seconds. During a production incident, those 30 minutes can cost thousands in lost revenue.

Scheduled Changes

Scheduled changes let you program flag modifications for a specific date and time:

Coordinated launch — "Enable the new feature Friday at 2 PM when marketing publishes the blog post"
Temporary promotions — "Enable the Black Friday banner from Friday to Monday"
Automatic progressive rollout — "1% Monday, 10% Wednesday, 50% Friday, 100% next Monday"
Feature sunset — "Disable the old API on April 1st"

Each scheduled change appears in the flag's timeline with pending/executed/cancelled status. A server-side cron job checks every minute for changes to apply.

Instant Rollback

Every flag modification is saved in history with timestamp, author, and complete state snapshot. Rollback restores the exact flag state at a previous point — not just the value, but also targeting rules, percentages, and scheduled changes.

It's different from a simple "undo": you can go back 5 changes, or to a specific dated version. The audit log tracks who did what and when.

A/B Testing

String variant flags enable native A/B testing. Instead of simple true/false, the flag returns a variant ("control", "variant-a", "variant-b") with configurable percentage distribution.

Evaluation tracking records which variant was served to each user, with timestamp and context. This allows correlating variants with business metrics in your preferred analytics tool.

I deliberately didn't build an integrated statistical engine — I prefer teams use their existing analytics tools rather than creating another data silo.

Multi-Environment

Every project has separate environments: development, staging, production (and as many as you want). Flags are independent per environment — you can have a flag active in staging but off in production.

Each environment has its own API keys (server and client), targeting rules, and history. This prevents the classic "oops, I modified the production flag thinking it was staging" mistake.

Audit Log

Every platform action is recorded in an immutable audit log: who created/modified/deleted a flag, what changed (before/after diff), when (precise timestamp), from which IP and user agent.

Retention varies by plan: 3 days (Free), 14 days (Starter), 90 days (Pro), 1 year (Growth). For compliance and debugging, having a complete trace is essential.

Webhooks

Webhooks notify external systems when a flag changes. Every create, update, or delete sends an HTTP POST to configured URLs with the full event payload.

Use cases: notify Slack when a production flag changes, trigger a deploy, update monitoring, sync with project management tools. Webhooks have automatic retry with exponential backoff and delivery logging.

Analytics and Usage Tracking

Rollgate tracks flag evaluations in real-time: how many times evaluated, unique users, true/false distribution, trends over time. Usage limits are per plan: 500K requests/month (Free), 1M (Starter), 3M (Pro), 12M (Growth).

13 SDKs

I built 13 SDKs covering all major languages and frameworks:

JavaScript/TypeScript — sdk-core, sdk-node, sdk-browser, sdk-react, sdk-vue, sdk-angular, sdk-svelte
Mobile — sdk-react-native, sdk-flutter
Backend — sdk-go, sdk-java, sdk-python, sdk-dotnet

All SDKs share the same features: local cache, circuit breaker, retry with backoff, event buffering, and real-time SSE updates. If the server is down, SDKs continue working with cached values.

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

function App() {
  return (
    <RollgateProvider apiKey="rg_client_your_key">
      <Dashboard />
    </RollgateProvider>
  );
}

function Dashboard() {
  const showNewFeature = useFlag('new-dashboard', false);

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

System Architecture

Client SDK -> API Server (Go) -> Redis Cache -> PostgreSQL
              ^
          SSE Connection (real-time updates)

Flag evaluation happens in ~200us. P99 latency is under one millisecond. The system supports tens of thousands of simultaneous SSE connections.

Technical Challenges

Race Conditions on Updates

When multiple users modify the same flag simultaneously, I use optimistic locking with a version counter. If someone else modified the flag in the meantime, the operation returns 409 Conflict.

Circuit Breaker in SDKs

If the API server is down, SDKs must not crash the host app. The circuit breaker has three states (Closed, Open, Half-Open) with exponential retry and request deduplication.

SEO for a SaaS App

I separated marketing and dashboard with a domain split: rollgate.io for SEO pages (Server Components) and app.rollgate.io for the authenticated dashboard.

Resilience and Monitoring

Daily backups — PostgreSQL dump every night to a geographically separate server
Monitoring — Prometheus + Grafana + Alertmanager with real-time alerts
Health checks — Automated verification of API, Web, DB, Redis every 60 seconds
Disaster recovery — Automated script rebuilds the entire stack in ~20 minutes
SDK resilience — Local cache + circuit breaker = works even offline

The Numbers

Metric	Value
Go files (non-test)	147
TypeScript/TSX files	168
API endpoints	114
DB tables	29
Total tests	~850
Published SDKs	13
Codebase score	7.86/10

What I Learned

1. Simplicity Wins

Kubernetes in production? No, Docker Compose is enough. Microservices? No, a modular monolith is simpler. Every added complexity has a maintenance cost that must justify its weight.

2. Tests Save Lives

With ~850 tests, I can refactor with confidence. CI runs everything on every PR and blocks deployment if something fails.

3. Billing Is Harder Than the Product

Paddle for payments was surprisingly complex: webhooks, subscription lifecycle, prorating, dunning, tax handling. Use a payment provider that handles everything (Paddle, Lemon Squeezy) rather than raw Stripe.

4. SEO Requires Constant Attention

If Google doesn't index you, nobody will find you. I spent weeks on SSR, JSON-LD, sitemaps, meta tags. It never ends.

5. Building Solo Is Sustainable (With Limits)

Code is the easy part — finding users is the real challenge. Marketing, support, and growth require different skills.

The Market: Competitors and Positioning

The feature flags market is dominated by a few players with aggressive enterprise pricing:

Platform	Pricing	Strengths	Limitations
LaunchDarkly	From $833/mo	Market leader, enterprise-ready, vast integrations	Prohibitive for startups, excessive complexity
Flagsmith	From $45/mo	Free self-hosted, API-first	Less polished UI, fewer SDKs
Unleash	From $80/mo	Mature self-hosted, good docs	Complex setup, dated UI
PostHog	Usage-based	Complete suite (analytics + flags), open-source	Flags aren't the focus, overhead
Rollgate	Free -> €45/mo	Accessible pricing, 13 SDKs, 5-min setup	New to market, growing community

Choosing the Pricing Model

Pricing was one of the hardest decisions. I studied every competitor and identified three approaches:

Per-seat (LaunchDarkly) — Scales with team size, penalizes large companies. $70k/year for 50 developers isn't unusual.
Usage-based (PostHog) — Scales with traffic, unpredictable for budgeting. Can explode with traffic spikes.
Fixed tiers (Rollgate) — Predictable pricing, scales by features and limits. Customers know exactly what they pay.

I chose fixed tiers because cost predictability is essential for startups and SMBs. The four plans:

Plan	Monthly	Annually	Requests/mo	Team	Target
Free	€0	€0	500K	3 members	Side projects, MVPs
Starter	€45/mo	€39/mo	1M	5 members	Early-stage startups
Pro	€119/mo	€99/mo	3M	15 members	Growing teams
Growth	€349/mo	€299/mo	12M	50 members	Scale-ups, high traffic

The free tier is generous by design: 500K requests/month is enough for an app with thousands of active users. The goal is to lower the entry barrier — if a developer tries Rollgate and it works, upgrading to Starter as the project grows is natural.

Why Not Open Source?

I evaluated the open-core model (free core, paid enterprise features), but it requires an active community to work. For a solo project, the risk is giving everything away for free without monetizing. I opted for a SaaS model with a generous free tier, with plans to release a self-hosted version under BSL (Business Source License) — the same approach used by HashiCorp and Sentry.

What's Next

Rollgate is live at rollgate.io with a generous free tier (500K requests/month). Next up: advanced A/B testing with auto-winner, teams with SSO, self-hosted version, and complete OpenAPI spec.

If you're interested in the project or have questions about building a SaaS solo, I'd love to hear from you in the comments.

I'm building Rollgate, a feature flag platform for developers. If you have questions about feature flags, drop them in the comments — happy to help!

The Best LaunchDarkly Alternative in 2026: Rollgate vs the Rest

Domenico Giordano — Fri, 03 Apr 2026 12:55:14 +0000

Let's be real: LaunchDarkly is a great product, but the pricing is wild. I was paying more for feature flags than for my entire cloud infrastructure. So I started looking at alternatives, and eventually built one. Here's an honest comparison of what's out there in 2026.

Why Teams Are Looking for a LaunchDarkly Alternative

If you're searching for a LaunchDarkly alternative, you're not alone. LaunchDarkly is the category leader in feature flags, but it's also the most expensive option by a wide margin. Enterprise contracts typically range from $25,000 to $150,000 per year, and pricing scales with Monthly Active Users (MAU) — a metric that punishes success. The more users you have, the more you pay, even if your feature flag usage stays the same.

For teams with 10 developers and a growing product, the math doesn't work. You're paying enterprise pricing for what is fundamentally a configuration service: a key-value store with targeting rules and an SDK.

That's why more teams are evaluating alternatives to LaunchDarkly that offer the same core capabilities — feature flags, targeting, rollback — without the unpredictable pricing model.

What to Look for in a LaunchDarkly Alternative

Not all feature flag tools are created equal. Before you switch, make sure the alternative checks these boxes:

Transparent, Predictable Pricing

No "contact sales" as the only option. No MAU-based pricing that explodes when your product grows. You should know exactly what you'll pay before you sign up. For a deeper breakdown of how different vendors charge, see our feature flags pricing comparison.

Multi-Platform SDK Support

Your stack isn't just React. You need SDKs for your backend (Node.js, Go, Python, Java), your frontend (React, Vue, Angular, Svelte), and your mobile apps (React Native, Flutter). The SDKs should include circuit breakers, retry logic, and local caching out of the box.

Scheduled Releases

The ability to schedule a flag change for a specific date and time — without writing cron jobs or staying awake at 3am. This is a feature that LaunchDarkly offers only on higher tiers, and many alternatives don't offer at all.

Instant Rollback

When something breaks in production, you need to revert a flag to its previous state in one click. Not "create a new flag version," not "redeploy" — one click, instant rollback to the exact previous state.

GDPR Compliance with EU Data Residency

If you serve European users, your feature flag data should stay in Europe. LaunchDarkly's infrastructure is primarily US-based. For teams that need GDPR compliance without complex DPAs, an EU-hosted alternative is simpler.

LaunchDarkly Pricing Breakdown: Why MAU Gets Expensive

LaunchDarkly's pricing model revolves around two axes: seats (the developers who manage flags) and Monthly Active Users (the end users your application evaluates flags for). This sounds reasonable until you look at how MAU scales in practice.

Here's how it works:

Base plan cost: LaunchDarkly's Pro plan starts around $10,000/year. Enterprise plans start around $25,000/year and go well over $100,000/year depending on contract terms.
MAU tiers: Each plan includes a base MAU allotment. Once you exceed it, you pay per additional MAU block. The per-MAU overage cost varies by contract, but published estimates range from $0.01 to $0.03 per MAU.
MAU counts every unique user: Every user who triggers a flag evaluation counts, regardless of how many flags you use. If you have 100,000 active users but only 3 flags, you're still paying for 100,000 MAU.
Client-side vs server-side: Client-side SDKs report MAU automatically. Server-side SDKs can too, depending on how you pass user contexts.

The problem is that MAU correlates with product growth, not feature flag complexity. A team with 50,000 MAU and 5 flags pays far more than a team with 1,000 MAU and 200 flags — even though the second team puts more load on the system.

For startups experiencing growth, this creates budget unpredictability. You might be paying $1,000/month one quarter and $4,000/month the next, simply because your product is succeeding.

Cheaper alternatives to LaunchDarkly, like Rollgate, avoid this problem entirely by pricing on SDK requests — a metric you can control and predict.

Feature Flag Tools Compared: Rollgate vs LaunchDarkly vs Alternatives

Here's a side-by-side comparison of the major feature flag platforms in 2026:

Feature	Rollgate	LaunchDarkly	Flagsmith	ConfigCat	GrowthBook
Free tier	500K req/mo	Limited trial	50K req/mo	10 flags	Unlimited (self-hosted)
Paid plans	From €39/mo	From ~$8,333/mo (est.)	From $45/mo	From $84/mo	From $99/mo
Pricing model	Per request (flat)	Per MAU + seat	Per request + seat	Per config fetches	Per seat
SDKs	13 official	25+	18	12	8
Scheduled changes	All paid plans	Enterprise only	No	No	No
1-click rollback	All paid plans	Flag history only	Audit log	No	No
Self-hosted	Coming soon	No	Yes	No	Yes
EU data residency	Yes (Germany)	US-primary	Configurable	EU option	Self-hosted only
A/B testing	Yes (Pro+)	Yes (add-on)	No	No	Yes (core)
Real-time (SSE)	Yes	Yes	Yes	Polling only	Polling only

Note on competitor pricing: Prices change frequently. Check each vendor's website for current pricing. The estimates above are based on publicly available information as of March 2026.

Real Cost Comparison: 10K, 50K, 100K, 500K MAU

One of the biggest reasons teams look for a LaunchDarkly alternative is sticker shock at scale. Here's a realistic cost comparison across different growth stages, assuming a team of 10 developers:

MAU	Rollgate (est.)	LaunchDarkly (est.)	Flagsmith (est.)	ConfigCat (est.)	GrowthBook (est.)
10K	€39/mo	~$1,000/mo	~$45/mo	~$84/mo	~$99/mo
50K	€39-99/mo	~$2,500/mo	~$200/mo	~$200/mo	~$99/mo
100K	€99-119/mo	~$4,000/mo	~$400/mo	~$350/mo	~$99/mo
500K	€299-349/mo	~$10,000+/mo	~$1,200/mo	~$800/mo	~$200/mo

How to read this table: Rollgate prices are based on SDK requests, not MAU, so the correlation is approximate. A typical SPA polling every 30 seconds generates ~86K requests/user/month. With caching and SSE (which Rollgate supports), actual request volume is much lower. LaunchDarkly estimates are based on published pricing and community reports — actual costs depend on your contract.

The pattern is clear: at every growth tier, LaunchDarkly costs 5-30x more than alternatives. For a team at 100K MAU, the difference between Rollgate (~€99/mo) and LaunchDarkly (~$4,000/mo) is roughly $46,000/year.

That's not a rounding error — that's a senior developer's salary.

Why Rollgate Is the LaunchDarkly Alternative Built for Growing Teams

Rollgate was built by developers who got tired of paying five figures for a feature flag service. Here's what makes it different.

12 Official SDKs with Built-in Resilience

Every Rollgate SDK ships with circuit breakers, retry with exponential backoff, local caching, and graceful degradation. If the Rollgate API goes down, your flags keep working with cached values.

Here's a React example:

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

function App() {
  return (
    <RollgateProvider apiKey="rg_client_your_key">
      <Dashboard />
    </RollgateProvider>
  );
}

function Dashboard() {
  const showNewDashboard = useFlag('new-dashboard', false);

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

And on the backend with Node.js:

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

const client = new RollgateClient({
  apiKey: process.env.ROLLGATE_SERVER_KEY,
  enableSSE: true, // real-time updates
});

await client.initialize();

app.get('/api/pricing', (req, res) => {
  const newPricing = client.isEnabled('new-pricing-model', {
    id: req.user.id,
    attributes: { plan: req.user.plan, country: req.user.country }
  });

  if (newPricing) {
    return res.json(calculateNewPricing(req.user));
  }
  return res.json(calculateLegacyPricing(req.user));
});

Scheduled Changes as a First-Class Feature

Unlike LaunchDarkly where scheduling is buried in enterprise plans, Rollgate makes scheduled changes available on every paid plan. Set enable_at and disable_at directly from the dashboard or API:

# Schedule a flag to enable at midnight UTC on launch day
curl -X POST https://api.rollgate.io/api/v1/projects/:id/flags/:flagId/schedule \
  -H "Authorization: Bearer $ROLLGATE_SERVER_KEY" \
  -d '{"enable_at": "2026-04-01T00:00:00Z"}'

You can also schedule a maintenance window — enable at midnight, disable at 6am — all from the dashboard without writing any code.

Gradual Rollouts Without Complexity

Rollgate supports percentage-based gradual rollouts on every plan. Roll a feature out to 5% of users, monitor your metrics, then ramp to 25%, 50%, and 100%. If something goes wrong at any stage, roll back instantly to the previous percentage.

LaunchDarkly supports this too, but it's part of their premium pricing. With Rollgate, gradual rollouts are available starting from the free tier.

Flat, Predictable Pricing

Rollgate pricing is based on SDK requests, not MAU. You know exactly what you'll pay:

Plan	Monthly	SDK Requests	Projects	Team Members
Free	€0	500K/mo	3	3
Starter	€39-45/mo	1M/mo	5	5
Pro	€99-119/mo	3M/mo	10	15
Growth	€299-349/mo	12M/mo	Unlimited	50

A team polling every 30 seconds generates about 86K SDK requests per month per client. Even at scale, Rollgate costs a fraction of LaunchDarkly.

What LaunchDarkly Does Better

Let's be honest — LaunchDarkly is the market leader for a reason. If you're evaluating alternatives, you should know where LaunchDarkly genuinely excels:

Mature Ecosystem and Integrations

LaunchDarkly has 25+ official SDKs covering virtually every language and framework. They also have deep integrations with tools like Jira, Slack, Datadog, Terraform, and dozens more. If you need a Haskell SDK or a Terraform provider on day one, LaunchDarkly has it.

Rollgate covers the 12 most-used platforms, which handles 95%+ of teams. But if your stack includes niche languages, verify SDK availability first.

Enterprise Features

LaunchDarkly offers features built for large enterprise organizations: approval workflows, custom roles with granular permissions, audit log exports, SCIM provisioning, and SSO with every major identity provider. If you have a 200-person engineering org with strict compliance requirements, these features matter.

Rollgate covers team management, role-based access, and audit logging — enough for most teams — but doesn't yet match LaunchDarkly's enterprise governance depth.

Relay Proxy

LaunchDarkly's Relay Proxy lets you run a local proxy that caches flag data, reducing latency and providing an extra layer of resilience. This is particularly valuable in high-traffic environments or architectures with strict network policies.

Rollgate's SDKs handle resilience at the SDK level (circuit breakers, local cache, SSE streaming), but a dedicated relay proxy is not yet available.

Statistical Experimentation

LaunchDarkly's experimentation add-on includes statistical significance calculations, metric analysis, and guardrail metrics. If you're running high-stakes A/B tests where statistical rigor matters, LaunchDarkly's experimentation is more mature.

Rollgate offers A/B testing on Pro plans and above, but the statistical analysis tooling is still evolving.

Bottom line: If you're a Fortune 500 company with an unlimited budget and need every possible integration, LaunchDarkly is a safe choice. For everyone else, the question is whether those extras justify 10-30x the cost.

Migration from LaunchDarkly to Rollgate

Switching from LaunchDarkly doesn't have to be painful. Here's a practical migration path:

Step 1: Export Your Flags

Audit your current LaunchDarkly flags. Most teams discover that 30-50% of their flags are stale (old kill switches, completed rollouts, abandoned experiments). Migration is a good time to clean house.

For each active flag, note:

Flag key and type (boolean, string, multivariate)
Targeting rules and segments
Default values (on/off)
Which environments use it

Step 2: Create Flags in Rollgate

Recreate your active flags in the Rollgate dashboard. Rollgate supports the same flag types: boolean, string, number, and JSON. Targeting rules map directly — user attributes, segments, and percentage rollouts all work the same way.

Step 3: Swap the SDK

This is the core change. Here's how LaunchDarkly SDKs map to Rollgate equivalents:

LaunchDarkly SDK	Rollgate SDK	Package
`launchdarkly-js-client-sdk`	`@rollgate/sdk-browser`	Browser/SPA
`launchdarkly-react-client-sdk`	`@rollgate/sdk-react`	React
`@launchdarkly/node-server-sdk`	`@rollgate/sdk-node`	Node.js server
`launchdarkly-vue-client-sdk`	`@rollgate/sdk-vue`	Vue 3
`gopkg.in/launchdarkly/go-server-sdk.v5`	`github.com/rollgate/sdk-go`	Go server
`com.launchdarkly:launchdarkly-java-server-sdk`	`io.rollgate:sdk-java`	Java server
`launchdarkly-server-sdk` (Python)	`rollgate-sdk-python`	Python server
`launchdarkly_flutter_client_sdk`	`rollgate_sdk_flutter`	Flutter
`launchdarkly-react-native-client-sdk`	`@rollgate/sdk-react-native`	React Native

Step 4: Update Flag Evaluation Calls

The API surface is intentionally similar. Here's a typical before/after:

LaunchDarkly (React):

import { useFlags } from 'launchdarkly-react-client-sdk';

function MyComponent() {
  const { newCheckout } = useFlags();
  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 differences: Rollgate uses useFlag('key', defaultValue) instead of destructuring from useFlags(). This makes default values explicit and avoids issues with undefined flags.

Step 5: Run Both in Parallel (Optional)

For critical flags, you can run both LaunchDarkly and Rollgate simultaneously during a transition period. Evaluate flags from both services and log any discrepancies. Once you're confident the values match, remove the LaunchDarkly SDK.

Step 6: Clean Up

Remove LaunchDarkly SDK packages, delete environment variables, and update your CI/CD pipeline. Cancel your LaunchDarkly contract (check your billing cycle — many contracts auto-renew).

Most teams complete the migration in 1-3 days for small projects and 1-2 weeks for larger codebases with multiple services.

When to Choose Each Alternative

Choose Rollgate if:

You want flat, predictable pricing without MAU penalties
Scheduled releases and instant rollback are core requirements
You need GDPR compliance with EU-hosted infrastructure (Germany)
You're a startup or mid-size team (5-50 developers) shipping fast
You want resilient SDKs with circuit breakers and local caching out of the box
You care about gradual rollouts as part of your release process

Choose LaunchDarkly if:

You're an enterprise with budget for $25K+/year and need maximum integrations
You need 25+ SDKs including niche languages (Haskell, Erlang, Lua, etc.)
You need built-in experimentation with statistical significance
You require enterprise governance: approval workflows, SCIM, custom roles
You need the Relay Proxy for latency-sensitive, high-traffic architectures

Choose Flagsmith if:

You need to self-host today and want an open-source option (MIT license)
You want remote config in addition to feature flags
You need an open API and want full control over your flag infrastructure
You're comfortable managing your own infrastructure and upgrades

Choose ConfigCat if:

You have a small team with very few flags and simple targeting needs
You primarily need simple boolean toggles without scheduling or rollback
You want a no-frills tool that does the basics well at a reasonable price
Polling-based updates (no real-time SSE) are acceptable for your use case

Choose GrowthBook if:

A/B testing and experimentation are your primary use case, not feature management
You want to self-host and connect your own data warehouse (BigQuery, Snowflake, etc.)
You need Bayesian statistical analysis built into the platform
Feature flags are secondary to your experimentation workflow

FAQ

Is Rollgate production-ready?

Yes. Rollgate has been running in production since 2025. The platform handles millions of SDK requests, is hosted on EU infrastructure (Hetzner, Germany), and has built-in resilience at every layer — from the API (health checks, graceful degradation) to the SDKs (circuit breakers, retry logic, local caching). You can try the live demo to see the dashboard and evaluate flags in real time.

How long does migration from LaunchDarkly take?

For most teams, 1-3 days for a small project (one service, a few flags) and 1-2 weeks for larger codebases with multiple services and environments. The SDK APIs are intentionally similar, so the code changes are mostly find-and-replace. The longest part is usually auditing and cleaning up stale flags, which you should do anyway.

Does Rollgate support Server-Side Rendering (SSR)?

Yes. The @rollgate/sdk-node package supports server-side flag evaluation, which integrates with Next.js, Nuxt, SvelteKit, and any other SSR framework. You can evaluate flags on the server and pass them to the client as initial props, avoiding layout shifts and flicker. The Node SDK supports SSE for real-time updates, so flag changes propagate without redeployment.

How does Rollgate pricing compare to LaunchDarkly for a growing startup?

A startup with 50,000 MAU would pay approximately $2,500/month with LaunchDarkly. With Rollgate, the same team would pay €39-99/month depending on SDK request volume. That's a difference of roughly $28,000/year. See the full pricing comparison for details.

Can I use Rollgate with my existing analytics stack?

Yes. Rollgate's SDKs emit events that you can forward to your existing analytics tools (Segment, Mixpanel, PostHog, etc.). Flag evaluations include context about which variant was served, making it easy to correlate feature flags with product metrics.

Get Started

Rollgate's free tier includes 500K requests per month, 3 projects, all 13 SDKs, and unlimited flags. No credit card required.

If you're evaluating a LaunchDarkly alternative, create a free account or try the live demo to see it in action.

I'm building Rollgate, a feature flag platform for developers. If you have questions about feature flags, drop them in the comments — happy to help!

What Are Feature Flags? A Complete Guide for 2026

Domenico Giordano — Fri, 03 Apr 2026 12:55:13 +0000

I've been using feature flags for years, and I'm still surprised how many teams ship code without them. Whether you're a solo dev or on a 50-person team, feature flags change how you think about deployments. This is the guide I wish I had when I started — practical, with real code examples in 5 languages.

What Are Feature Flags?

Feature flags (also called feature toggles or feature switches) are a software development technique that lets you enable or disable functionality in your application without deploying new code. Instead of shipping a feature directly to all users, you wrap it behind a conditional check that can be toggled on or off remotely.

At its simplest, a feature flag looks like this:

if (featureFlags.isEnabled('new-checkout')) {
  showNewCheckout();
} else {
  showOldCheckout();
}

The key difference from a regular if statement is that the flag's value is controlled externally — through a dashboard, API, or configuration service — not hardcoded in your source code. This separation of deployment from release is what makes feature flags so powerful for modern engineering teams.

Feature flags have become a core practice at companies like Netflix, GitHub, Google, and Spotify. They're not just a convenience — they're infrastructure that enables continuous delivery, experimentation, and operational safety at scale.

Feature Flags vs Feature Toggles vs Feature Switches

If you've been researching this topic, you've probably seen all three terms used interchangeably. Here's the short answer: they're the same thing.

Feature flag is the most widely used term, especially in North America and in the context of SaaS platforms.
Feature toggle was popularized by Martin Fowler's influential article on feature toggles and is common in European engineering circles.
Feature switch is less common but still used, particularly in mobile development and gaming.

Some teams draw subtle distinctions — for example, using "toggle" for simple on/off switches and "flag" for flags with targeting rules and percentage rollouts — but in practice, the industry treats them as synonyms. Throughout this guide, we'll use "feature flag" as the primary term.

What matters is not the name but the capability: decoupling code deployment from feature release so you can control what users see without redeploying your application.

Why Use Feature Flags?

Feature flags solve several problems that every growing engineering team faces:

Ship Faster, Break Less

Without feature flags, deploying code means releasing it to everyone. This creates pressure to batch changes into large releases, which are riskier and harder to debug. Feature flags decouple deployment from release. You can merge code to main, deploy it to production, and only enable it when you're ready.

This is the foundation of trunk-based development — a practice where all developers commit to a single branch and use feature flags to hide work-in-progress. No more long-lived feature branches, no more merge conflicts, no more "integration hell." If you're curious about how this compares to branching strategies, check out our guide on feature flags vs feature branches.

Gradual Rollouts

Instead of flipping a switch for 100% of users, you can roll out a feature to 1%, then 5%, then 25%, then 100%. If something goes wrong at 5%, you turn it off — no rollback, no hotfix, no downtime.

Gradual rollouts give you confidence. You can observe real-world behavior with a small audience before committing to a full release. For a deep dive on implementation strategies, see our gradual rollouts guide.

Kill Switches

Production incidents happen. A feature flag gives you an instant kill switch. Instead of reverting a commit, waiting for CI, and redeploying, you toggle a flag and the problematic feature is disabled in seconds.

The difference between a 30-second recovery and a 30-minute recovery is enormous — both for user experience and for your on-call team's stress levels.

A/B Testing

Feature flags are the foundation of experimentation. Show variant A to 50% of users and variant B to the other 50%, then measure which performs better. This is how companies like Netflix, Uber, and Spotify make data-driven product decisions.

With multivariate flags, you can test more than two variants simultaneously — different copy, layouts, pricing displays, or algorithms — and let data guide your decisions. Learn more about combining A/B testing with feature flags.

User Targeting

Want to enable a feature only for beta testers? Or only for users on the Pro plan? Feature flags with targeting rules let you control exactly who sees what, based on user attributes like email, plan, country, or custom properties.

Scheduled Releases

Some features need to go live at a specific time — a marketing campaign, a product launch, or a compliance deadline. Feature flags with scheduling let you set the exact moment a feature activates without anyone staying up at midnight to press a button. We cover this in detail in our scheduled releases guide.

Types of Feature Flags

Not all feature flags are the same. Understanding the different types helps you use them effectively:

Release Flags

The most common type. Used to hide incomplete features in production. Short-lived — removed once the feature is fully launched. These flags enable trunk-based development by letting you merge partially complete work without exposing it to users.

Ops Flags

Used for operational control. Kill switches, circuit breakers, and maintenance modes. These tend to be long-lived and are critical for system reliability. Examples include disabling a non-essential service during peak load or switching to a fallback provider when a third-party API is down.

Experiment Flags

Used for A/B tests and multivariate experiments. They assign users to variants and track metrics. Removed after the experiment concludes and a winner is chosen.

Permission Flags

Control access to features based on user attributes — plan tier, role, geography. Often long-lived, acting as a dynamic permission system. For example, showing advanced analytics only to Pro plan users, or enabling GDPR-specific data handling for EU users.

How Feature Flags Work: Architecture Deep Dive

Understanding the architecture behind feature flags helps you make better decisions about implementation. Here's how a typical feature flag system works end to end:

┌─────────────┐     ┌──────────────────┐     ┌─────────────┐
│  Dashboard   │────>│  Flag Service    │────>│  Database   │
│  (Web UI)    │     │  (API Server)    │     │  (Postgres) │
└─────────────┘     └──────────────────┘     └─────────────┘
                           │
                    ┌──────┴──────┐
                    │             │
               SSE/Polling    REST API
                    │             │
              ┌─────v─────┐ ┌────v──────┐
              │ Client SDK │ │ Server SDK│
              │ (Browser)  │ │ (Node/Go) │
              └─────┬─────┘ └────┬──────┘
                    │             │
              ┌─────v─────┐ ┌────v──────┐
              │ Your App   │ │ Your API  │
              │ (Frontend) │ │ (Backend) │
              └───────────┘ └───────────┘

The Flag Service

At the center is the flag service — the API that stores flag definitions, targeting rules, and percentage allocations. This is where the logic lives: "Enable new-pricing for 20% of users in the US who are on the Pro plan." The service evaluates rules and returns flag states for a given user context.

Client-Side vs Server-Side Evaluation

There are two fundamental approaches to flag evaluation:

Server-side evaluation — Your backend SDK sends the user context to the flag service (or evaluates locally with a cached ruleset) and returns the computed flag values. This is more secure because targeting rules and flag logic never leave your server.

Client-side evaluation — The browser SDK receives the evaluated flag values from the flag service (not the raw rules). The client knows what's enabled for the current user but doesn't see other users' configurations or your targeting logic.

Most production setups use both: server-side SDKs for backend logic and API responses, and client-side SDKs for UI rendering.

Polling vs Streaming

How does your SDK know when a flag changes?

Polling — The SDK periodically checks the flag service for updates (e.g., every 30 seconds). Simple to implement, but introduces latency. If you toggle a flag, it might take up to 30 seconds to propagate.

Streaming (SSE/WebSocket) — The flag service pushes updates to connected SDKs in real-time via Server-Sent Events or WebSockets. Changes propagate in milliseconds. More complex to operate, but critical for kill switches where seconds matter.

Most feature flag platforms support both, letting you choose based on your latency requirements.

The SDK Pattern

Modern feature flag SDKs follow a consistent pattern regardless of language:

Initialize with a client key and optional user context
Cache flag values locally (in memory, localStorage, or disk)
Evaluate flags synchronously from the local cache
Sync with the flag service in the background (polling or streaming)
Emit events for analytics and experimentation tracking

This means flag evaluation is fast (local cache lookup) and resilient (works even if the flag service is temporarily unavailable).

Feature Flags in Different Languages

Feature flags work across any language and framework. Here's what the integration looks like in practice:

JavaScript / React

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

function PricingPage() {
  const showNewPricing = useFlag('new-pricing-page');

  if (showNewPricing) {
    return <NewPricingLayout />;
  }
  return <CurrentPricingLayout />;
}

Node.js

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

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

app.get('/api/recommendations', async (req, res) => {
  const useNewAlgorithm = await client.isEnabled('new-recommendations', {
    userId: req.user.id,
    attributes: { plan: req.user.plan },
  });

  const results = useNewAlgorithm
    ? await newRecommendationEngine(req.user)
    : await currentRecommendationEngine(req.user);

  res.json(results);
});

Python

from rollgate import RollgateClient

client = RollgateClient(api_key=os.environ["ROLLGATE_SERVER_KEY"])

@app.route("/api/search")
def search():
    user_context = {"userId": current_user.id, "attributes": {"plan": current_user.plan}}

    if client.is_enabled("new-search-engine", user_context):
        return new_search(request.args["q"])
    return legacy_search(request.args["q"])

Go

package main

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

func handleRequest(w http.ResponseWriter, r *http.Request) {
    ctx := rollgate.UserContext{
        UserID:     r.Header.Get("X-User-ID"),
        Attributes: map[string]interface{}{"plan": "pro"},
    }

    if client.IsEnabled("new-dashboard", ctx) {
        serveNewDashboard(w, r)
    } else {
        serveCurrentDashboard(w, r)
    }
}

Java

import io.rollgate.sdk.RollgateClient;
import io.rollgate.sdk.UserContext;

RollgateClient client = new RollgateClient(System.getenv("ROLLGATE_SERVER_KEY"));

UserContext context = UserContext.builder()
    .userId(currentUser.getId())
    .attribute("plan", currentUser.getPlan())
    .build();

if (client.isEnabled("new-payment-flow", context)) {
    return processWithNewFlow(order);
} else {
    return processWithCurrentFlow(order);
}

The pattern is the same everywhere: initialize a client, pass user context, and evaluate a flag. The SDK handles caching, syncing, and resilience under the hood.

Feature Flag Use Cases

Feature flags are versatile. Here are the most common real-world scenarios where teams use them:

Dark Launches

Deploy a feature to production without any user seeing it. The code is live, but the flag is off. This lets you verify that deployment works — database migrations ran, services connect, no errors in logs — before any user is exposed to the change. When you're confident, you flip the flag for a small group.

Dark launches are especially valuable for major infrastructure changes. You can deploy a new payment provider integration, test it with internal transactions, and gradually shift real traffic without any public announcement.

Beta Programs and Early Access

Create a segment of beta users who opt in to see new features before general availability. This gives you real feedback from motivated users without the risk of a full release. Flag targeting rules make this trivial: target users where beta_program = true or where the email ends with @yourcompany.com.

Trunk-Based Development

In trunk-based development, all developers commit to main (or a single trunk branch). Feature flags hide incomplete work so it can be merged without breaking the application. This eliminates long-lived feature branches, reduces merge conflicts, and keeps the codebase in a continuously deployable state.

The workflow: create a flag, wrap your work-in-progress code behind it, merge to main, deploy. The flag stays off until the feature is complete and tested. Read more about feature flags vs feature branches and why many teams are making this switch.

Canary Releases

A canary release routes a small percentage of traffic to the new version while the majority stays on the current version. If the canary shows elevated error rates or latency, you pull it back. Feature flags enable canary releases at the application level — no need for infrastructure-level traffic splitting.

Operational Kill Switches

Every external dependency in your system should have a kill switch. If your recommendation engine depends on a third-party ML service, wrap it in a flag. When that service has an outage, disable the flag and fall back to a simpler algorithm. Your users see slightly less personalized results instead of an error page.

Entitlement Management

Use feature flags as a dynamic permission layer. Free users see the basic editor; Pro users see the advanced editor with collaboration features; Enterprise users see admin controls and audit logs. When a user upgrades their plan, their flag evaluations update in real time — no code change needed.

Compliance and Regional Features

Some features are only legal in certain regions, or need to comply with specific regulations. Feature flags targeting by geography let you enable GDPR consent flows for EU users, disable certain data collection in California for CCPA compliance, or roll out features region by region to meet local requirements.

Feature Flag Lifecycle

Every feature flag should follow a defined lifecycle. Flags that linger without clear ownership become technical debt. Here's the lifecycle that high-performing teams follow:

1. Planning

Before creating a flag, define its purpose, type, and expected lifetime. A release flag for a new checkout flow might have a two-week lifespan. An ops flag for a circuit breaker might be permanent. Document this upfront.

2. Creation

Create the flag in your dashboard with a descriptive name, a description of its purpose, and an owner. Use a consistent naming convention across your team — feature.checkout-v2, ops.disable-recommendations, experiment.pricing-page-layout.

3. Implementation

Wrap the relevant code paths with the flag check. Keep the flag's scope as narrow as possible — one flag should control one feature, not five. Test both the on and off states.

4. Rollout

Enable the flag progressively. Internal users first, then beta testers, then 5% of production traffic, then wider. Monitor error rates, latency, and business metrics at each stage. Our gradual rollouts guide covers specific strategies.

5. Full Release

Once you're confident, enable the flag for 100% of users. But you're not done yet.

6. Cleanup

This is the step most teams skip — and it's the most important for long-term codebase health. Once a flag has been at 100% for a defined period (one to two weeks is common), remove it:

Delete the flag evaluation from your code
Remove the else branch (the old code path)
Delete the flag from your dashboard
Update any tests that referenced the flag

Set a calendar reminder or use your flag service's stale flag detection to ensure cleanup happens. A codebase with 500 stale flags is a codebase no one wants to touch.

Common Feature Flag Mistakes

Feature flags are powerful, but misuse leads to real problems. Here are the mistakes we see most often:

Never Cleaning Up Flags

The most common mistake by far. Teams add flags but never remove them. Six months later, no one knows if temp-fix-checkout-2024 is still needed. The code has two paths, both partially tested, and removing either feels risky. Prevent this by assigning an owner and an expiry date to every flag at creation time.

Flag Sprawl

Creating too many flags without governance leads to combinatorial complexity. If you have 20 flags, there are potentially over a million unique combinations of flag states. Testing all of them is impossible. Keep your active flag count manageable and archive flags aggressively.

Testing Only the Happy Path

If your code has a feature flag, it has two code paths. Many teams only test the new path (flag on) and neglect the old path (flag off). When the flag is toggled off in an emergency, the fallback is broken because no one tested it.

Nesting Flags

Avoid situations where one flag's behavior depends on another flag's state. if (flagA && flagB) quickly becomes if (flagA && flagB && !flagC), and suddenly your application behavior is impossible to reason about. If you find yourself nesting flags, it's a sign your flag design needs simplification.

Using Flags for Permanent Configuration

Feature flags are for temporary conditions. If something will never be removed — like a config value for page size or a timeout duration — use application configuration, not a feature flag. Conflating the two leads to a flag system bloated with pseudo-config values.

Not Monitoring Flag Impact

Toggling a flag without monitoring is flying blind. Always have dashboards or alerts that correlate flag state changes with key metrics (error rate, latency, conversion). If you enable a flag and errors spike, you need to know immediately.

Feature Flag Best Practices

Keep Flags Short-Lived

Every feature flag is technical debt. Once a feature is fully rolled out, remove the flag and the conditional code. Stale flags clutter your codebase and confuse new team members.

Name Flags Descriptively

Use clear, consistent naming. enable-new-checkout-flow is better than flag-42 or test. Include the feature area and purpose in the name.

Use a Feature Flag Service

Managing flags through config files or environment variables works for a handful of flags but doesn't scale. A dedicated service gives you a dashboard, audit logs, targeting rules, and real-time updates without redeployment.

Test Both Paths

If your code has a feature flag, you have two code paths. Test both. Ensure the application works correctly whether the flag is on or off.

Monitor Flag Usage

Track how many users are seeing each variant. Monitor error rates and performance metrics per flag state. This helps you catch issues early during rollouts.

Set Ownership and Expiry

Every flag should have an owner (a person or team) and an expected removal date. Review stale flags weekly. If a flag has been at 100% for more than two weeks and no one can explain why it's still there, it's time to clean it up.

Feature Flag Tools: The Landscape

There are several feature flag platforms available, ranging from open-source to enterprise SaaS. Here's a brief overview to help you evaluate:

LaunchDarkly — The established market leader with enterprise features, strong SDKs, and a mature platform. Well-suited for large organizations. Pricing starts high and scales with seat count and monthly active users (MAUs), which can get expensive quickly. See our LaunchDarkly alternative comparison for a detailed breakdown.

Flagsmith — Open-source with a hosted option. Good flexibility, supports self-hosting. The interface can feel complex for smaller teams, and some advanced features require the enterprise tier.

ConfigCat — Simple and affordable. Good for teams that want basic flag management without the complexity of a full experimentation platform. Limited targeting and analytics compared to other options.

GrowthBook — Open-source, strong focus on A/B testing and experimentation. Great if experiments are your primary use case. The feature flagging capabilities are secondary to the experimentation engine.

Rollgate — Built for teams that want a fast, developer-focused flag platform without enterprise pricing. First-party analytics, multi-environment support, and SDKs for all major languages and frameworks. Transparent pricing with a generous free tier. For a detailed pricing comparison across platforms, see our feature flags pricing comparison.

The right tool depends on your team size, budget, and requirements. What matters most is that you use something — even a simple implementation is better than no feature flags at all.

Getting Started with Feature Flags

If you're new to feature flags, start simple:

Pick a feature flag service — Choose one that fits your stack and budget. You can try Rollgate for free or explore the live demo to see how it works.
Install the SDK for your tech stack — most platforms have SDKs for JavaScript, React, Node.js, Python, Go, and more.
Create your first flag and wrap a small, low-risk feature — maybe a UI change or a new notification.
Practice the cycle: create flag, deploy code, enable for internal users, monitor, full rollout, clean up.
Establish team conventions — naming patterns, ownership rules, and cleanup cadence.

The learning curve is gentle. Most teams have their first flag in production within an hour.

Conclusion

Feature flags are more than just if/else statements. They're a deployment strategy, a safety net, and an experimentation platform rolled into one. Whether you're a solo developer or part of a large engineering team, feature flags help you ship faster, recover from incidents in seconds, and make product decisions backed by real data.

The pattern is simple — wrap code behind a conditional, control it remotely — but the impact on your delivery velocity and operational confidence is profound. Teams that adopt feature flags consistently report shorter release cycles, fewer production incidents, and more experimentation.

If you're ready to get started, create a free Rollgate account or explore the interactive demo to see feature flags in action.

I'm building Rollgate, a feature flag platform for developers. If you have questions about feature flags, drop them in the comments — happy to help!