Skip to Content

The Complete Guide to Feature Flag Scenarios: From Kill Switches to Ring Deployments

March 5, 2026

Feature flags are one of those ideas that seem deceptively simple. Wrap a code path in an if statement, toggle it remotely. Done, right?

In practice, feature flags are a Swiss Army knife for modern software delivery. The same primitive — a conditional check evaluated at runtime — powers everything from emergency kill switches to multi-week canary rollouts to sophisticated A/B experiments with statistical significance testing.

Today we’re publishing the GoGreen Flags Feature Flag User Guide, a comprehensive reference covering every flag type, targeting scenario, and SDK pattern we support. In this post, we’ll walk through the highlights and share the thinking behind each scenario.

The Four Flag Types

Most platforms stop at boolean flags. We support four:

Boolean is the workhorse — on/off, true/false. Kill switches, feature gates, simple A/B tests.

String flags unlock multi-variant testing and configuration selection. Instead of true/false, you return "classic", "modern", or "minimal" — great for theme selection, algorithm variants, or copy testing.

Number flags let you tune parameters without redeploying: rate limits, timeout values, cache TTLs, discount percentages. Change a number in the dashboard, and every server picks it up within seconds via streaming.

JSON flags are the most powerful. Return structured configuration objects — layout definitions, feature bundles, form schemas. One flag, infinite flexibility.

// Boolean: simple feature gate
enabled := client.BoolVariation("new-checkout", user, false)
 
// String: select a variant
theme := client.StringVariation("checkout-theme", user, "classic")
 
// Number: tune a parameter
rateLimit := client.NumberVariation("api-rate-limit", user, 100)
 
// JSON: return structured config
config := client.JSONVariation("dashboard-layout", user, defaultConfig)

12 Targeting Scenarios

The user guide covers twelve distinct targeting scenarios with dashboard setup steps and full SDK examples in both Go and TypeScript. Here are the ones teams use most:

1. Kill Switch

The simplest and most critical pattern. Toggle a flag off, and every user immediately gets the safe default. No rules, no percentage logic — just enabled: false.

When your new payment processor starts throwing 500s at 2 AM, you don’t want to be running git revert && git push && wait for CI. You want a button.

2. Percentage Rollout

Release to 10% of users first. If metrics look good, bump to 25%, then 50%, then 100%. The assignment is deterministic — we use MurmurHash3 on flagKey.userKey.salt to produce a stable bucket (10,000 buckets = 0.01% precision). The same user always gets the same variation.

3. Gradual Rollout Schedule

The automated version of percentage rollout. Define steps — 1% for 60 minutes, then 10% for 2 hours, then 50% for 4 hours, then 100% — and the system advances automatically. If something goes wrong, one click rolls back to the previous step.

This is how you do multi-day canary releases without waking up to change a percentage.

4. Segment Targeting

Segments are reusable groups: “beta testers”, “enterprise customers”, “QA team”. Define them once, reference them in any flag. We support two types:

  • Rule-based: Dynamic membership via attribute clauses (plan = "enterprise" AND region IN ["US", "EU"])
  • List-based: Explicit user key lists, up to 1M entries, with CSV/JSON bulk upload

5. Ring-Based Deployment

Combine segments into deployment rings. Priority-ordered rules ensure Ring 0 (internal) sees the feature first, then Ring 1 (beta), then Ring 2 (early adopters), then everyone else. Enable each ring independently as confidence grows.

6. Prerequisites

Flag B only evaluates if Flag A returns a specific variation. This lets you build feature chains — “advanced analytics” requires “basic analytics” to be on first. Prerequisites are checked recursively (up to 10 levels), and circular dependencies are rejected at save time.

Evaluation Detail: Know Why

Every SDK evaluation method has a Detail variant that returns not just the value, but the reason it was selected:

val, detail := client.BoolVariationDetail("new-checkout", user, false)
// detail.Reason.Kind = "RULE_MATCH"
// detail.RuleIndex = 0
// detail.VariationID = "var_abc123"

Reason codes include RULE_MATCH, DEFAULT, OFF, PREREQUISITE_FAILED, and ERROR. This is invaluable for debugging (“why is user X seeing the old experience?”) and for logging evaluation metadata alongside your application metrics.

Testing Without the Network

Feature flags shouldn’t make your tests flaky. Both SDKs provide a test client that returns predetermined values with zero network calls:

const client = GoGreenClient.testClient({
    'new-checkout': true,
    'checkout-theme': 'modern',
});
 
const enabled = await client.boolVariation('new-checkout', false);
// Always returns true — no API calls, no flakiness

For integration tests, use bootstrap mode to pre-load a full config, or toggle offline mode at runtime to freeze values mid-test.

OpenFeature: Vendor-Neutral by Default

If you prefer a vendor-neutral API, GoGreen Flags implements the OpenFeature  provider specification for both Go and TypeScript. Swap providers without changing application code:

provider := gogreen.NewGoGreenProvider(ggClient)
openfeature.SetProvider(provider)
 
ofClient := openfeature.NewClient("my-app")
enabled, _ := ofClient.BooleanValue(ctx, "new-checkout", false, evalCtx)

React: One Hook, Zero Boilerplate

For frontend teams, the TypeScript SDK includes a React provider and useFeatureFlag hook:

function CheckoutPage() {
    const { value: useNewCheckout, loading } = useFeatureFlag('new-checkout', false);
    if (loading) return <Spinner />;
    return useNewCheckout ? <NewCheckout /> : <ClassicCheckout />;
}

The provider handles initialization, streaming updates, and automatic re-renders when flag values change in real time.

Production Safeguards

Powerful targeting deserves powerful safeguards. GoGreen Flags provides:

  • Environment protection: Require approval from N reviewers before production changes go live
  • Diff modal: Every production save shows a JSON diff and requires a mandatory comment
  • Audit log: Every flag change, rule modification, and approval is logged with actor, timestamp, and full change details — exportable as CSV for compliance

Read the Full Guide

The Feature Flag User Guide covers all twelve targeting scenarios with step-by-step dashboard instructions and complete SDK examples in Go and TypeScript. It also includes a quick-reference cheat sheet mapping every common scenario to the right flag type and setup approach, and a full operator reference covering all 18+ targeting operators.

Whether you’re setting up your first kill switch or designing a multi-ring enterprise rollout, the guide has you covered.

Ready to get started? Sign up for free  or check out the documentation.