# Featureflip > Feature flag platform for modern development teams. Roll out features gradually, run A/B experiments, and let a GitHub Action open the pull request that deletes each flag once its rollout is finished. Free to start, with SDKs for JavaScript, Python, C#, Java, Go, PHP, Ruby, Swift, Flutter, Android, and React. - [Full site text for LLMs](https://featureflip.io/llms-full.txt): Every page inlined in full, including the comparison tables, alternatives guides, cost calculators, glossary definitions and question answers. ## Product - [Homepage](https://featureflip.io/): Feature flags without the tech debt. A GitHub Action opens one reviewable pull request per dead flag and removes the code path in thirteen languages once a rollout is finished, and every plan is one flat price with nothing metered. - [Product Features](https://featureflip.io/product/features/): Index of Featureflip's feature-flag capabilities, each with a dedicated deep-dive: percentage rollouts, user targeting, environments, SDKs, the audit log, and the REST API. - [Percentage Rollouts](https://featureflip.io/product/features/percentage-rollouts/): Ramp a feature from 1% to 100% of users on a slider without redeploying. Deterministic sticky bucketing keeps each user in place as you climb, changes stream live over SSE, and it composes with targeting rules, per-environment control, and multivariate weights. - [Feature Flag Targeting](https://featureflip.io/product/features/targeting/): Serve a variation to the users who match an attribute-based rule (equals, contains, startsWith, endsWith, in, combined with AND/OR) and the default to everyone else. Reusable per-project segments, first-match-wins ordering with a fallthrough, per-environment rules, sub-millisecond local evaluation, and live rule updates over SSE. - [Feature Flag Environments](https://featureflip.io/product/features/environments/): Keep development, staging, and production flag configurations fully isolated, each with its own SDK key that selects which environment an app reads. Independent flag states, targeting rules, and rollout percentages per environment; new environments default every flag to off; promote flags forward without a redeploy; sub-millisecond local evaluation with live updates over SSE. - [Scheduled Changes](https://featureflip.io/product/features/scheduled-changes/): Queue a flag to turn on or off automatically at a future time, per environment, applied server-side with no cron job or CI wiring. Cancel a pending change any time before it applies; when it runs it streams to connected SDKs live over SSE and is recorded in the audit log under the user who scheduled it. Pending / Applied / Failed / Cancelled history with failure reasons. - [Feature Flag SDKs](https://featureflip.io/product/features/sdks/): Official SDKs for 13 languages and frameworks — server (JavaScript/TypeScript, Node.js, Python, Go, Java, C#, Ruby, PHP) and client (React, Browser, Swift, Flutter, Android). Server SDKs evaluate flags locally in-memory with no per-request network call; every SDK streams config updates over SSE; one consistent variation API; identical results across SDKs (shared, vector-tested engine); fail-safe defaults; direct Evaluation API over HTTP for anything else. - [Feature Flag Audit Log](https://featureflip.io/product/features/audit-log/): Every flag and configuration change recorded automatically — actor (name + email), per-property before/after values, timestamp, and IP/user-agent. Covers flags, variations, targeting rules, per-environment config, environments, segments, SDK keys, projects, and the org. Read organization-wide (filter by project, entity, action, user, date) or per flag on a History tab. Retention 7 days (Solo) to 365 (Enterprise). - [Feature Flag REST API](https://featureflip.io/product/features/api/): The Management API at api.featureflip.io puts the whole flag configuration behind REST under /api/v1 — projects, environments, flags, variations, toggles, targeting rules, segments, and SDK keys. Bearer-token auth (Personal Access Tokens or project-scoped Service Tokens), Idempotency-Key on creates, X-RateLimit headers on every response, a frozen machine-readable error envelope, cursor pagination, and a full OpenAPI reference. Included on every plan. - [Security](https://featureflip.io/product/security/): How Featureflip protects customer data. All data stored and processed in the EU (Hetzner Cloud), Cloudflare in front for DNS/CDN/WAF, HSTS with preload. Evaluation context (user IDs, emails, attributes) is never stored, and server-side SDKs never transmit it because they evaluate locally in memory. TOTP two-factor authentication with recovery codes on every plan, Sign in with Google, SAML/SCIM on Enterprise, hashed passwords, temporary lockout on repeated failed sign-ins. Per-environment SDK keys; client keys return only client-side-visible flags as pre-evaluated values, never targeting rules. Personal (ffp_) and service (ffs_) API tokens with roles, project allowlists, expiry, and immediate revocation. Full audit log with actor, timestamp, IP/user-agent, and before/after values. Vulnerability reports go to security@featureflip.io. - [Pricing](https://featureflip.io/pricing/): Solo plan (free forever, 1 project, 10 flags), Pro from $49/month (10 projects, unlimited flags), Business from $149/month (25 projects, 90-day audit logs, priority support). - [Contact](https://featureflip.io/contact/): Reach the team at contact@featureflip.io or (770) 275-2734. ## Use Cases - [Feature Flag Use Cases](https://featureflip.io/use-cases/): Practical patterns teams run with flags — progressive rollouts, kill switches, and more. - [Progressive Rollouts](https://featureflip.io/use-cases/progressive-rollouts/): Ship to 1% of users first, watch the metrics, then expand in steps — the percentage is a config change, not a redeploy. - [Kill Switch](https://featureflip.io/use-cases/kill-switch/): Wrap a risky code path in a flag and disable it in production in seconds, with a fail-safe fallback and no rebuild or rollback. - [A/B Testing](https://featureflip.io/use-cases/a-b-testing/): Serve two variations to a sticky 50/50 split and record who saw which one — the flag delivers the experiment, your analytics call the winner. - [Entitlements](https://featureflip.io/use-cases/entitlements/): Gate features by plan tier with a targeting rule on the plan you pass at evaluation, with per-customer overrides. The flag enforces access; your billing system stays the source of truth for the plan. - [Beta Programs](https://featureflip.io/use-cases/beta-programs/): Ship the beta code with the flag off, opt testers in, hand-pick early access, and expand the cohort from the dashboard. The flag decides who is in the beta; your feedback and analytics tools own what they think. - [Feature Flags for AI and LLM Apps](https://featureflip.io/use-cases/feature-flags-for-ai/): Keep the model name, system prompt, temperature, and max_tokens in one JSON flag. Swap models with no deploy, migrate a new model in gradually with a sticky percentage rollout, route a model or prompt per tenant with targeting rules, and kill a bad model in seconds with a fail-safe cached-config fallback. The flag owns the model config and routing; your eval and observability tools own quality and cost. ## Feature Flag Tools - [Feature Flag Tools](https://featureflip.io/feature-flag-tools/): The category shortlist, grouped by what each vendor's meter counts rather than by feature. Three billing models cover all seven tools: flat (Featureflip, ConfigCat), per seat (Unleash at $75, GrowthBook at $40), and per unit of traffic (LaunchDarkly on service connections plus client-side MAU, Flagsmith on API requests, PostHog on flag requests). Every rate carries the date it was checked against the vendor's published pricing page. ## Compare - [Compare Featureflip](https://featureflip.io/compare/): Head-to-head comparisons of Featureflip against the major feature flag platforms — pricing, features, and a verdict for each team profile. - [Featureflip vs LaunchDarkly](https://featureflip.io/compare/featureflip-vs-launchdarkly/): Flat pricing vs LaunchDarkly's bundled, per-MAU platform — feature parity, pricing math, and when to pick each. - [Featureflip vs Flagsmith](https://featureflip.io/compare/featureflip-vs-flagsmith/): Flat pricing and unlimited evaluations vs API-request metering; hosted SaaS vs open-source self-host. - [Featureflip vs ConfigCat](https://featureflip.io/compare/featureflip-vs-configcat/): Project ceilings, network-traffic metering, and SAML/SCIM on free — the most direct small-team comparison. - [Featureflip vs Unleash](https://featureflip.io/compare/featureflip-vs-unleash/): Flat team pricing vs $75 a seat, a free hosted tier vs open-source-only free, SSE streaming vs polling. - [Featureflip vs PostHog](https://featureflip.io/compare/featureflip-vs-posthog/): A focused, flat-priced flag tool vs PostHog's usage-billed analytics suite — and when to pick each. - [Featureflip vs GrowthBook](https://featureflip.io/compare/featureflip-vs-growthbook/): A focused, flat-priced flag tool vs GrowthBook's open-source, warehouse-native experimentation suite — and when to pick each. ## Alternatives - [Feature Flag Alternatives](https://featureflip.io/alternatives/): Considering a switch? Honest alternatives guides for each major vendor, with multi-vendor recommendations and migration notes. - [LaunchDarkly Alternative](https://featureflip.io/alternatives/launchdarkly-alternative/): How to choose a LaunchDarkly replacement — six platforms weighed with a decision rubric for each. - [Flagsmith Alternative](https://featureflip.io/alternatives/flagsmith-alternative/): How to choose a Flagsmith replacement — six platforms weighed with a decision rubric for each. - [ConfigCat Alternative](https://featureflip.io/alternatives/configcat-alternative/): How to choose a ConfigCat replacement — six platforms weighed with a decision rubric for each. ## Tools - [Feature Flag Cost Calculators](https://featureflip.io/tools/): Six per-vendor calculators that run your own numbers through a published rate card and put the result next to Featureflip's flat price. Every rate carries a source link and a check date. - [LaunchDarkly Cost Calculator](https://featureflip.io/tools/launchdarkly-cost-calculator/): Estimate LaunchDarkly's usage-based Foundation bill from your service connections and client-side MAU, and compare it to Featureflip's flat price. Rates sourced and dated. - [Flagsmith Cost Calculator](https://featureflip.io/tools/flagsmith-cost-calculator/): Estimate Flagsmith's metered SaaS bill from your monthly API requests and team size, and compare it to Featureflip's flat price. Rates sourced and dated. - [ConfigCat Cost Calculator](https://featureflip.io/tools/configcat-cost-calculator/): Estimate ConfigCat's tiered plan cost from your product count and monthly network traffic, and compare it to Featureflip's flat price. Rates sourced and dated. - [Unleash Cost Calculator](https://featureflip.io/tools/unleash-cost-calculator/): Estimate Unleash cloud's per-seat Pay-As-You-Go bill from your team size and monthly API requests, and compare it to Featureflip's flat price. Rates sourced and dated. - [PostHog Feature Flags Cost Calculator](https://featureflip.io/tools/posthog-feature-flags-cost-calculator/): Estimate PostHog's per-request feature flag bill from your monthly flag request volume on its graduated rate curve, and compare it to Featureflip's flat price. Feature flags only, not the analytics bundle. Rates sourced and dated. - [GrowthBook Cost Calculator](https://featureflip.io/tools/growthbook-cost-calculator/): Estimate GrowthBook Cloud's per-seat bill from your team size, with the free 3-user Starter tier and the 50-user Pro ceiling accounted for, and compare it to Featureflip's flat price. Rates sourced and dated. ## Changelog - [Changelog](https://featureflip.io/changelog/): Dated record of what shipped to the Featureflip API, SDKs, and integrations, newest first. - [GitHub Action that removes dead flags from your source](https://featureflip.io/changelog/#flag-cleanup-action) (2026-09-09): Detecting a dead flag was always the easy half. The flag cleanup Action does the other one: it reads removal candidates from the public API, deletes the flag branch in your repository, and opens one pull request per flag for you to review. Merge it and the flag can archive itself, so the code and the dashboard stop disagreeing. It runs inside your CI holding your token, and no model writes the diff. The rewrites are AST transforms, so the same input always produces the same patch. - [OpenFeature provider for Java](https://featureflip.io/changelog/#openfeature-java) (2026-09-06): Java joins Node.js, .NET, Python and Go behind the OpenFeature API. The artifact is io.featureflip:featureflip-openfeature on Maven Central, and it wraps the Featureflip Java SDK, so your call sites talk to the standard OpenFeature client and swapping vendors becomes a provider registration rather than a rewrite. Register it with setProviderAndWait rather than setProvider, for the same reason as every other runtime: the plain form returns before flags have loaded, and the evaluations on the lines after it can hand back their defaults. - [OpenFeature provider for Go](https://featureflip.io/changelog/#openfeature-go) (2026-09-06): Go joins Node.js, .NET and Python behind the OpenFeature API. The module is github.com/canopy-labs/featureflip-go-openfeature, and it wraps the Featureflip Go SDK, so your call sites talk to the standard OpenFeature client and swapping vendors becomes a provider registration rather than a rewrite. Register it with SetProviderAndWait rather than SetProvider, for the same reason as in Node and Python: the plain form initializes on a background goroutine and returns before flags have loaded. - [OpenFeature provider for Python](https://featureflip.io/changelog/#openfeature-python) (2026-08-28): Python joins Node.js and .NET behind the OpenFeature API. The provider is on PyPI as featureflip-openfeature-provider, and it wraps the Featureflip Python SDK, so your call sites talk to the standard OpenFeature client and swapping vendors becomes a provider registration rather than a rewrite. Register it with set_provider_and_wait rather than set_provider. The second one returns before the first flag load has finished, and the evaluations on the lines after it can hand back their defaults. - [One date grammar across every SDK](https://featureflip.io/changelog/#date-operand-parity) (2026-08-26): A Before or After targeting rule now reads its date the same way in every SDK. Until this release each one leaned on its own language date parser, so a single saved rule could serve one variation to a service written in C# and a different one to a service written in Go. Every SDK now accepts ISO-8601 or a Unix timestamp in seconds, and rejects everything else, including the US-style and slash-separated formats the .NET SDK used to allow. The same run of releases also fixed analytics delivery: a batch the events endpoint refuses now goes back on the queue instead of being discarded. - [Evaluation inspectors across the server SDKs](https://featureflip.io/changelog/#evaluation-inspectors) (2026-07-29): Inspectors let you watch every flag evaluation from inside your own process. Register a callback and it fires on each variation call with the flag key, the context you passed, the value the caller received, the variation key, the reason, and whichever rule or prerequisite decided it. This is the piece you need to send exposure data to an analytics tool without hand-wrapping every call site. - [Terraform provider on the Registry](https://featureflip.io/changelog/#terraform-provider) (2026-07-25): The Featureflip provider is published on the Terraform Registry at v0.1.0. Projects, environments, flags, variations, targeting rules, segments and SDK keys are all resources, so your flag configuration goes through the same version control and review that the rest of your infrastructure already does. The provider is open source in its own repository and talks to the public API, which means it runs against the free plan too. - [OpenFeature providers for Node.js and .NET](https://featureflip.io/changelog/#openfeature-providers) (2026-07-14): OpenFeature is the CNCF vendor-neutral API for feature flags. Two providers now sit behind it, @featureflip/openfeature-node on npm and Featureflip.OpenFeature on NuGet. Your call sites talk to the OpenFeature client instead of ours, which turns swapping vendors into a provider registration rather than a rewrite. That cuts both ways and we ship it anyway, because a team weighing a small vendor is right to want a cheap exit. - [Manage flags from Claude Code and Cursor](https://featureflip.io/changelog/#mcp-server) (2026-07-10): The @featureflip/mcp server puts flag management inside any editor or agent that speaks the Model Context Protocol. You say what you want in English and the agent calls the Management API for you: create a flag, check where it is enabled, add a targeting rule, archive the dead ones. Most established vendors ship an MCP server now. Ours works on the free plan. - [Management API, on every plan](https://featureflip.io/changelog/#management-api) (2026-07-09): Everything the dashboard does is available over REST at api.featureflip.io. Projects, environments, flags, variations, toggles, targeting rules, segments and SDK keys each have endpoints under /api/v1, authenticated with a bearer token. It is on every plan, the free one included, on the view that a configuration you cannot read out programmatically is a configuration you do not really own. ## Glossary - [Feature Flag Glossary](https://featureflip.io/glossary/): Plain-English definitions of feature flag terms and how they relate. - [Feature flag](https://featureflip.io/glossary/feature-flag/): A feature flag is a conditional in your code whose value is controlled from a remote dashboard, letting you turn functionality on or off without deploying new code. - [Feature toggle](https://featureflip.io/glossary/feature-toggle/): Feature toggle is another name for a feature flag — a runtime switch that turns functionality on or off without a code deploy. The terms are interchangeable. - [Percentage rollout](https://featureflip.io/glossary/percentage-rollout/): A percentage rollout serves a feature to a defined share of users — chosen by a deterministic hash — so the same users stay in the cohort as you ramp the percentage up. - [Kill switch](https://featureflip.io/glossary/kill-switch/): A kill switch is a feature flag used to disable functionality instantly in production — flip it off and every SDK stops running the risky code path within seconds, no redeploy required. - [Dark launch](https://featureflip.io/glossary/dark-launch/): A dark launch ships a feature to production turned off or invisible to users, so the code runs in the live environment before anyone sees it — you reveal it later on your own schedule. - [Canary release](https://featureflip.io/glossary/canary-release/): A canary release exposes a new version to a small group of users first and watches its metrics before rolling it out to everyone — so problems surface on a fraction of traffic instead of the whole fleet. - [Progressive delivery](https://featureflip.io/glossary/progressive-delivery/): Progressive delivery is the practice of releasing software gradually and reversibly — using feature flags, canary releases, and percentage rollouts to expand exposure step by step while watching metrics, instead of shipping to everyone at once. - [A/B testing](https://featureflip.io/glossary/a-b-testing/): A/B testing serves two variations to randomly assigned groups of users and measures which one performs better on a chosen metric — turning a product decision into a controlled experiment instead of a guess. - [Experimentation](https://featureflip.io/glossary/experimentation/): Experimentation is the practice of making product decisions from controlled experiments — running A/B and multivariate tests, measuring outcomes against a hypothesis, and shipping the version the data supports rather than the one with the loudest advocate. - [Trunk-based development](https://featureflip.io/glossary/trunk-based-development/): Trunk-based development is a branching model where everyone commits small, frequent changes straight to a single shared branch — keeping integration continuous and avoiding the merge pain of long-lived feature branches. - [Stale flag](https://featureflip.io/glossary/stale-flag/): A stale flag is a feature flag that no longer makes a live decision — it serves one variation to everyone, receives no traffic, or was never used — yet still exists as a conditional branch in code. - [Flag debt](https://featureflip.io/glossary/flag-debt/): Flag debt is the accumulated maintenance burden of feature flags that have outlived their purpose but still sit in the codebase as conditional branches nobody has removed. - [Multivariate testing](https://featureflip.io/glossary/multivariate-testing/): Multivariate testing compares more than two variations at once — often combinations of several changes — to find which performs best, extending an A/B test beyond a single either/or split. - [Segment targeting](https://featureflip.io/glossary/segment-targeting/): Segment targeting serves a flag variation to a named, reusable group of users defined by shared attributes — like "beta users" or "EU customers" — instead of listing individuals one by one. - [Flag evaluation](https://featureflip.io/glossary/flag-evaluation/): Flag evaluation is the process an SDK runs to decide which variation a feature flag returns for a given user — applying prerequisites, targeting rules, and rollouts to the user context. - [Targeted rollout](https://featureflip.io/glossary/targeted-rollout/): A targeted rollout releases a feature to a specific audience — defined by user attributes or a segment — rather than to a random percentage of everyone, so the right users get it first. - [Feature management](https://featureflip.io/glossary/feature-management/): Feature management is the practice, and the category of tools, for running feature flags as a system: defining, targeting, rolling out, and retiring them from one place without redeploying. - [Remote config](https://featureflip.io/glossary/remote-config/): Remote config stores application settings on a server so you can change them without shipping a release, using the same delivery mechanism a feature flag does but for values like limits, copy, and thresholds rather than on/off decisions. - [Variation](https://featureflip.io/glossary/variation/): A variation is one of the possible values a feature flag can return — true or false for a boolean flag, or one of several strings, numbers, or JSON objects for a multivariate flag. - [Sticky bucketing](https://featureflip.io/glossary/sticky-bucketing/): Sticky bucketing assigns each user to a flag variation with a deterministic hash of their identifier, so the same user always lands in the same bucket and stays there even as you raise a rollout percentage. - [Blue-green deployment](https://featureflip.io/glossary/blue-green-deployment/): A blue-green deployment runs two identical production environments — one live, one holding the new release — and switches all traffic over at once, with an instant switch back if the new version misbehaves. - [OpenFeature](https://featureflip.io/glossary/openfeature/): OpenFeature is a CNCF open standard that defines one vendor-neutral API for evaluating feature flags, with a swappable provider behind it, so changing flag vendors becomes a configuration change instead of a rewrite. - [Model Context Protocol (MCP)](https://featureflip.io/glossary/model-context-protocol/): The Model Context Protocol is an open standard for giving AI assistants callable tools, and an MCP server for feature flags lets an assistant like Claude Code or Cursor create, toggle, and clean up flags without leaving the editor. - [Flags as code](https://featureflip.io/glossary/flags-as-code/): Flags as code is the practice of declaring feature flag configuration in version-controlled files, so flags, variations, segments, and targeting rules are reviewed in pull requests and applied by CI rather than edited in a dashboard. - [Continuous delivery](https://featureflip.io/glossary/continuous-delivery/): Continuous delivery is the practice of keeping every change in a deployable state and automating the path to production, so shipping becomes a routine decision rather than a scheduled event. - [Beta testing](https://featureflip.io/glossary/beta-testing/): Beta testing puts a pre-release feature in front of a limited group of real users to gather feedback and find defects under real conditions, before it reaches everyone. - [Dogfooding](https://featureflip.io/glossary/dogfooding/): Dogfooding is the practice of running your own unreleased features internally, so your team hits the defects before any customer does. - [Client-side testing](https://featureflip.io/glossary/client-side-testing/): Client-side testing decides the variation inside the user's browser or mobile app, using a client SDK and a client key that can read only the flags you have marked visible to the client. - [Server-side testing](https://featureflip.io/glossary/server-side-testing/): Server-side testing decides the variation in your own backend before the response leaves it, using a server SDK and a server key that can read every flag in the project. ## Questions - [Feature Flag Questions](https://featureflip.io/questions/): Short answers to the things that go wrong with feature flags in practice, each naming the causes in the order they occur. - [Can I use one SDK key for every environment?](https://featureflip.io/questions/can-i-use-one-sdk-key-for-every-environment/): No, and the key is not a credential you could reuse even if you wanted to. It is the selector: whichever environment issued the key is the configuration your process receives. Point staging at the production key and staging reads production flag states, which means a rollout you start in staging is a rollout in production. - [Do I need a user ID to evaluate a feature flag?](https://featureflip.io/questions/do-i-need-a-user-id-to-evaluate-a-feature-flag/): Not for on/off flags or targeting rules that match on other attributes. You need one for percentage rollouts, because the bucket comes from hashing the identifier with the flag key. Without it a server SDK evaluating locally serves the first (control) variation, while the hosted evaluation endpoint spreads anonymous traffic by weight with no per-user stickiness. - [Do users lose a feature if I lower the rollout?](https://featureflip.io/questions/do-users-lose-a-feature-if-i-lower-the-rollout/): Yes. Buckets are fixed per user, so lowering a rollout from 50% to 20% keeps everyone in buckets 0 through 19 and removes everyone from 20 through 49. It is deterministic, not a reshuffle, which is why raising the percentage again restores exactly the same people. Users who lose access see the feature disappear mid-session unless you evaluate once per session and cache the result. - [Does changing a targeting rule re-bucket users?](https://featureflip.io/questions/does-changing-a-targeting-rule-re-bucket-users/): No. A user bucket comes from a salt stored on the flag and the user key, so editing rules, adjusting weights or adding conditions leaves every assignment untouched. Two things do reassign everybody: changing the attribute a rollout buckets by, and deleting a flag and recreating it, because a new flag gets a new salt. - [How do I test code that uses feature flags?](https://featureflip.io/questions/how-do-i-test-code-that-uses-feature-flags/): Use the test client each SDK provides. You construct it with a map of flag keys to values and it evaluates against that map, with no network calls and no initialization step. It is not registered in the normal client cache, so every call returns an independent instance and tests cannot leak state into each other. - [What if I archive a flag still used in my code?](https://featureflip.io/questions/what-happens-when-i-archive-a-flag-still-in-my-code/): Archiving removes the flag from the configuration SDKs receive, so every remaining call site immediately falls back to the default value passed at that call site. Nothing throws and nothing logs an error, because the SDK cannot tell an archived flag from one that never existed. Remove the code first, then archive. - [Why can't my browser SDK see a feature flag?](https://featureflip.io/questions/why-cant-my-browser-sdk-see-a-feature-flag/): Because the flag is not marked client-side visible. Client SDK keys are public by design, so they only ever receive flags you have explicitly opted in. A server key sees every flag in the project, which is why the same key works from your backend and fails in the browser. The client SDK reports the flag as not found rather than raising. - [Why did my flag change take minutes to reach my app?](https://featureflip.io/questions/why-did-my-flag-change-take-minutes-to-reach-my-app/): Because the streaming connection is not established, so the client picks the change up on its next poll instead. Streaming is on by default and delivers changes within seconds, so a delay of roughly thirty seconds points at the poll interval taking over. Proxies that buffer responses and HTTP clients with a short timeout are the usual reasons the stream drops. - [Why did my targeting rule not match?](https://featureflip.io/questions/why-did-my-targeting-rule-not-match/): Usually one of three things: an earlier rule matched first and stopped evaluation, the attribute your rule tests was never included in the evaluation context, or the value is present but a different type or case than the rule expects. Rules run top to bottom and the first match wins, so rule order is part of the logic. - [Why didn't the cleanup Action remove my flag?](https://featureflip.io/questions/why-didnt-the-cleanup-action-remove-my-flag/): Almost always because your code reads the flag through your own wrapper function instead of calling the SDK directly. Matching is by method name plus key string, so a wrapper is invisible to the rules and the run reports no changes. The other common causes are a refusal it prints explicitly, such as a mock stub holding the flag read, or a key that is not a string literal at the read site. - [Why do teammates get different variations?](https://featureflip.io/questions/why-do-users-on-the-same-team-get-different-variations/): Because a rollout buckets by user key by default, and each user hashes independently. Two colleagues in the same workspace are two separate users, so a 50% rollout splits them roughly half the time. Set the rollout to bucket by an account or organization attribute instead, and everyone sharing that value moves together. - [Why do two SDKs return different variations?](https://featureflip.io/questions/why-do-two-sdks-return-different-variations/): Almost always because the evaluation context is keyless in one of them. Bucketing needs a stable user key, and the two evaluation paths handle its absence differently on purpose: a server SDK evaluating locally serves the first variation, while the hosted endpoint assigns a fresh random bucket per call. Pass the same user key everywhere and the two agree, because every SDK runs the same hash. - [Why do two users get different variations?](https://featureflip.io/questions/why-do-two-users-get-different-variations-in-the-same-rollout/): In a percentage rollout that is the expected behaviour. Each user is hashed together with the flag key to produce a bucket from 0 to 100, so a 30% rollout puts roughly three users in ten on the new variation. The same user always lands in the same bucket for the same flag. Different flags hash independently, so being in the 30% for one says nothing about another. - [Why does my flag flash the wrong value on load?](https://featureflip.io/questions/why-does-my-flag-flash-the-wrong-value-on-page-load/): Because the browser SDK returns the default value you passed until its first flag payload has arrived, and your UI renders during that window. The reason string is FlagNotFound rather than an error, since the flag is simply absent from an empty snapshot. Wait for initialization before rendering the gated region, or render a neutral state until the client is ready. - [Why does my flag work in dev but not production?](https://featureflip.io/questions/why-does-my-flag-work-in-development-but-not-production/): Because every environment holds its own configuration, and enabling a flag in development changes nothing in production. Targeting rules and rollout percentages are per environment as well, so a flag can be on in both and still serve different values. A new environment starts every existing flag in the off state deliberately, so nothing goes live by accident. - [Why does my flag work locally but not in Docker?](https://featureflip.io/questions/why-does-my-feature-flag-work-locally-but-not-in-docker/): Almost always because the SDK key did not reach the container. A key read from a local env file that is not passed through in your compose file or Dockerfile arrives empty, and the SDK serves your default value rather than failing loudly. The second cause is outbound network: a container on an internal-only network cannot reach the evaluation endpoint, so the first payload never arrives. - [Why doesn't my rollout hit the percentage I set?](https://featureflip.io/questions/why-doesnt-my-rollout-hit-the-percentage-i-set/): Because bucketing assigns each user a fixed number from 0 to 99 and counts how many land under your threshold. It does not meter traffic. With a few hundred users the observed share can sit several points either side of the configured one, and that is expected. Persistent skew usually means anonymous contexts, which the hosted endpoint spreads randomly on every call instead of bucketing. - [Why doesn't my segment match any users?](https://featureflip.io/questions/why-doesnt-my-segment-match-any-users/): Usually because the rule cannot resolve the segment at all, which fails closed and matches nobody. A client SDK that was never given segment data behaves the same way. If the segment does resolve, the next suspect is condition logic: segments use one flat condition list with a single AND or OR, so a segment built to catch two different user groups with AND matches nobody by construction. - [Why doesn't my semver targeting rule match?](https://featureflip.io/questions/why-doesnt-my-semver-targeting-rule-match/): Because the value you are sending does not parse as a semantic version. An unparseable string matches nothing rather than falling back to text comparison, which is why the rule looks dead instead of behaving oddly. A leading v is fine and 2.0 compares equal to 2.0.0, but a build number like 1042 or a date will never satisfy a semver condition. - [Why is my feature flag returning the default value?](https://featureflip.io/questions/why-is-my-feature-flag-returning-the-default-value/): Almost always because the SDK cannot find the flag, not because evaluation failed. The usual causes, in order: the SDK key belongs to a different environment, the flag is off in that environment, the key is misspelled, the client has not finished initializing, the requested type does not match the variation type, or the flag is not marked client-side visible and you are asking from a browser. - [Why is my feature flag returning the wrong type?](https://featureflip.io/questions/why-is-my-feature-flag-returning-the-wrong-type/): Because the SDKs do not coerce between types. If the variation holds a string and you call the boolean method, you get the default you passed rather than a converted value. The dashboard shows the flag serving one thing while your code reports another, which looks like a stale cache and is actually a type mismatch. - [Why is my flag evaluation returning an error?](https://featureflip.io/questions/why-is-my-flag-evaluation-returning-an-error/): Because the evaluator picked a variation key the flag no longer defines, which normally means a rule or fallthrough still references a deleted variation. The SDK serves the default value you passed and reports Error rather than guessing. A variation that exists but holds a null value is not this case, so the reason string is a reliable way to tell a config problem from a data one. ## Blog - [Automated Feature Flag Removal: What a Bot Must Refuse](https://featureflip.io/blog/automated-feature-flag-removal/): Detecting a dead feature flag is easy. Deleting it safely is not. What automated feature flag removal has to refuse in order to be worth trusting. - [Trunk-Based Development with Feature Flags: What CI Misses](https://featureflip.io/blog/feature-flags-trunk-based-development/): Trunk-based development with feature flags moves risk from merge day to flag-flip day. A green trunk only proves the off path works. Here is the rest. - [Self-Hosted Feature Flags: When Running Your Own Wins](https://featureflip.io/blog/self-hosted-feature-flags/): Self-hosted feature flags trade a license fee for an availability problem: your kill switch ends up inside the blast radius it exists to protect you from. - [GitOps for Feature Flags: How the Workflow Actually Runs](https://featureflip.io/blog/gitops-feature-flags/): Run feature flag config through git: where it lives, what a reviewer checks, how CI applies it, and why some configuration drift is correct and should stay. - [OpenFeature Feature Flags: Node, .NET, Python, Go, Java](https://featureflip.io/blog/openfeature-feature-flags/): OpenFeature feature flags in Node.js, .NET, Python, Go and Java: set up the Featureflip provider, map evaluation context, keep call sites vendor-neutral. - [Feature Flags as Code: Managing Featureflip with Terraform](https://featureflip.io/blog/feature-flags-as-code-terraform/): Manage feature flags as code with the Featureflip Terraform provider: declare projects, flags, and targeting in .tf files, and know what to leave out. - [Feature Flag Outages: How SDKs Recover and Resync](https://featureflip.io/blog/feature-flag-outage-recovery/): A feature flag outage is survivable when SDKs evaluate from cache and fall back to your defaults. The costly failure is an SDK that never reconnects after. - [MCP Server for Managing Feature Flags in Claude Code](https://featureflip.io/blog/feature-flags-mcp-server/): The Featureflip MCP server lets Claude Code, Cursor, and other AI agents create flags, ramp rollouts, and clean up stale ones without leaving your editor. - [Feature Flags for AI Apps: Roll Out a New LLM Model Safely](https://featureflip.io/blog/feature-flags-for-ai-apps/): Feature flags for AI apps: put the model, prompt, and settings behind one flag, roll a new LLM out with sticky bucketing, and keep a fail-safe kill switch. - [Feature Flag Management API: Automate Flags with REST](https://featureflip.io/blog/feature-flag-management-api/): Create projects, flags, and targeting rules programmatically with the Featureflip feature flag API. Seed flags in CI, sync environments, build internal tools. - [Feature Flag Naming Conventions: A Practical Guide](https://featureflip.io/blog/feature-flag-naming-conventions/): Feature flag naming conventions that hold up: the anatomy of a good key, how to enforce it in CI, how to scale it by team size, and how to fix bad names. - [Dark Launch and Soft Rollout: Ship Code Before the Feature](https://featureflip.io/blog/dark-launches-and-soft-rollouts/): A dark launch ships a feature to production with nobody seeing it. A soft rollout then reveals it a few users at a time. How to run both with feature flags. - [Python Feature Flags: A Fork-Safe Gunicorn and uWSGI Setup](https://featureflip.io/blog/feature-flags-in-python/): Python feature flags without the pre-fork trap: local in-memory evaluation, why Gunicorn and uWSGI silently freeze flags, and where to build the client. - [Go Feature Flags: In-Process Evaluation, No cgo or Sidecar](https://featureflip.io/blog/feature-flags-in-go/): Go feature flags with a pure-Go SDK: no cgo, no dependencies, in-process evaluation with no per-request network call, goroutine-safe reads, clean shutdown. - [Node.js Feature Flags: Local Evaluation, Long-Lived Server](https://featureflip.io/blog/feature-flags-in-nodejs/): Node.js feature flags in a long-lived server: one shared client, local in-memory evaluation, readiness gating on boot, and a clean shutdown on SIGTERM. - [Next.js Feature Flags: Server-Side Evaluation, No Flash](https://featureflip.io/blog/feature-flags-in-nextjs/): Next.js feature flags without the hydration flash: evaluate in a Server Component or getServerSideProps, then seed the client hook so it keeps updating live. - [React Feature Flags: Provider, Hooks, and Live Updates](https://featureflip.io/blog/feature-flags-in-react/): React feature flags with a provider and a useFeatureFlag hook that re-renders on change, plus user targeting and tests that never touch the network. - [Feature Flag Flat Pricing vs Per-Seat and Usage-Based](https://featureflip.io/blog/feature-flag-pricing-explained/): Feature flag flat pricing versus per-seat and usage-based: how each model scales as your team and traffic grow, with a real cross-vendor cost comparison. - [Build vs Buy Feature Flags: A Decision Framework](https://featureflip.io/blog/build-vs-buy-feature-flags/): Build vs buy feature flags: a homegrown one starts as an if-statement, then grows into targeting, SDKs, audit logs, and cleanup nobody owns. What each costs. - [Progressive Delivery Explained: The Two-Pillar Playbook](https://featureflip.io/blog/progressive-delivery-explained/): Progressive delivery has two pillars: release progression and progressive delegation. How feature flags turn a deploy into a dial you can turn up slowly. - [Feature Flag Best Practices: 8 Rules for Production Teams](https://featureflip.io/blog/feature-flag-best-practices/): Eight feature flag best practices for production teams: lifecycle tagging, flat decisions, both-state testing, progressive rollouts, observability, and cleanup. - [Prerequisite Flags: Gate One Flag on Another, No Glue Code](https://featureflip.io/blog/prerequisite-flags/): Featureflip supports first-class prerequisite flags. A child flag stays off until its parent serves the right variation, with no application-side gating. - [Feature Flag Anti-Patterns: 9 Mistakes Behind Real Outages](https://featureflip.io/blog/feature-flag-anti-patterns/): Nine feature flag anti-patterns behind real outages — Knight Capital's $460M loss, Slack's day-long cascade, Google Cloud's June 2025 crash. Each with a fix. - [Feature Flag Cleanup: A Playbook for Paying Down Flag Debt](https://featureflip.io/blog/feature-flag-cleanup/): Most feature flags are never removed, and one reused bit cost Knight Capital $460M. The four-step playbook to clean up flag debt safely. - [Feature Flags vs Environment Variables: A Practical Guide](https://featureflip.io/blog/feature-flags-vs-environment-variables/): Env vars configure where the process runs; flags decide what each request sees. Decision rule, comparison table, and 4 production gotchas inside. ## Docs - [Getting Started](https://featureflip.io/docs/): Learn how to use Featureflip to manage feature flags, target users, and roll out features safely. ## Concepts - [What Are Feature Flags?](https://featureflip.io/docs/concepts/feature-flags/): What feature flags are, how they work, and why modern teams use them to ship safely. - [Rollout Strategies](https://featureflip.io/docs/concepts/rollout-strategies/): Percentage-based rollouts, canary releases, and fixed serving. - [User Targeting & Segments](https://featureflip.io/docs/concepts/targeting/): Target specific users and groups with targeting rules, percentage rollouts, and reusable segments. - [Prerequisite Flags](https://featureflip.io/docs/concepts/prerequisites/): Gate one flag on another flag's variation, enforced inside the evaluator before targeting rules run. - [Environments](https://featureflip.io/docs/concepts/environments/): Manage separate feature flag configurations for development, staging, and production. - [Stale Flag Detection](https://featureflip.io/docs/concepts/stale-flags/): How Featureflip automatically classifies flags as Active, Stale, or Dead from real evaluation traffic. - [Reliability & Resilience](https://featureflip.io/docs/concepts/reliability/): What the SDKs do when the service is slow or unavailable — local evaluation, cached values, safe defaults, and graceful streaming fallback. ## Guides - [Creating Feature Flags](https://featureflip.io/docs/guides/creating-flags/): Step-by-step guide to creating and managing feature flags. - [Setting Up Targeting Rules](https://featureflip.io/docs/guides/targeting-rules/): Create targeting rules that serve different variations to specific users. - [Setting Prerequisite Flags](https://featureflip.io/docs/guides/prerequisites/): Add and manage prerequisites in the dashboard to gate one flag on another. - [Using Segments](https://featureflip.io/docs/guides/segments/): Create reusable user segments for targeting across multiple flags. - [Managing Environments](https://featureflip.io/docs/guides/environments/): Create and manage environments for your feature flag configurations. - [Scheduled Changes](https://featureflip.io/docs/guides/scheduled-changes/): Queue a flag to turn on or off automatically at a future time, view pending and recent changes, and cancel a pending change before it applies. - [Team Management](https://featureflip.io/docs/guides/team-management/): Invite team members, manage roles, and configure your organization. - [Account Security](https://featureflip.io/docs/guides/account-security/): Enable two-factor authentication (TOTP authenticator app plus recovery codes) and sign in with Google. - [Audit Log](https://featureflip.io/docs/guides/audit-log/): See who changed what and when — every flag, rule, environment, and key change with before/after values, with retention by plan. - [Flag Cleanup Action](https://featureflip.io/docs/integrations/flag-cleanup-action/): Remove dead feature flag code with a GitHub Action that opens one reviewable pull request per flag across thirteen languages, then archives the flag when the pull request merges. - [MCP Server](https://featureflip.io/docs/integrations/mcp/): Manage feature flags from Claude Code, Cursor, and other AI agents with the @featureflip/mcp Model Context Protocol server. - [OpenFeature](https://featureflip.io/docs/integrations/openfeature/): Evaluate Featureflip flags through the CNCF vendor-neutral OpenFeature standard, with providers for the Node.js, .NET, Python, Go and Java SDKs. - [Terraform Provider](https://featureflip.io/docs/integrations/terraform/): Manage projects, environments, feature flags, targeting rules, segments, and SDK keys as code with the canopy-labs/featureflip Terraform provider. ## Quickstarts - [JavaScript / TypeScript](https://featureflip.io/docs/quickstart/javascript/): Add feature flags to your JS/TS app in under 5 minutes. - [Python](https://featureflip.io/docs/quickstart/python/): Add feature flags to your Python app in under 5 minutes. - [C# / .NET](https://featureflip.io/docs/quickstart/csharp/): Add feature flags to your C# or .NET app in under 5 minutes. - [Java](https://featureflip.io/docs/quickstart/java/): Add feature flags to your Java app in under 5 minutes. - [Go](https://featureflip.io/docs/quickstart/go/): Add feature flags to your Go app in under 5 minutes. - [Node.js](https://featureflip.io/docs/quickstart/nodejs/): Add feature flags to your Node.js app in under 5 minutes. - [PHP](https://featureflip.io/docs/quickstart/php/): Add feature flags to your PHP app in under 5 minutes. - [Ruby](https://featureflip.io/docs/quickstart/ruby/): Add feature flags to your Ruby app in under 5 minutes. - [Swift](https://featureflip.io/docs/quickstart/swift/): Add feature flags to your iOS/macOS app in under 5 minutes. - [Flutter](https://featureflip.io/docs/quickstart/flutter/): Add feature flags to your Flutter app in under 5 minutes. - [Android](https://featureflip.io/docs/quickstart/android/): Add feature flags to your Android app in under 5 minutes. ## SDK References - [SDK Overview](https://featureflip.io/docs/sdks/overview/): Choose the right SDK — server-side for backends, client-side for browsers and mobile. - [JavaScript / TypeScript SDK](https://featureflip.io/docs/sdks/javascript/): Initialization, flag evaluation, streaming, and configuration. - [Node.js SDK](https://featureflip.io/docs/sdks/nodejs/): Initialization, flag evaluation, streaming, and configuration. - [Python SDK](https://featureflip.io/docs/sdks/python/): Initialization, flag evaluation, context, and configuration. - [C# SDK](https://featureflip.io/docs/sdks/csharp/): Initialization, flag evaluation, dependency injection, and configuration. - [Java SDK](https://featureflip.io/docs/sdks/java/): Initialization, flag evaluation, context, and configuration. - [Go SDK](https://featureflip.io/docs/sdks/go/): Initialization, flag evaluation, context, and configuration. - [PHP SDK](https://featureflip.io/docs/sdks/php/): Initialization, flag evaluation, context, and configuration. - [Ruby SDK](https://featureflip.io/docs/sdks/ruby/): Initialization, flag evaluation, context, and configuration. - [Browser SDK](https://featureflip.io/docs/sdks/browser/): Framework-agnostic feature flag evaluation for browser apps. - [React SDK](https://featureflip.io/docs/sdks/react/): React bindings with provider and hooks for feature flag evaluation. - [Swift SDK](https://featureflip.io/docs/sdks/swift/): Feature flag evaluation for iOS, macOS, tvOS, and watchOS. - [Flutter SDK](https://featureflip.io/docs/sdks/flutter/): Feature flag evaluation for Flutter apps on iOS, Android, web, and desktop. - [Android SDK](https://featureflip.io/docs/sdks/android/): Feature flag evaluation for Android and Kotlin/JVM apps. ## API Reference - [Evaluation API Overview](https://featureflip.io/docs/api/overview/): REST API reference for building custom SDKs or integrating directly. - [Evaluate Endpoint](https://featureflip.io/docs/api/evaluate/): Evaluate a feature flag for a given user context. - [Flags Endpoint](https://featureflip.io/docs/api/flags/): Fetch feature flag configurations. - [Events Endpoint](https://featureflip.io/docs/api/events/): Record SDK analytics events. - [Streaming Endpoint](https://featureflip.io/docs/api/streaming/): Subscribe to real-time flag updates via Server-Sent Events (SSE). - [Evaluation API OpenAPI Spec](https://featureflip.io/openapi/evaluation-v1.json): The OpenAPI 3.0 document the Evaluation API reference is generated from, served as raw JSON for client generators and agents. ## Management API - [Management API Overview](https://featureflip.io/docs/management-api/overview/): REST API for configuring Featureflip programmatically — projects, environments, flags, targeting, segments, and SDK keys. - [Authentication](https://featureflip.io/docs/management-api/authentication/): Personal Access Tokens and organization-scoped Service Tokens, sent as bearer tokens. - [Quickstart](https://featureflip.io/docs/management-api/quickstart/): Create a project, environment, and flag, enable it, and add a targeting rule in a few requests. - [Conventions](https://featureflip.io/docs/management-api/conventions/): Versioning, key/slug addressing, cursor pagination, the error envelope, rate limits, idempotency, and hypermedia actions. - [Errors](https://featureflip.io/docs/management-api/errors/): Every stable error code and how to resolve it. - [API Reference](https://featureflip.io/docs/management-api/reference/): OpenAPI-generated reference for every endpoint, request, and response. - [Management API OpenAPI Spec](https://featureflip.io/openapi/public-v1.json): The OpenAPI 3.0 document behind the Management API reference, served as raw JSON for client generators and agents.