Featureflip changelog

version

0.10.0 → 0.10.1

version

0.9.0 → 0.10.0

version

0.8.0 → 0.9.0

version

0.7.0 → 0.8.0

https://featureflip.io/llms.txt

− Free to start, with SDKs for JavaScript, Cloudflare Workers, Python, C#, Java, Go, PHP, Ruby, Swift, Flutter, Android, and React.− - [Homepage](https://featureflip.io/): Feature flags without the tech debt. A GitHub Action opens one reviewable pull request per dead flag and removes the code path in thirteen languages once a rollout is finished, and every plan is one flat price with nothing metered.− - [Feature Flag Webhooks](https://featureflip.io/product/features/webhooks/): Outbound webhooks send a signed HTTP request to your endpoint 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− - [A/B Testing](https://featureflip.io/use-cases/a-b-testing/): Serve two variations to a sticky 50/50 split and record who saw which one — the flag delivers the experiment, your analytics call the winner.− - [Feature Flag Cost Calculators](https://featureflip.io/tools/): Six per-vendor calculators that run your own numbers through a published rate card and put the result next to Featureflip's flat price. Every rate carries a source link and a check date.− - [OpenFeature Feature Flags: Seven Language Providers](https://featureflip.io/blog/openfeature-feature-flags/): OpenFeature feature flags in Node.js, .NET, Python, Go, Java, PHP and Ruby: set up the Featureflip provider, map context, keep call sites vendor-neutral.− - [Account Security](https://featureflip.io/docs/guides/account-security/): Enable two-factor authentication (TOTP authenticator app plus recovery codes) and sign in with Google or GitHub, including what GitHub sign-in reads and why an unverified address is turned away.− - [Outbound Webhooks](https://featureflip.io/docs/guides/webhooks/): Subscribe an HTTPS endpoint 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.− - [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.− - [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 values a server SDK evaluated while rendering the page (no request before first render, and the server-rendered HTML matches the first client render), or bootstrap: 'localStorage' to reuse the values the browser saw last visit, stored per client key and context. The server's values then replace them. Includes a Node.j− - [Flag Cleanup Action](https://featureflip.io/docs/integrations/flag-cleanup-action/): Remove dead feature flag code with a GitHub Action that opens one reviewable pull request per flag across thirteen languages, then archives the flag once the removal is deployed and the old traffic has drained.− - [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 and Ruby SDKs.− - [Authentication](https://featureflip.io/docs/management-api/authentication/): Personal Access Tokens and organization-scoped Service Tokens, sent as bearer tokens.+ Free to start, with SDKs for JavaScript, Node.js, Cloudflare Workers, Python, C#, Java, Go, PHP, Ruby, the browser, React, Swift, Flutter and Android.+ ## 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, + - [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.+ - [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.+ - [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 re+ - [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.+ - [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.+ - [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 when+ - [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 c+ - [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 eval+ - [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 st+ - [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 c+ - [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+ - [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+ - [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 re+ - [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.+ - [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.+ - [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 t+ - [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.+ - [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 p+ - [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 co+ - [Flag Cleanup Action](https://featureflip.io/docs/integrations/flag-cleanup-action/): Remove dead feature flag code with a GitHub Action that opens one reviewable pull request per flag across twelve languages plus ERB and Blade templates, then archives the flag once the removal is deployed and the old traffic has drained.+ - [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.+ - [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).+ - [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.

version

0.6.0 → 0.7.0

version

0.4.0 → 0.6.0

version

0.3.0 → 0.4.0

https://featureflip.io/llms.txt

