# Featureflip > Featureflip is a feature flag platform that removes its own dead flags: a GitHub Action opens one pull request per stale flag. Flat priced, nothing metered. Free to start, with SDKs for JavaScript, Node.js, Cloudflare Workers, Python, C#, Java, Go, PHP, Ruby, the browser, React, Swift, Flutter and Android. - [Full site text for LLMs](https://featureflip.io/llms-full.txt): The whole site's text in one file, including the comparison tables, alternatives guides, cost calculators, glossary definitions and question answers. Pricing, comparison and product pages come first and the blog and docs last. Legal pages and the generated API reference are left out, since the OpenAPI specs listed below cover the API. ## For AI agents - [Using the Management API from an AI agent](https://featureflip.io/docs/management-api/agents/): The short path for a coding agent. A person signs up, confirms the email address, creates a Service Token (Organization Settings, Service Tokens) or a Personal Access Token (Settings, API Tokens) in the dashboard and hands it over as FEATUREFLIP_TOKEN, because tokens are created only there. With it the agent calls https://api.featureflip.io/api/v1 with Authorization: Bearer, checks GET /api/v1/me, reads its organization key from GET /api/v1/orgs, and works in the project keyed default that every new organization starts with (development and production environments on Free, which allows one project). It creates flags with POST /api/v1/orgs/{org}/projects/default/flags and mints an SDK key for its app with POST /api/v1/orgs/{org}/projects/default/environments/{env}/sdk-keys. A create past a plan cap returns 403 plan_limit_reached. - [Management API OpenAPI Spec](https://featureflip.io/openapi/public-v1.json): Every /api/v1 endpoint, request and response. - [API Onboarding Descriptor](https://featureflip.io/.well-known/api-onboarding): Plans, credential types and the token-to-SDK-key flow in machine-readable form. - [MCP Server](https://featureflip.io/docs/integrations/mcp/): The same API as MCP tools, configured with the same FEATUREFLIP_TOKEN. ## 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 twelve languages plus ERB and Blade templates 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, scheduled changes, flag lifecycle (expiry dates, flag owners, cleanup notice emails), outbound webhooks, single sign-on, 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. Available on the Team plan and above. - [Flag Lifecycle](https://featureflip.io/product/features/flag-lifecycle/): Keep temporary feature flags temporary. Set an expiry date on a flag, or a default lifetime for a project that dates every temporary flag without one (every plan). Once it passes, the flag is marked Expired and reported stale with the reason PastExpiry, while evaluation is unchanged. Name an owner for each flag (Pro and above), and reassign a departing member's flags when they are removed. Below Pro the creator is recorded as owner automatically. On Team and above, a daily cleanup notice email names flags that have expired or gone dead, sent to the flag's owner or, for unowned flags and on Team, to the organization's Owners and Admins, with an opt-out in email preferences. Stale and dead flag detection from hourly evaluation traffic, and the flag cleanup GitHub Action opening one pull request per dead flag, complete the loop. A passed expiry date alone never opens a removal pull request. Flags marked permanent (kill switches, ops toggles) are left out of stale reports, cleanup notices and removal pull requests, on every plan. - [Feature Flag Webhooks](https://featureflip.io/product/features/webhooks/): Outbound webhooks send a signed HTTP request to your endpoint, a message to a Slack channel, a change event to Datadog or an annotation to Grafana, whenever a flag, targeting rule, variation, segment, environment, project, SDK key, API token or the organization changes. HMAC-signed deliveries with rotatable signing secrets, filters by event type, project and environment, automatic retries, a delivery log with manual redelivery, and test events. Managed from the dashboard, the /api/v1 Management API, the MCP server (list_webhooks, manage_webhook, list_webhook_deliveries, deliver_webhook) and the Terraform provider (featureflip_webhook). Endpoints per plan: 1 on Free, 3 on Team and Pro, unlimited on Business and Enterprise. - [Single Sign-On](https://featureflip.io/product/features/single-sign-on/): Single sign-on through your own identity provider over OpenID Connect, with setup guides for Okta and Microsoft Entra ID and support for any OIDC provider with a discovery document. Email domains verified by DNS TXT record, a test connection before activation, automatic provisioning with a default role (Viewer, Member or Admin), and a Require single sign-on setting that makes the IdP the only way into the organization while Owners keep a recovery sign-in. On the Business plan and Enterprise, with SAML and SCIM on Enterprise. Google and GitHub sign-in are available on every plan and are social sign-in, not SSO. - [Feature Flag SDKs](https://featureflip.io/product/features/sdks/): Official SDKs for 14 languages, frameworks and runtimes — server (JavaScript/TypeScript, Node.js, Cloudflare Workers, 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 except Cloudflare Workers streams config updates over SSE, and the Workers SDK refreshes a cached copy within 60s by default; one consistent variation API; identical results across SDKs (shared, vector-tested engine); fail-safe defaults; direct Evaluation API over HTTP for anything else. Measurement methodology for the sub-millisecond claim is published on the page: over the 30 days to 2026-09-19, 89% of production evaluations completed under 50us, 96% under 100us, 99.5% under 1ms, mean 0.054ms; the timing covers the evaluator only (rule and segment matching, rollout bucketing, prerequisite resolution) and excludes config loading, application code and network. - [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 (Free) 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, SDK keys, flag expiry dates, and outbound webhook subscriptions. 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 or GitHub on every plan, single sign-on through your own OIDC identity provider on Business, 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/): Free plan (free forever, up to 3 people, 1 project, 10 flags per project, 2 environments, 1 webhook endpoint, 7-day audit logs), Team from $49/month or $39/month billed annually (5 people, 3 projects, unlimited flags, 3 environments, scheduled changes, 3 webhook endpoints, 30-day audit logs), Pro from $99/month or $79/month annually (10 people, 10 projects, 5 environments, scheduled changes, flag owners, 3 webhook endpoints, 30-day audit logs), Business from $249/month or $199/month annually (25 people, 25 projects, unlimited environments, scheduled changes, flag owners, single sign-on with your own OIDC identity provider, unlimited webhook endpoints, 90-day audit logs, priority support). Enterprise is custom and adds SAML/SCIM and self-hosting. Every plan includes flag expiry dates, stale-flag detection, the flag cleanup GitHub Action, the Management API, the MCP server, the Terraform provider, two-factor authentication, and Google and GitHub sign-in. Cleanup notice emails are on Team and above. Nothing is metered: no per-seat, active-user or evaluation charges. - [About](https://featureflip.io/about/): Who builds Featureflip and why. Canopy Labs LLC, a bootstrapped software company in Atlanta, runs the hosted service and maintains all fourteen SDKs under the Apache 2.0 license. The page also sets out the principles behind the product: published pricing, flags treated as infrastructure, in-memory evaluation, open-source SDKs, and docs thorough enough to replace a sales demo. - [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, hand each exposure to your analytics tool through an evaluation inspector, and check the split in the flag's Analytics tab. 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 allowances, 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, plus a cleanup cost calculator for your stale flag backlog. Every vendor 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 30-user Pro ceiling accounted for, and compare it to Featureflip's flat price. Rates sourced and dated. - [Feature Flag Cleanup Cost Calculator](https://featureflip.io/tools/feature-flag-cleanup-cost-calculator/): Price a stale feature flag backlog from your own inputs only (flag counts, minutes per removal, hourly cost, carrying minutes per stale flag): the cost to clear it, its 12-month carrying cost, how fast it grows, the monthly cost of keeping up, and how many removals a cleanup tool needs to pay back its setup. No industry averages, every formula shown. Because a removal costs the same whenever it happens, the model treats the carrying cost as the whole cost of waiting. ## Changelog - [Changelog](https://featureflip.io/changelog/): Dated record of what shipped to the Featureflip platform, API, SDKs, and integrations, newest first. - [Server SDKs can start from a saved configuration](https://featureflip.io/changelog/#server-sdk-snapshot-store) (2026-11-07): The Node.js, Python, Go, C#, Java and Ruby SDKs can save the flag configuration they receive and load it on a later start if the Evaluation API is unreachable. A process that starts during an outage then serves your real targeting instead of code defaults, so a deploy or autoscaling event mid-outage no longer leaves new instances answering differently from old ones. It is opt-in. - [Flag cleanup opens merge requests on GitLab and Bitbucket](https://featureflip.io/changelog/#flag-cleanup-gitlab-bitbucket) (2026-11-07): Version 2.8.0 of the flag cleanup Action removes dead flags from repositories hosted on GitLab and Bitbucket Cloud as well as GitHub. It runs from a GitLab CI template, a Bitbucket Pipelines step, the CircleCI orb, or any CI that can run Docker, and opens one merge request or pull request per flag with the same rules it follows on GitHub. - [Compare environments and copy a flag between them](https://featureflip.io/changelog/#compare-and-copy-environments) (2026-11-06): A Compare page lists every flag whose configuration differs between two environments, and a flag can be copied from one environment into another after a preview. Compare is on every plan. Copy is on Team and above. Both work from the dashboard, the Management API and the MCP server. - [Flag triggers: let an alert flip a flag](https://featureflip.io/changelog/#flag-triggers) (2026-11-06): A trigger is a secret URL that turns one flag on or off in one environment when something calls it. Point a Grafana or Datadog alert at it and the kill switch flips without anyone being woken up to do it. Triggers are available on the Team plan and above. - [OpenFeature provider for Android](https://featureflip.io/changelog/#openfeature-android) (2026-11-03): Android apps can read Featureflip flags through the OpenFeature Kotlin SDK. The io.featureflip:featureflip-android-openfeature package wraps the Featureflip Android SDK and fetches flags for the user you set, so every read is a cache lookup and a user switch is one setEvaluationContext call. - [Cleanup reads OpenFeature React hooks and leaves JSX tidy](https://featureflip.io/changelog/#flag-cleanup-openfeature-react) (2026-10-28): Version 1.17.0 of the flag cleanup Action removes flags read through OpenFeature's React SDK, so useBooleanFlagValue goes the way useFeatureFlag already did. It also puts code back on one line where a removal made room, which leaves less reformatting for review. Version 1.18.0 then removes more of the C# gate plumbing that earlier versions kept when they couldn't prove a piece unused. - [See what a flag actually served](https://featureflip.io/changelog/#flag-evaluation-analytics) (2026-10-27): Every flag now has an Analytics tab. Pick an environment and a range of 7, 30 or 90 days, and it shows how many evaluations each variation got, day by day, and which targeting rule, rollout, default or off variation served them. The same breakdown is on /api/v1 and in the MCP server, so a script or an agent can check a rollout before widening it. Counts are evaluations, so one user evaluated ten times counts ten times. - [OpenFeature provider for the browser and React](https://featureflip.io/changelog/#openfeature-web) (2026-10-27): Browser and React apps can read Featureflip flags through the OpenFeature web SDK. The @featureflip/openfeature-web package wraps the Featureflip browser SDK and fetches flags for the user you set, which keeps every read synchronous and makes a user switch one setContext call. React reaches it through @openfeature/react-sdk. - [Removal pull requests fix the tests and comments around a flag](https://featureflip.io/changelog/#flag-cleanup-tests-and-comments) (2026-10-26): A removal used to leave the tests about a flag, and the comments describing it, for you to fix by hand. Versions 1.14.0 to 1.16.0 of the flag cleanup Action handle more of that in the same pull request. A TypeScript test about the removed branch is deleted, a kept test's title stops naming a flag that is gone, and comments that describe the flag's state are listed beside the code they sit next to. - [Rollouts skip a context they can't bucket](https://featureflip.io/changelog/#rollouts-skip-unbucketable-contexts) (2026-10-22): A percentage rollout needs a stable ID to put each user in the same bucket every time. A context without one used to get different answers depending on where it was evaluated: the hosted evaluation API drew a random bucket on every request, and the server SDKs served one fixed variation to all of them. Now the hosted API and every server SDK skip that rule, and the context moves on to the next matching rule or the flag's default. Browser and mobile SDKs already generate and keep an anonymous ID, so their visitors are still bucketed. - [Wrapper inlining reaches Python, Dart, PHP, Ruby and Swift](https://featureflip.io/changelog/#flag-cleanup-wrappers-every-language) (2026-10-21): The flag cleanup Action could already replace a call to a method that wraps one flag read with the value the flag serves, in Kotlin, Java, C#, Go, TypeScript and JavaScript. Versions 1.11.0 to 1.13.0 do the same in Python, Dart, PHP, Ruby and Swift, which covers every language a Featureflip SDK is written for. The same releases delete a comment that names only the removed flag, and versions 1.8.0 to 1.10.0 fix how a removed line treats the code around it. - [Evaluate feature flags inside a Cloudflare Worker](https://featureflip.io/changelog/#edge-sdk-cloudflare-workers) (2026-10-21): @featureflip/edge is a new SDK for Cloudflare Workers, Pages Functions included. It evaluates flags inside your Worker from a cached copy of your environment's config, held in the isolate's memory and in the Workers Cache API, so a request that finds a warm copy reads all of its flags with no network call. The engine is the one the JavaScript and Node.js SDKs run. A Worker can't keep a streaming connection open between requests, so flag changes reach edge traffic within 60 seconds by default. - [Bootstrap the browser and React SDKs for a first paint with real flags](https://featureflip.io/changelog/#browser-react-bootstrap) (2026-10-20): The browser and React SDKs 2.12.0 take a bootstrap option, so a page can render real flag values before the client has made a request. Pass the values your server SDK evaluated while rendering the page, or let the browser reuse the values it received on its last visit. Either way the client is ready at once, and the server's values replace the bootstrap ones as soon as they arrive. - [Cleanup removes the C# gate a flag leaves behind](https://featureflip.io/changelog/#flag-cleanup-csharp-gates) (2026-10-20): A C# flag often sits behind an interface: ICheckoutGate, a class that calls the SDK, a DI registration, and a constructor parameter in every service that asks for it. Earlier versions of the flag cleanup Action inlined the calls and left all of that standing, empty. Version 1.7.0 deletes it. All of it goes, down to the settings key in appsettings.json, once the Action can prove nothing else uses it. Go removal pull requests that would not have compiled are now fixed, or refused with the local named. PHP, Dart and C# shapes that used to be refused now fold, and a few folds that dropped a call or changed a string literal leave them alone. - [Plan caps get their own Management API error](https://featureflip.io/changelog/#management-api-plan-limit-reached) (2026-10-16): When a request would take an organization past its plan, the Management API now answers 403 with the error code plan_limit_reached. It used to return 400 validation_failed. That told a script or an agent to go fix a payload that had nothing wrong with it. The response now names the cap and points at the collection holding what the organization already has. The status and code of those requests change, so a client that matched on validation_failed to spot a plan cap should match on plan_limit_reached now. - [Cleanup removes the constructor parameter a fold leaves unread](https://featureflip.io/changelog/#flag-cleanup-unread-constructor-parameters) (2026-10-16): When the flag cleanup Action folds a flag read away, the constructor parameter that fed it can end up with no reader at all. C# flags that as CS9113. TypeScript under noUnusedLocals calls it TS6138, and either one failed a strict build on the removal pull request. Version 1.6.0 deletes the parameter, and the argument each caller passes for it, once it can account for every caller. The release also reaches wrappers 1.5.0 left alone, among them TypeScript class fields, object-literal methods and wrappers your tests stub or mock, plus C# interfaces in projects nobody packs for NuGet. - [Wrapper inlining reaches Go, TypeScript and JavaScript](https://featureflip.io/changelog/#flag-cleanup-wrappers-go-typescript) (2026-10-15): Version 1.4.0 taught the flag cleanup Action to inline a method that wraps one flag read, in Kotlin, Java and C#. Version 1.5.0 does it in Go, TypeScript and JavaScript as well. A call like flags.NewCheckout(u) turns into the value the flag serves wherever its file proves which function it reaches, and the function goes once nothing calls it. Swift enum cases that hold a key are followed now too. And in TypeScript and JavaScript, an import of a local module that does nothing when it loads, such as a file of flag-key constants, is deleted with its last use. - [The MCP server sets up SDK keys, segments and environments](https://featureflip.io/changelog/#mcp-sdk-keys-segments) (2026-10-14): MCP server 0.2.0 lets an agent set up a project end to end. It can create projects, environments, SDK keys and segments, and edit one targeting rule without resending the whole list. A write can carry the etag of what the agent read, so a change someone else made in the meantime makes it fail rather than get overwritten. Claude Desktop users can install the server from a one-click bundle, attached to every release since 0.1.12. - [The cleanup Action inlines the methods that wrap a flag](https://featureflip.io/changelog/#flag-cleanup-inline-wrappers) (2026-10-14): Most codebases read a flag through a small method like isNewCheckoutEnabled() and call that method everywhere. The flag cleanup Action used to fold the read inside the method and leave every caller alone. Version 1.4.0 replaces each call it can prove is bound to that method with the value the flag serves, in Kotlin, Java and C#. Once nothing calls the method, it goes too. The release also follows a key declared in another file in five more languages, reads keys held in Dart, PHP and Python enums, and lets archive-sweep wait until a removal is deployed. - [Default flag lifetime for a project](https://featureflip.io/changelog/#default-flag-lifetime) (2026-10-13): An expiry date only helps on the flags someone remembered to date. A project can now set a default lifetime in days, and every temporary flag in it with no date of its own expires that long after it was created. Those flags then turn up as expired in the dashboard, in stale flag detection and in cleanup notices. What they serve stays the same. - [Permanent flags](https://featureflip.io/changelog/#permanent-flags) (2026-10-11): Some flags are meant to stay. A kill switch or an ops toggle can serve one value for a year and still be doing its job, which traffic analysis reads as a finished rollout. Marking a flag permanent records that intent, and Featureflip stops suggesting you remove it. What the flag serves stays the same. - [OpenFeature provider for Ruby](https://featureflip.io/changelog/#openfeature-ruby) (2026-10-10): Ruby joins Node.js, .NET, Python, Go, Java and PHP behind the OpenFeature API. The featureflip-openfeature gem wraps the Featureflip Ruby SDK, so call sites use the standard OpenFeature client and a vendor switch means registering a different provider. Configuration-change events work from the first release. - [The cleanup Action follows a flag key to where it is declared](https://featureflip.io/changelog/#flag-cleanup-declared-keys) (2026-10-09): Plenty of code doesn't pass a flag key straight to the SDK. It keeps the key in a constant, an enum or a TypeScript as const object, often in another file, and the flag cleanup Action used to leave every one of those flags alone. Version 1.3.0 goes and finds it. It traces each read back to its declaration in Java, Kotlin, TypeScript and JavaScript, and removes the read once it can prove which flag that read is checking. When it can't, the declaration stays and the pull request says why. The release also cleans up tests that mock a removed flag, removes flags in prerequisite order and deprecates mode: archive-on-merge. - [Client SDKs report the flags your app actually reads](https://featureflip.io/changelog/#client-sdk-read-reporting) (2026-10-08): Featureflip used to count every flag it sent a browser or mobile client as in use, whether your code read it or not. A client-side flag could therefore never look stale, and none could be archived while the app was open. The browser, React, Swift, Android and Flutter SDKs now report the flags your app reads, so stale detection and the archive guard work from real reads. - [Flag owners in the MCP server](https://featureflip.io/changelog/#mcp-flag-owners) (2026-10-01): An agent connected to @featureflip/mcp 0.1.9 can now assign flag owners. Ask it to hand a flag to a teammate or find the stale flags nobody owns, and it calls the same owner endpoints as the Management API under the same plan rules. That means Pro and above. - [Flag owners](https://featureflip.io/changelog/#flag-owners) (2026-09-30): Every flag can now name the person responsible for it. The owner shows on the flag and in the flags list, you can filter by it to see what is yours or what nobody has claimed, and cleanup notices about a flag go to its owner instead of to every admin. When someone leaves, the admin removing them picks who inherits their flags in the same step. Flag owners are on Pro and above. On Free and Team, Featureflip still records each flag's creator as its owner, so a team that upgrades finds its flags already owned. - [Cleanup notices for flags that are ready to remove](https://featureflip.io/changelog/#flag-cleanup-notices) (2026-09-30): Featureflip now emails someone when a flag is ready to come out of your code. Once a day it checks for flags that have passed their expiry date or gone Dead, and sends a digest listing each one with the reason it qualified and a link to the flag. On Pro and above the email goes to the flag's owner. On Team, and for any flag without an owner, it goes to the organization's Owners and Admins. Cleanup notices come with Team and every plan above it. On Free, the same flags show as Expired or Dead in the flags list and through the MCP server and the API. - [Single sign-on with your own identity provider](https://featureflip.io/changelog/#single-sign-on) (2026-09-30): Your team can now sign in to Featureflip through the identity provider your company already runs. Featureflip connects over OpenID Connect, so Okta, Microsoft Entra ID and any other provider that publishes an OIDC discovery document will work, and your IdP decides who gets in. New people can join automatically with a role you choose, and an Owner can require single sign-on for the whole organization. Single sign-on is on the Business and Enterprise plans. SAML and SCIM are part of Enterprise. - [New plans: Free for up to 3 people, and a Team tier](https://featureflip.io/changelog/#new-plans-free-team) (2026-09-30): Featureflip now has four self-serve plans. Solo is renamed Free and covers up to 3 team members, so a small team can run flags in production without paying anything. Team is new, at $49 a month or $39 billed annually, for teams of up to 5. Pro moves to $99 a month and Business to $249, and neither loses any room. Scheduled changes are now part of the paid plans. Subscriptions that started before this change keep the price they signed up at. - [Outbound webhooks for configuration changes](https://featureflip.io/changelog/#outbound-webhooks) (2026-09-24): Featureflip can now call your own HTTPS endpoint whenever a flag or its configuration changes, so a deploy pipeline, chat channel or cache can react to a toggle instead of polling for it. Each subscription picks the event types it wants and can be narrowed to specific projects and environments. Every request is signed, retried when your endpoint fails, and kept in a delivery log you can resend from. Subscriptions are managed from Organization Settings, through the Management API or with the Terraform provider, and an organization gets one on Free, three on Team and Pro, and as many as it needs on Business and Enterprise. - [Expiration dates for temporary flags](https://featureflip.io/changelog/#flag-expiration-dates) (2026-09-24): A feature flag can now carry the date it is meant to come out. Set it when you create the flag or later from its header, and once that day passes Featureflip reports the flag as stale with the reason PastExpiry, right beside the traffic-based signals stale flag detection already tracks. The date is a reminder for your team, and the flag keeps serving exactly what it served before. - [Archive a flag when its removal deploys](https://featureflip.io/changelog/#flag-cleanup-archive-on-deploy) (2026-09-18): A removal pull request merging is not the same event as its code going live, and Featureflip will not archive a flag its own traffic is still evaluating. That refusal used to fail the run. Version 1.2.0 makes it a deferred outcome that exits 0, then adds two modes that come back for the flag once the code is live. Put mode: archive-sweep on a schedule and it retries every flag whose removal merged while the flag itself is still being evaluated. The other mode, archive-on-deploy, waits for deployment_status instead, then archives the flags whose removal the deployed commit contains, asked of GitHub's compare endpoint rather than assumed. Pair the sweep with either one, because a deferral nothing retries leaves the flag live indefinitely. - [Sign in with GitHub](https://featureflip.io/changelog/#sign-in-with-github) (2026-09-18): GitHub joins Google as a way to sign in, on every plan. Click Continue with GitHub on the sign-in or sign-up screen, approve the consent screen, and Featureflip signs you in or creates your account from your verified GitHub email. GitHub uses OAuth 2.0 rather than OpenID Connect, so its sign-in response carries no verification status at all, and Featureflip reads your primary address and its verified flag from GitHub directly before it will create anything. - [OpenFeature provider for PHP](https://featureflip.io/changelog/#openfeature-php) (2026-09-17): PHP joins Node.js, .NET, Python, Go and Java behind the OpenFeature API. The package is featureflip/featureflip-openfeature on Packagist, and it wraps the Featureflip PHP SDK, so your call sites talk to the standard OpenFeature client and swapping vendors becomes a provider registration rather than a rewrite. Unlike the other five providers, it takes no SDK key: the PHP SDK requires a caller-supplied PSR-18 HTTP client, PSR-17 factories and a PSR-16 cache, so you build a FeatureflipClient yourself and hand it to the provider instead. - [OpenFeature .NET catches up on four SDK releases](https://featureflip.io/changelog/#openfeature-dotnet-evaluation-fixes) (2026-09-16): The .NET provider now requires Featureflip.Client 2.9.0. NuGet resolves a package reference to the lowest version that satisfies it, so anyone on 0.3.x kept loading the 2.7.0 SDK while four releases of evaluation fixes went only to people using the .NET SDK directly. Version 0.4.0 closes that gap. Before you upgrade, check your date rules. A Before or After operand has to be written as ISO-8601 or as a Unix timestamp in seconds, so a rule holding something like 05/15/2023 will stop matching. Rewrite it as 2023-05-15. - [Re-run a flag cleanup pull request from a comment](https://featureflip.io/changelog/#flag-cleanup-pr-commands) (2026-09-14): A pull request from the flag cleanup Action can sit open while its base branch moves on, or someone pushes a fix to it by hand and wants it to try again. Version 1.1.0 takes that request as a comment. Comment @featureflip-cleanup rerun and the Action rebuilds the removal from the pull request's own base branch, then force-pushes the result. It refuses if anyone else has committed to that branch, and commenting @featureflip-cleanup recreate instead is how you tell it to go ahead and throw those commits away. Neither command takes a flag key. The same release adds a flags input that limits a sweep to the keys you name. - [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. - [Flag change subscriptions in the Go and Java SDKs](https://featureflip.io/changelog/#flag-update-subscriptions-go-java) (2026-09-06): Go and Java can now tell your code when flag configuration changes. Register a listener and it gets the keys of every flag an update touched, in one call, so you can drop a cache or log the change as it lands instead of polling for it. That puts Go and Java level with JavaScript, Node.js, .NET and Python, which picked up the same subscription in featureflip 2.7.0 on August 28. It is also what the Go and Java OpenFeature providers use to emit PROVIDER_CONFIGURATION_CHANGED. - [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. - [The MCP server is in the official MCP Registry](https://featureflip.io/changelog/#mcp-registry) (2026-08-28): The Featureflip MCP server is listed in the official Model Context Protocol Registry as io.github.canopy-labs/featureflip. Clients and directories that read the registry can now find it and install @featureflip/mcp from npm without anyone copying a config block out of our docs. The listing names the package, its stdio transport and the environment variables it reads, and every release updates it automatically. - [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 works nothing like a credential you could reuse anyway. It selects an environment: whichever one issued the key is the configuration your process receives. Point staging at the production key and staging reads production flag states, so 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 a per-flag salt. Without it the rollout skips that caller, who gets the next matching rule or the flag's default variation. The hosted evaluation endpoint and every server SDK behave the same way. - [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. - [Is automated flag removal safe to let into my repo?](https://featureflip.io/questions/is-automated-flag-removal-safe-to-let-into-my-repo/): The Action runs inside your own CI, so the only credential holding write access to your repository is the GITHUB_TOKEN that workflow already has. The Featureflip token you supply reads removal candidates and nothing else, and a Viewer token scoped to one project is enough. Every change arrives as a pull request you review, and dry-run mode prints each diff without contacting GitHub at all. - [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/): 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 flag resolves from your backend and comes back empty in the browser. The client SDK reports it 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/): Streaming delivers a flag change within seconds, so anything slower is not coming over the stream. When the stream cannot connect, most SDKs give up after five failed attempts and poll instead, every thirty seconds by default. A stream held open by a buffering proxy goes quiet without raising an error, so the SDK keeps waiting on a connection that delivers nothing. - [Why did my targeting rule not match?](https://featureflip.io/questions/why-did-my-targeting-rule-not-match/): An earlier rule almost certainly matched first and stopped evaluation. Failing that, the attribute your rule tests never made it into the evaluation context, or the value is there but arrives as a different type or case than the rule expects. Rules run top to bottom and the first match wins, which makes rule order 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/): A rollout buckets by user key by default, and each user hashes independently. Two colleagues in the same workspace count as two separate users, so a 50% rollout splits them roughly half the time. Point the rollout at 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/): Check what each service passes as the user key. Every SDK and the hosted endpoint run the same hash, so the same key and the same flag configuration give the same variation everywhere. A service that drops the key, sends it under another attribute name or reads a different environment will disagree with one that does not. - [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 behavior. Each user is hashed together with the flag's salt to produce a bucket from 0 to 99, 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. Hashing is per flag, so being inside the 30% for one tells you nothing about any other. - [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/): Your UI is rendering inside the window before the browser SDK has its first flag payload, and during that window every call returns the default value you passed. The reason string reads 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/): Every environment holds its own configuration, so enabling a flag in development changes nothing in production. Targeting rules and rollout percentages are per environment as well, which means a flag can read as 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/): The SDK key almost certainly did not reach the container. A key read from a local env file that is never passed through in your compose file or Dockerfile arrives empty, and the SDK serves your default value rather than failing loudly. After that, suspect 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/): Bucketing assigns each user a fixed number from 0 to 99 and counts how many land under your threshold, rather than metering 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 contexts with no user key, which the rollout skips so they fall through to the next rule or the default. - [Why doesn't my segment match any users?](https://featureflip.io/questions/why-doesnt-my-segment-match-any-users/): The rule probably cannot resolve the segment at all, which fails closed and matches nobody. A client SDK never given segment data behaves the same way. Once that is ruled out, look at condition logic. Segments carry 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/): The value you are sending does not parse as a semantic version. An unparseable string matches nothing at all, with no fallback 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/): The SDK almost certainly cannot find the flag at all, so evaluation never got far enough to fail. Check the SDK key first, since it may belong to a different environment, then whether the flag is simply off there. After that comes a misspelled key, a client still initializing, a type mismatch against the variation, or a flag that is not client-side visible when you ask 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/): 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 and no conversion happens. The dashboard then shows the flag serving one thing while your code reports another, which reads like a stale cache and is really a type mismatch. - [Why is my flag evaluation returning an error?](https://featureflip.io/questions/why-is-my-flag-evaluation-returning-an-error/): 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, declining to guess which survivor you meant. A variation that exists but holds a null value falls outside this, so the reason string reliably separates a config problem from a data one. ## Blog - [Feature Flag Cleanup Business Case and Policy Template](https://featureflip.io/blog/feature-flag-cleanup-business-case/): Make the business case for feature flag cleanup: a pitch for each audience, copyable email, Slack and sprint templates, and an expiration policy to paste in. - [Feature Flag Code Review Checklist: What to Check in a PR](https://featureflip.io/blog/feature-flag-code-review-checklist/): A feature flag code review checklist for the three kinds of flag PR: adding a flag, building behind one and removing one, plus a template you can paste. - [Feature Flag Lifecycle Management: Archive, Remove, Audit](https://featureflip.io/blog/flag-lifecycle-management/): Feature flag lifecycle management is deciding a flag's exit when you create it. When to remove the code, when to archive, when to delete, and how to audit. - [Golden Vector Testing: Keeping Seven SDKs in Agreement](https://featureflip.io/blog/golden-vector-testing/): How we keep seven server SDKs giving the same flag answer: the evaluation engine generates the test vectors, and every SDK must match them in CI. - [Feature Flag Owners, Expiry Dates, SSO and New Plans](https://featureflip.io/blog/new-plans-sso-flag-lifecycle/): Free now covers 3 people and Team is new at $49. Flags get expiry dates and named owners, someone hears when a flag is done, and Business adds SSO. - [Feature Flag Cleanup Tools Compared (2026)](https://featureflip.io/blog/feature-flag-cleanup-tools-compared/): Feature flag cleanup tools split three ways: mark the flag, let a model rewrite the code, or apply deterministic transforms. Which one fits your codebase. - [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: Nine Providers, Eight Languages](https://featureflip.io/blog/openfeature-feature-flags/): OpenFeature feature flags in Node.js, .NET, Python, Go, Java, PHP, Ruby, Web and Android: set up the Featureflip provider and 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. - [Plans and Limits](https://featureflip.io/docs/concepts/plans-and-limits/): Every Featureflip plan's limits and plan-gated features in one place (Free, Team, Pro, Business and Enterprise), how the limits are counted, and what happens when you upgrade, downgrade or cancel. Prices are on the pricing page. - [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. - [Critical Environments](https://featureflip.io/docs/guides/critical-environments/): Mark an environment critical so every change to what it serves needs a written reason, enforced by the server on the dashboard, the Management API (X-Intent-Reason header, 422 change_reason_required) and the MCP server, and recorded in the audit log. Project-wide changes such as segment, variation and archive edits need one when any environment in the project requires it, and scheduled changes keep the reason they were created with. Required reasons are on Business and Enterprise. A second setting, on every plan, asks for the environment key in the dashboard before a change lands. New projects turn on both for production, as far as the plan allows. - [Compare and Copy Environments](https://featureflip.io/docs/guides/compare-and-copy-environments/): The Compare page lists every flag whose on/off state, default variation, strategy, rules or prerequisites differ between two environments, with a Differences only switch and a tag filter on every plan, plus an owner filter on Pro and above. Copy takes one flag's default variation, strategy, rules and prerequisites from one environment into another, and on/off only when asked, after a preview with warnings. Prerequisites are re-checked in the target, a change since the preview refuses the apply, and a critical target asks for a reason. Copy is on Team and above. Available in the dashboard, on /api/v1 (compare, per-flag compare and copy) and as the MCP tools compare_environments and copy_flag_config. - [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. - [Flag Triggers](https://featureflip.io/docs/guides/flag-triggers/): A secret URL that turns one flag on or off in one environment when a monitoring tool calls it with a POST, so an alert can flip a kill switch. Create it on the flag's Triggers tab or through /api/v1, call it from Grafana, Datadog or curl, and see each firing in the audit log and on the flag's History tab. Calls to a flag already in that state change nothing. Rate-limited per trigger. Up to 10 per flag environment. Team plan and above; turn-off triggers keep working after a downgrade. - [Flag Expiration Dates](https://featureflip.io/docs/guides/flag-expiration/): Give a temporary flag a target removal date. Once the date passes the flag is reported stale with the reason PastExpiry, and what it serves does not change. Set, change or clear it from the dashboard or the Management API. A project can also set a default lifetime in days, so a temporary flag with no date of its own expires that long after it was created. - [Permanent Flags](https://featureflip.io/docs/guides/permanent-flags/): Mark a kill switch, ops toggle or entitlement flag as permanent so it is never reported for cleanup. A permanent flag shows a Permanent badge instead of a Stale or Dead one, is left out of the Stale and Dead filters, cleanup notice emails, removal candidates, the flag cleanup Action and the MCP tools find_stale_flags and list_removal_candidates, and evaluates exactly as before. It can't have an expiry date. The flags list has a lifecycle filter (Any lifecycle, Temporary, Permanent). Available on every plan, from the dashboard, POST/PUT/DELETE on /api/v1 (isPermanent, .../flags/{flag}/permanent, ?permanent=true on the list call) and the MCP tool set_flag_permanent. - [Flag Owners](https://featureflip.io/docs/guides/flag-owners/): Name the person responsible for each feature flag, on the Pro plan and above. The owner is shown on the flag, the flags list can be filtered by owner, cleanup notices for the flag go to its owner, and when a member is removed an admin chooses who inherits their flags. Owners can be changed or cleared from the dashboard or the API. - [Flag Cleanup Notices](https://featureflip.io/docs/guides/cleanup-notices/): A daily email when a feature flag passes its expiry date or goes dead, on Team and above. It goes to the flag's owner on Pro and above, otherwise to the organization's Owners and Admins, and each person can opt out in their email preferences or from the unsubscribe link. On Free the same flags show as Expired or Dead in the dashboard and through find_stale_flags. - [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), require it for every member of an organization (Team plan and above, with a grace period and an SSO exemption), and sign in with Google or GitHub, including what GitHub sign-in reads and why an unverified address is turned away. - [Single Sign-On (SSO)](https://featureflip.io/docs/guides/single-sign-on/): Sign in through your own identity provider over OpenID Connect, on the Business plan and above. Verify email domains with a DNS TXT record, add new people automatically with a default role, and optionally require SSO for the organization, with a password recovery path for Owners. - [Set Up SSO with Okta](https://featureflip.io/docs/guides/sso-okta/): Create an OIDC web app integration in Okta, find the issuer, save and test the connection in Featureflip, and add the Okta dashboard tile. - [Set Up SSO with Microsoft Entra ID](https://featureflip.io/docs/guides/sso-entra-id/): Register a single-tenant app in Entra ID (formerly Azure AD), create a client secret, use the tenant-specific v2.0 issuer, and restrict sign-in with app assignment. - [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. - [Outbound Webhooks](https://featureflip.io/docs/guides/webhooks/): Subscribe an HTTPS endpoint, a Slack channel, Datadog or Grafana to flag, targeting, segment, environment and key changes. Deliveries are HMAC-SHA256 signed, retried on failure, logged with one-click redelivery, and signed with rotatable secrets. Manageable from the dashboard, the Management API or the Terraform provider. - [Flag Evaluation Analytics](https://featureflip.io/docs/guides/flag-analytics/): Every flag's Analytics tab shows, per environment over 7, 30 or 90 UTC days, how many evaluations each variation got and which rule, default, off variation or prerequisite served them. Each percentage-rollout rule gets a sample-ratio check of its configured split against what it served. Counts are evaluations, not unique users. The same breakdown is on /api/v1 and in the MCP server's flag_evaluations tool. Every plan and every role. - [Analytics Integration](https://featureflip.io/docs/guides/analytics-integration/): Register an inspector when you create the client, and every flag evaluation reaches your own code as it happens, in every SDK except Cloudflare Workers. From there you can send exposures to PostHog, Amplitude, GrowthBook or any analytics tool you already run, record each evaluation on the active OpenTelemetry span using the feature flag semantic conventions, or attach boolean flags to Sentry error events. - [Bootstrap Client-Side Flags](https://featureflip.io/docs/guides/bootstrap/): Start the browser or React SDK with flag values so the first paint doesn't wait on the network. Pass the values a server SDK evaluated while rendering the page, so the first client render matches the server HTML, or use bootstrap: 'localStorage' to reuse last visit's values. Fresh values from the server replace them. Examples for Node.js and for a Cloudflare Worker (@featureflip/edge bootstrapValues), plus keeping contexts identical for anonymous visitors. - [Flag Cleanup Action](https://featureflip.io/docs/integrations/flag-cleanup-action/): Remove dead feature flag code with one reviewable pull request per flag on GitHub, GitLab or Bitbucket (a GitHub Action, a GitLab CI template, a Bitbucket Pipelines step, a CircleCI orb, or any CI through Docker) across twelve languages plus ERB and Blade templates, then archives the flag once the removal is deployed and the old traffic has drained. - [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, Java, PHP, Ruby, Android and Web (browser) SDKs. - [Terraform Provider](https://featureflip.io/docs/integrations/terraform/): Manage projects, environments, feature flags, targeting rules, segments, SDK keys, and outbound webhooks as code with the canopy-labs/featureflip provider, published on both the Terraform Registry and the OpenTofu Registry. ## 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. - [Cloudflare Workers](https://featureflip.io/docs/quickstart/edge/): Evaluate feature flags inside a Cloudflare Worker or Pages Function with @featureflip/edge, using a stable visitor key from a cookie. - [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. - [Cloudflare Workers SDK](https://featureflip.io/docs/sdks/edge/): @featureflip/edge evaluates flags locally in a Worker from a cached copy of the environment's config (memory plus the Workers Cache API). Flag changes arrive within ttlSeconds (60s by default). Covers options and defaults, typed accessors, variationDetail, bootstrapValues for the browser SDK (client-visible flags only), cold starts, and best-effort events. Cloudflare Workers is the only supported runtime. - [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 Reference](https://featureflip.io/docs/api/reference/): OpenAPI-generated reference for every Evaluation API endpoint, request, and response. - [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, and an organization's maximum personal token lifetime (Business plan and above). - [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. - [Using an AI Agent](https://featureflip.io/docs/management-api/agents/): How a coding agent gets its token from a person, finds the default project, creates flags, mints an SDK key, and what the Free plan's caps return. - [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.