− Free to start, with SDKs for JavaScript, Python, C#, Java, Go, PHP, Ruby, Swift, Flutter, Android, and React.− - [Feature Flag SDKs](https://featureflip.io/product/features/sdks/): Official SDKs for 13 languages and frameworks — server (JavaScript/TypeScript, Node.js, Python, Go, Java, C#, Ruby, PHP) and client (React, Browser, Swift, Flutter, Android). Server SDKs evaluate flags locally in-memory with no per-request network call; every SDK streams config updates over SSE; one consistent variation API; identical results across SDKs (shared, vector-tested engine); fail-safe defaults; direct Evaluation API− - [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 thirteen 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.− - [Do I need a user ID to evaluate a feature flag?](https://featureflip.io/questions/do-i-need-a-user-id-to-evaluate-a-feature-flag/): Not for on/off flags or targeting rules that match on other attributes. You need one for percentage rollouts, because the bucket comes from hashing the identifier with the flag key. Without it a server SDK evaluating locally serves the first (control) variation, while the hosted evaluation endpoint spreads anonymous traffic by weight with no per-user stickiness.− - [Why do two SDKs return different variations?](https://featureflip.io/questions/why-do-two-sdks-return-different-variations/): One of them is almost certainly evaluating a keyless context. Bucketing needs a stable user key, and the two evaluation paths handle its absence differently on purpose. A server SDK evaluating locally serves the first variation, while the hosted endpoint assigns a fresh random bucket per call. Pass the same user key everywhere and the two agree, since every SDK runs th− - [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 key to produce a bucket from 0 to 100, so a 30% rollout puts roughly three users in ten on the new variation. The same user always lands in the same bucket for the same flag. Hashing is per flag, so being inside the 30% for one tells you nothing about any o− - [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 anonymous contexts, which the hosted endpoint spreads randomly on every call − - [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 all thirteen SDKs. From there you can send exposures to PostHog, Amplitude, GrowthBook or any analytics tool you already run.+ Free to start, with SDKs for JavaScript, Cloudflare Workers, Python, C#, Java, Go, PHP, Ruby, Swift, Flutter, Android, and React.+ - [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 consis+ - [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.+ - [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 + - [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 bootst+ - [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 c+ - [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 statu+ - [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.+ - [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+ - [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 th+ - [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.+ - [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 values a server SDK evaluated while rendering the page (no request before first render, and the server-rendered HTML matches the first client render), or bootstrap: 'localStorage' to reuse the values the browser saw last visit, stored per client key and context. The server's values then replace them. Includes a Node.j+ - [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.+ - [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.

https://featureflip.io/llms.txt

− > Feature flag platform for modern development teams. Roll out features gradually, run A/B experiments, and let a GitHub Action open the pull request that deletes each flag once its rollout is finished. Free to start, with SDKs for JavaScript, Python, C#, Java, Go, PHP, Ruby, Swift, Flutter, Android, and React.− - [Full site text for LLMs](https://featureflip.io/llms-full.txt): Every page inlined in full, including the comparison tables, alternatives guides, cost calculators, glossary definitions and question answers.− - [Flag Lifecycle](https://featureflip.io/product/features/flag-lifecycle/): Keep temporary feature flags temporary. Set an expiry date on a flag (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− - [OpenFeature Feature Flags: Node, .NET, Python, Go, Java, PHP](https://featureflip.io/blog/openfeature-feature-flags/): OpenFeature feature flags in Node.js, .NET, Python, Go, Java and PHP: set up the Featureflip provider, map evaluation context, keep call sites vendor-neutral.− - [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.− - [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 and PHP SDKs.+ > 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, Python, C#, Java, Go, PHP, Ruby, Swift, Flutter, Android, and React.+ - [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.+ - [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 recor+ - [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+ - [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 + - [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, + - [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.+ - [OpenFeature Feature Flags: Seven Language Providers](https://featureflip.io/blog/openfeature-feature-flags/): OpenFeature feature flags in Node.js, .NET, Python, Go, Java, PHP and Ruby: set up the Featureflip provider, map context, keep call sites vendor-neutral.+ - [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 + - [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 and Ruby SDKs.

version

0.2.0 → 0.3.0

version

0.1.13 → 0.2.0

version

0.1.12 → 0.1.13

version

0.1.11 → 0.1.12

version

0.1.10 → 0.1.11

https://featureflip.io/llms.txt

− - [GrowthBook Cost Calculator](https://featureflip.io/tools/growthbook-cost-calculator/): Estimate GrowthBook Cloud's per-seat bill from your team size, with the free 3-user Starter tier and the 50-user Pro ceiling accounted for, and compare it to Featureflip's flat price. Rates sourced and dated.− - [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.− - [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.− - [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.− - [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.+ - [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.+ - [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 rem+ - [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.+ - [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.+ - [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.+ - [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.

version

0.1.9 → 0.1.10