Changelog
What shipped, when it shipped, and where to read the docs for it. Newest first. Each release links to the packages and pages it added, so you can check the claim rather than take our word for it.
-
Integration
OpenFeature provider for Android
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.
- Boolean, string, integer, long, double and object resolution through the standard OpenFeature Kotlin client
- setProviderAndWait and setEvaluationContextAndWait return once that user's flags are in, and the status goes Reconciling then Ready on a switch
- ProviderConfigurationChanged fires with the keys of the flags that changed
- ruleId and prerequisiteKey arrive in flagMetadata, and an unmet prerequisite resolves as PREREQUISITE_FAILED
- client.track() calls are forwarded to Featureflip custom events
- Needs Java 17 or higher and a client-side SDK key. Apache 2.0, like every Featureflip SDK
- Version 2.4.0 of the flag cleanup Action removes getBooleanValue reads from Kotlin files that import dev.openfeature, through key constants in other files and wrapper functions too
-
Integration
Cleanup reads OpenFeature React hooks and leaves JSX tidy
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.
- useBooleanFlagValue from @openfeature/react-sdk is removed, read through a key constant, a key imported from another file or a hook of your own, and so is getBooleanValue on the client that useOpenFeatureClient() returned
- A value the removal shortened goes back onto the line of its = or :, a JSX element written over several lines rejoins its tag once its attributes fit, and a fragment left directly inside another fragment or element is replaced by its children
- Lines are only joined when the result fits your Prettier printWidth or .editorconfig max_line_length, and a Prettier config that sets singleAttributePerLine joins nothing
- In C#, the gate class's own unit test is deleted with the member it reads. It used to become Assert.Equal(flagValue, true), an analyzer error that broke the build
- More C# constructor parameters typed as a deleted interface are removed, and a test that switches its fake between the removed and the kept value partway through loses only the removed half
- A C# test helper whose bool parameter defaults to the removed value, called somewhere without an argument, now keeps the gate rather than being rebuilt with the kept value
-
Platform
See what a flag actually served
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.
- A daily line per variation, a table of evaluations and share per variation, the total, and when the flag was last evaluated
- A breakdown by source splits evaluations by the rule, default, off variation or prerequisite that served them, with live rules in evaluation order and deleted ones after
- Each percentage-rollout rule shows its configured split beside what it served, with a sample-ratio check that marks the split only when it is statistically significant and some variation is at least 2 points off
- GET /api/v1/orgs/{org}/projects/{project}/flags/{flag}/environments/{env}/evaluations returns the same breakdown, and MCP server 0.4.0 adds the read-only flag_evaluations tool
- Server SDKs report the reason and rule behind each evaluation from JavaScript, Node.js and Cloudflare Workers 2.16.0, Python 2.10.0, C# 2.12.0, Go 2.11.0, Java 2.13.0, PHP 3.7.0 and Ruby 2.13.0. Evaluations from older versions show as Unknown. Browser and mobile reads are attributed on the server, with no upgrade needed
- Every role can open the tab, Viewers included, on every plan
-
Integration
OpenFeature provider for the browser and React
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.
- Boolean, string, number and object resolution through the standard @openfeature/web-sdk client
- setContext fetches flags for the new user before it resolves, and OpenFeature announces the switch as PROVIDER_CONTEXT_CHANGED
- PROVIDER_CONFIGURATION_CHANGED fires with the keys whose value changed for the current user
- ruleId and prerequisiteKey arrive in flagMetadata, an unmet prerequisite resolves as PREREQUISITE_FAILED, and bootstrap or localStorage values report CACHED
- The Featureflip flag cleanup Action removes getBooleanValue reads in files that import @openfeature/web-sdk, and from version 1.17.0 useBooleanFlagValue reads from @openfeature/react-sdk
- Needs @featureflip/browser 2.17.0 or newer. Apache 2.0, like every Featureflip SDK
-
Integration
Removal pull requests fix the tests and comments around a flag
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.
- A TypeScript or JavaScript test about the removed branch is deleted even when it never sets the flag, as long as your flag registry declares that branch the default and the test's title names the flag. The pull request then warns that tests leaving the flag unset run the kept branch from now on
- A kept test whose title names the flag in its kept state loses that condition from the title, and the pull request lists each rewrite, old title and new
- Comments next to changed code that describe a flag state without naming the flag, such as one saying polling is skipped while the flag is off, are listed in the pull request and never edited
- A parameter or argument list written one element per line goes back on one line when one element is left, constructor parameters included, if the line fits your Prettier printWidth or .editorconfig max_line_length
- An override left as {} is dropped from a call when the function it is passed to defaults that parameter to {}, and a paths alias is followed through a solution tsconfig.json
- In Dart, a plain import of the featureflip package that a removal leaves unused is removed when pubspec.lock resolves it from pub.dev, so dart analyze stops failing on unused_import. An unused import of @featureflip/edge is deleted like the other Featureflip JavaScript SDKs
-
SDKs
Rollouts skip a context they can't bucket
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.
- A context with no user_id skips a percentage-rollout rule in the hosted evaluation API and in the JavaScript, Node.js, Cloudflare Workers, Python, C#, Go, Java, PHP and Ruby SDKs, and the evaluation reports whatever served it instead
- Numeric and boolean IDs are formatted the same way in every SDK before they are hashed, so a context lands in the same bucket wherever it is evaluated
- A variation that a rule or the off state points at, but that the flag no longer defines, reports Error in every SDK
- Needs JavaScript, Node.js and Cloudflare Workers 2.15.0, Python 2.9.0, C# 2.11.0, Go 2.10.0, Java 2.12.0, PHP 3.6.0 or Ruby 2.12.0
-
Integration
Wrapper inlining reaches Python, Dart, PHP, Ruby and Swift
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.
- A Python function, method or @property whose body is one flag read is inlined at every call its file proves is bound to it. A wrapper your tests patch or mock, or one listed in __all__, stays, and its callers are still inlined
- Dart, PHP and Swift wrappers declared to return bool are inlined the same way, and so are Ruby instance methods, def self. methods and module functions. A public wrapper of a package that may be published is kept
- A comment that names only the removed flag is deleted. One that says anything else is kept and listed in the pull request, and license headers, TODOs and doc comments are never touched
- A Dart private field the removal leaves unread is deleted with the constructor parameter and caller arguments that fed it, so dart analyze stops reporting unused_field
- A comment at the end of a removed line goes with it, and code that shared a line with a removed statement keeps a line of its own instead of joining the line above
- In a TypeScript or JavaScript file with JSX, the import of the JSX factory, such as React or Preact's h, is kept so the elements left in the file still compile
- A C# gate method that builds its evaluation context before it reads the flag is inlined and removed like a one-line gate
-
SDKs
Evaluate feature flags inside a Cloudflare Worker
@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.
- createEdgeClient takes a server SDK key, and one await flags.load(ctx) per request returns a snapshot whose variation calls are synchronous
- Targeting rules, percentage rollouts and prerequisites resolve to the same values and reasons as in the Node.js SDK
- snapshot.bootstrapValues(context) returns client-visible flags only, ready for the bootstrap option of @featureflip/browser
- A copy older than ttlSeconds keeps serving while it refreshes in the background, and a cold start waits at most loadTimeoutMs before serving your defaults
- Evaluation events go out through waitUntil after the response, batched so each isolate sends at most once every 10 seconds unless a full batch is waiting, instead of once per request
-
SDKs
Bootstrap the browser and React SDKs for a first paint with real flags
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.
- bootstrap takes an object of flag values, for example from @featureflip/node during server rendering, and the client makes no request before the first render
- bootstrap: 'localStorage' saves the values per client key and context and serves them on the next page load, never to a different context
- FeatureflipProvider takes the same bootstrap prop, and server renders use a client that makes no requests and is never shared between requests
- flagSource and the ready event say whether the values came from the bootstrap, storage or the server, and initialize({ waitForServer: true }) waits for the server
-
Integration
Cleanup removes the C# gate a flag leaves behind
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.
- Once a C# wrapper with an interface has no callers, the emptied interface and classes go with their files, their dependency-injection registrations, the constructor parameters, fields and arguments that carried the interface, and test mocks that only built them. If one piece can't be proven, all of it stays and the pull request says why
- The options class an inert C# implementation read goes as well, with its binding and its key in each appsettings*.json. The edit keeps the file's comments and commas
- In Go, a label left with no break, continue or goto is removed, and so are two names declared together that the fold left unused, keeping the value as _ = load() when it may do work. A local that can't be cleaned up is refused, naming the local and its function, where the pull request used to open and fail with declared and not used
- In TypeScript and JavaScript, an unread private or # field is now deleted when deleting it skips no work, with the constructor parameter that fed it when every caller can be found. A stranded import of a Featureflip SDK, or a require of a module that does nothing on load, is deleted too
- PHP folds an if without braces and a match (true) arm on the read. Dart folds a collection-if inside a collection-for, and C# reads a flag inside an interpolated string with an escaped brace beside the hole. Each of these was refused before
- A dead if, case or while that ended a Ruby method becomes nil, so the method returns what it did before. A Dart local the fold left unused takes the comment at the end of its line with it
- Outside TypeScript, JavaScript and Python, a call to the left of the flag read is kept, so track() || read served true becomes track() || true. Blank lines inside a multi-line string are left alone, and a file with CRLF endings keeps one \r\n per line wherever code is deleted
- Archive modes count a removal only once it merges into the base branch, and archive-on-merge never archives from a fork's pull request. A cleanup workflow that sets base-branch needs the same value in its archive-sweep and archive-on-deploy workflows
-
API
Plan caps get their own Management API error
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.
- Creating a project, environment, flag or webhook subscription past the plan, or restoring an archived flag into a full project, returns 403 plan_limit_reached
- So does turning on, test-sending or redelivering to a webhook subscription that a downgrade left over the plan, which also used to return 400 validation_failed
- A plan_limit object carries the capped resource, the plan and the cap, so a client can branch on it without parsing the message
- next_actions lists a GET on the capped collection, so an agent can reuse what already exists rather than retry
- Every other validation_failed response is unchanged, and so is the dashboard
-
Integration
Cleanup removes the constructor parameter a fold leaves unread
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.
- A C# primary-constructor parameter or a TypeScript constructor parameter property that only the removed flag read is deleted, along with the matching argument at every call. If a caller can't be accounted for, the parameter stays and the pull request names it in a warning
- An unread private field or method left behind in TypeScript or JavaScript is named in the pull request as well, so you can delete it before noUnusedLocals or ESLint fails the build on it
- TypeScript and JavaScript wrappers can now be a class field holding an arrow function, or a member of an object literal held by a top-level const. Imports through baseUrl resolve, and callers of a .js wrapper with its own .d.ts are inlined while the wrapper stays beside its declaration
- Tests that stub a TypeScript or JavaScript wrapper with jest.spyOn, vi.spyOn, sinon.stub or a jest.mock factory are resolved the way Kotlin, Java and C# stubs are. So is a jest-mock-extended or ts-mockito class mock stubbed to the kept value
- In C#, a dotnet pack step now marks only the projects it packs, and what they reference, as published. A wrapper on a public interface in any other project can be inlined, and calls on a local taken from GetRequiredService or on an NSubstitute substitute are proven too
- Folds that tsc or eslint:recommended rejected come out clean now, including read ?? false, a switch on the flag, a constant loop and a statement stranded after break
- In Go, a variable a fold leaves unused in a for range, select or type switch header is taken out of the header instead of breaking the build, and a removed import leaves gofmt-clean output. Files with CRLF line endings keep them on every line a fold rewrites
-
Integration
Wrapper inlining reaches Go, TypeScript and JavaScript
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.
- In Go, a function or method returning one bool whose body is just return of the flag read is inlined at each call its file ties to it: a bare call in its own package, a call through an import of that package, or a method on a receiver whose type the file spells
- An exported Go method is never deleted, because code outside the repository may need it to satisfy an interface. Its callers are still folded, and the pull request reports the removal as partial
- In TypeScript and JavaScript, a top-level function, a const holding an arrow function, or a method of a non-generic class is inlined when its name is declared once across the repository. Async functions, getters and default exports keep the earlier behavior and are only folded inside
- A key held in a Swift enum case is resolved through a String raw value or a computed key property that switches on self, so enum keys now resolve in seven languages
- A TypeScript or JavaScript import of a repository file that only declares types, functions, classes and literal constants is deleted once nothing reads it. If that was the last import or export in the file, export {}; keeps it a module
- In Go, a var local that only the removed branch used is deleted as well, the way a := local already was
-
Integration
The MCP server sets up SDK keys, segments and environments
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.
- manage_project and manage_environment create and update. Neither can delete
- list_sdk_keys shows the last four characters of each key. manage_sdk_key creates, renames or revokes one, and shows a new key in full exactly once so an agent can write it into an .env file
- manage_segment creates, updates or deletes a segment, and manage_targeting_rule adds, updates, removes or reorders a single rule
- get_flag, get_targeting and get_segment return an etag, and update_flag, update_targeting and segment updates take it back as ifMatch. From 0.3.0 those writes return the new etag as well
- Every tool declares an outputSchema and returns structuredContent, so a client can type-check a result instead of parsing text
- The featureflip-mcp-<version>.mcpb bundle installs in Claude Desktop with one click and asks for the API token in its own settings. It needs Node.js 20.19 or later
-
Integration
The cleanup Action inlines the methods that wrap a flag
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.
- A method, Kotlin property getter, Kotlin top-level function or C# get-only bool property whose whole body reads the flag is inlined at every call its file proves is bound to it, then deleted once no caller is left
- A call that cannot be proven bound is left alone, and the pull request lists it with the reason. Set inline-wrappers: false to fold only inside the method, as earlier versions did
- A key constant declared in one file and read in another is now resolved in C#, Dart, PHP, Python and Swift, as well as Java, Kotlin, TypeScript and JavaScript
- Enum entries holding a key now resolve in Dart, PHP and Python too, joining Java, Kotlin and TypeScript
- archive-sweep takes a deployed-refs input, the tags, branches or commits that stand for what is deployed. A flag is archived only once its removal is in every one of them
- A local that only the removed branch used is deleted when it holds a literal, now in Swift, PHP and Ruby too, and PHP drops a use statement that only that branch needed
-
Platform
Default flag lifetime for a project
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.
- Set it under Project Settings, from 1 to 3650 days, and see how many flags it would mark expired before you save
- A flag with its own expiry date keeps that date, and permanent flags never expire
- The flag header and the Expired marker say when an expiry came from the project default
- Available on /api/v1 (PUT .../projects/{project}/default-flag-lifetime and a preview at .../impact), with effectiveExpiresAtUtc and expirySource on every flag
- The MCP tool find_stale_flags counts flags past the project default as expired
- Every plan, Free included
-
Platform
Permanent flags
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.
- Mark a flag permanent when you create it or from its header, and make it temporary again at any time
- Permanent flags show a Permanent badge instead of Stale or Dead, and drop out of the Stale and Dead filters
- Cleanup notice emails, removal candidates and the flag cleanup Action all skip them
- A permanent flag cannot have an expiry date. On a dated flag the dashboard asks, then removes the date and marks the flag in one step
- Available on /api/v1 (isPermanent on create, PUT and DELETE on .../flags/{flag}/permanent) and through the MCP tool set_flag_permanent
- Every plan, Free included. Marking and unmarking appear in the audit log as their own actions
-
Integration
OpenFeature provider for Ruby
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.
- Boolean, string, number, integer, float and object resolution through the standard openfeature-sdk client
- PROVIDER_CONFIGURATION_CHANGED fires with the changed flag keys, including flags pulled in by an edited segment or a changed prerequisite
- ruleId and prerequisiteKey arrive in flag_metadata, and an unmet prerequisite resolves as PREREQUISITE_FAILED
- targeting_key is written under both user_id and userId, so a rule on either spelling matches
- The Featureflip flag cleanup Action recognizes fetch_boolean_value reads, so a removed flag is cleaned up at those call sites too
- Needs featureflip 2.10.0 or newer. Apache 2.0, like every Featureflip SDK
-
Integration
The cleanup Action follows a flag key to where it is declared
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.
- A key constant declared in one file and read in another is resolved in Java, Kotlin, TypeScript, TSX and JavaScript, including a Kotlin companion object and a .tsx component reading a constant from a .ts module
- A key held in an enum entry is resolved in Java, Kotlin and TypeScript, and so is a property of an exported TypeScript as const object. The entry itself stays, and the pull request lists it
- Mocks of the removed read are resolved in Java, Kotlin, Dart, TypeScript, Go and C#. A stub returning the kept value is deleted, and a test whose stub returns the removed value is deleted too and named in the pull request
- A flag that another live flag uses as a prerequisite is reported as blocked and proposed once nothing depends on it, so archiving it can't switch its dependents off
- Imports and locals a removal leaves unused are now deleted in TypeScript, Dart and Kotlin, and the pull request names any import kept for its side effects. Python gets the locals deleted too, but an import there is never removed. It keeps every byte and gains # noqa: F401 so ruff and flake8 still pass
- mode: archive-on-merge is deprecated and prints a warning on every run until the next major version removes it. Run archive-sweep on a schedule instead, plus archive-on-deploy if your pipeline creates GitHub Deployments
-
SDKs
Client SDKs report the flags your app actually reads
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.
- The typed variation methods and flagDetail count as reads, and so does every useFeatureFlag call in React. Each flag, variation and user is reported about once an hour, and again when the page or app returns to the foreground
- Two numbers move as your apps upgrade. Client-side evaluation counts drop, because they now count reads, and a flag that is sent but never read can start showing as stale
- In Flutter, a flag your app reaches only through allFlags() looks unused, so it can be marked stale
- sendEvaluationEvents: false opts a client out, and Featureflip then treats every flag it sends that client as in use, as before
- Needs @featureflip/browser or @featureflip/react 2.11.0, Swift 3.3.0, Android 3.3.0 or Flutter 2.7.0
-
Integration
Flag owners in the MCP server
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.
- A new set_flag_owner tool takes a member's email, "me" for the token's own user, or null to clear the owner
- create_flag accepts ownerEmail
- list_flags and find_stale_flags filter by owner with an email, "me", or "none" for unowned flags, and find_stale_flags reports each candidate's owner
- update_flag changes only the fields you pass, so leaving out the description no longer erases it
- Setting an owner needs Pro or above. Clearing one works on every plan
-
Platform
Flag owners
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.
- Pick an owner on the Create Flag page, or use Set owner and Change owner in the flag header
- The flags list has an Owner column and a filter for Any owner, Mine, Unowned or any member
- Removing a member offers Reassign their flags to, and leaving it unset makes their flags unowned
- The Management API sets the owner with PUT /flags/{flag}/owner, clears it with DELETE, accepts ownerEmail when a flag is created, and filters the flag list with ?owner=
- Every flag response carries an owner object, or null when the flag is unowned
- Available on Pro, Business and Enterprise. Below Pro the creator is stored as owner and appears once you upgrade
-
Platform
Cleanup notices for flags that are ready to remove
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.
- A flag qualifies when it passes its expiry date or goes Dead, meaning a staleness signal has held for 90 days
- One digest per person per organization, sent daily at 14:00 UTC, grouped by project
- Each flag is announced once, and a flag that qualifies again later waits at least 30 days for another notice
- Archived flags never get notices
- Turn them off under Email Preferences with the Flag cleanup notices switch, or with the unsubscribe link in any notice. Account and security email is unaffected
-
Platform
Single sign-on with your own identity provider
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.
- Connect any OIDC provider with an issuer URL, client ID and client secret, then test the round trip before you activate it
- Step-by-step guides for Okta and Microsoft Entra ID, each with a Terraform configuration for the IdP side
- Prove you own an email domain with a DNS TXT record, and only people on verified domains are admitted
- Add new people automatically as a Viewer, Member or Admin, or admit only the people you have invited
- Require single sign-on so members can only open the organization through your IdP, while Owners keep an audited recovery path
- While SSO is required, only personal access tokens created during an SSO session work against the organization
- People who joined through SSO can add a Featureflip password with Forgot password?, which emails them a link to set one
- Available on Business and Enterprise. SAML and SCIM are on Enterprise
-
Platform
New plans: Free for up to 3 people, and a Team tier
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.
- Free covers up to 3 team members, 1 project, 2 environments and 10 flags, and it does not expire
- Team is $49 a month ($39 billed annually) for 5 team members, 3 projects, 3 environments, unlimited flags, scheduled changes, 30-day audit logs and email support
- Pro is $99 a month ($79 billed annually) for 10 team members, 10 projects and 5 environments, and adds flag owners, so every flag can name the person responsible for removing it
- Business is $249 a month ($199 billed annually) for 25 team members, 25 projects, unlimited environments and 90-day audit logs
- Business adds single sign-on through your own identity provider over OIDC, and an organization can require it for every member
- Targeting, rollouts, all 13 SDKs, the Management API, the MCP server, the Terraform provider, the audit log and automated flag cleanup stay on every plan, Free included
- An existing subscription keeps its current price until you switch between monthly and annual billing, which moves it to the current rate
-
Platform
Outbound webhooks for configuration changes
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.
- Subscribe to any of 29 event types across flags, targeting rules, variations, segments, environments, projects, SDK keys, API tokens and the organization, or leave the list empty to receive all of them
- Scope a subscription to chosen projects and environments, so a staging pipeline never hears about production toggles
- Every delivery carries webhook-id, webhook-timestamp and webhook-signature headers, and the signature is an HMAC-SHA256 over the id, the timestamp and the raw body
- A failed delivery is retried five times, backing off from 10 seconds to 2 hours, and any 2xx response counts as success
- The delivery log shows status, attempts and the last response for each event, and any delivery can be sent again once your endpoint is fixed
- A test event checks a new subscription end to end without waiting for a real change
- Rotating a signing secret keeps the old one valid until you retire it, and each request is signed with every active secret during the overlap
- The Management API covers the same ground at /api/v1/orgs/{org}/webhooks, including deliveries, redelivery, tests and secret rotation
- @featureflip/mcp 0.1.8 adds four webhook tools, so an AI agent can list subscriptions, read the delivery log, send a test or redeliver, and create, update or rotate a subscription with an Admin token
- Terraform provider 0.3.0 adds featureflip_webhook and featureflip_webhook_secret, so a subscription and its secret rotation can be reviewed in a pull request, plus a data source listing the event types
-
Platform
Expiration dates for temporary flags
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.
- An optional Expires on field on the Create Flag page, plus a Set expiry control on every existing flag
- Past its date, a flag is marked Stale with the reason PastExpiry, and the flag header and flags list show it as Expired
- PastExpiry applies as soon as the date passes, with no 30- or 90-day observation window like the traffic-based signals
- Extending the date or removing it clears the stale marking straight away
- Dates are whole UTC days, and a flag expires at the end of its chosen day in UTC
- A passed date alone never makes a flag a removal candidate for the flag cleanup Action, which still waits for traffic to agree
- The Management API sets and clears the date at /flags/{flag}/expiry and accepts expiresAtUtc when a flag is created
- @featureflip/mcp 0.1.8 adds set_flag_expiry and an expiresAtUtc option on create_flag, and find_stale_flags now reports each expired flag however recently it was edited
-
Integration
Archive a flag when its removal deploys
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.
- A flag the platform can still see traffic for reports deferred and exits 0, instead of turning an ordinary removal merge into a red build
- mode: archive-sweep runs on a schedule and retries those, finding every flag whose removal pull request merged while the flag itself is still live
- Nothing is written down to mark a deferral, so the sweep has no state to reset and re-running it costs nothing
- mode: archive-on-deploy fires on deployment_status and archives only the flags whose removal the deployed commit contains, asked of GitHub's compare endpoint
- A deployment to any environment other than the one named in deployment-environment archives nothing and says so, as does any status that is not success
- A merged removal the deploy does not contain is reported pending-deploy and left for the deploy that ships it
- Both modes need GITHUB_TOKEN: the sweep asks for pull-requests: read, and archive-on-deploy asks for contents: read as well
- Neither closes the case of clients you cannot update, where old versions keep evaluating a flag whatever you deploy
-
Platform
Sign in with GitHub
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.
- Continue with GitHub appears on both the sign-in and the sign-up screen, on every plan including Free
- Featureflip asks for the user:email scope and reads your primary address from it, which is the only place GitHub reports whether an address is verified
- A public profile address that differs from your primary one is ignored, so the account is created under the address that was actually checked
- A GitHub account whose primary address is unverified is turned away rather than signed in
- An existing Featureflip account under the same verified address is linked to GitHub, and either your password or GitHub works from then on
- Two-factor authentication still applies, so an enrolled account is asked for its one-time code once GitHub hands you back
- Enterprise SAML and SCIM are unchanged and stay on the Enterprise plan
-
Integration
OpenFeature provider for PHP
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.
- Boolean, string, integer, float and object resolution through the standard OpenFeature PHP client
- targetingKey is written under both user_id and userId, so a targeting rule against either spelling matches, unless you already supplied one yourself
- An unmet prerequisite surfaces as the custom reason PREREQUISITE_FAILED, because no standard OpenFeature reason models one
- A DateTime-valued context attribute is converted to ISO-8601 before evaluation, recursing into nested arrays
- The open-feature/sdk PHP package has no provider-events API, so flag changes arrive on the underlying SDK's poll interval rather than as a PROVIDER_CONFIGURATION_CHANGED push. Needs featureflip/featureflip-php 3.3.0 or newer
- The Featureflip flag cleanup Action recognizes OpenFeature PHP reads, so a removed flag is cleaned up at those call sites too
- Apache 2.0, the same license as every Featureflip SDK
-
Integration
OpenFeature .NET catches up on four SDK releases
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.
- Resolves Featureflip.Client 2.9.0 instead of 2.7.0, so four releases of evaluation and delivery fixes reach OpenFeature call sites
- A Before or After date operand has to be ISO-8601 or a Unix timestamp in seconds. Formats like 05/15/2023 and Jan 1 2024 resolved in .NET alone and matched nothing in the other six SDKs, so one saved rule targeted differently depending on which language read it
- Date operands are case-sensitive, so 2024-01-31T09:30:00Z matches where the lowercase spelling matches nobody
- An operator the SDK does not recognize now fails closed. It used to return false, which a negated condition flipped to true, so a config naming an unknown operator could serve the flag to everyone
- Config fetches survive an unknown flag type, so a new type added server-side cannot blank out every flag you serve
- Analytics events survive a transient failure of the events endpoint instead of being dropped, with the queue bounded at 10,000 events
- The NuGet listing renders release notes, which it had never done for any version
-
Integration
Re-run a flag cleanup pull request from a comment
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.
- Comment @featureflip-cleanup rerun to regenerate a removal from the pull request's own base branch. It refuses when the branch carries commits the Action did not make
- @featureflip-cleanup recreate regenerates anyway and discards those commits
- Both commands push under a lease on the branch's current commit, so the push fails if someone writes to the branch mid-run
- They run as mode: pr-command in their own issue_comment workflow, and only for someone with write access to the repository
- A new flags input limits a sweep to the flag keys you list, and a key that is also in ignore stays skipped
- In TypeScript and JavaScript modules, top-level bindings a removal leaves unused are now cleaned up, including import x = require() and a single-name destructured require
-
Integration
GitHub Action that removes dead flags from your source
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.
- Thirteen languages: TypeScript, TSX, JavaScript, PHP, Ruby, ERB, Dart, Java, Go, Python, Kotlin, C# and Swift
- One reviewable pull request per flag, with max-prs to bound a first run and dry-run to change nothing at all
- Two safety gates parse every rewritten file and discard the whole transform if it introduced breakage, so a rewrite it cannot verify never reaches a pull request
- Opt into mode: archive-on-merge and the flag is archived when its removal pull request merges
- Every released tag names one exact image digest, so a run stays reproducible even though @v1 moves
- Source and issues at canopy-labs/featureflip-flag-cleanup-action
-
SDKs
Flag change subscriptions in the Go and Java SDKs
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.
- Go 2.8.0 adds Client.OnUpdate, which takes a func(flagKeys []string) and returns a func that unsubscribes
- Java 2.9.0 adds FeatureflipClient.onUpdate, which takes a FlagUpdateListener and returns a Runnable that unsubscribes
- Python has had client.on_update and client.off_update since featureflip 2.7.0, released on August 28
- An update also names flags whose value moved without their own configuration changing: those whose rules reference an edited segment, and those that depend on a changed flag through a prerequisite
- The initial flag load does not fire, and neither does a poll or reconnect that changed nothing
- A listener that panics or throws is logged and skipped, and flag delivery carries on
- Closing a client handle drops the listeners it registered
-
Integration
OpenFeature provider for Java
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.
- Boolean, string, integer, double and object resolution through the standard OpenFeature Java client
- The targeting key maps to the user id that percentage rollouts bucket on, unless you supplied one explicitly
- A wrong-typed flag is reported as TYPE_MISMATCH, distinctly from a genuine evaluation failure
- An unmet prerequisite surfaces as the custom reason PREREQUISITE_FAILED, because no standard OpenFeature reason models one
- PROVIDER_CONFIGURATION_CHANGED fires when flag configuration changes, naming the keys that moved
- The Featureflip flag cleanup Action recognizes OpenFeature Java reads, so a removed flag is cleaned up at those call sites too
- Apache 2.0, the same license as every Featureflip SDK
-
Integration
OpenFeature provider for Go
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.
- Boolean, string, integer, float and object resolution through the standard OpenFeature Go client
- The targeting key maps to the user id that percentage rollouts bucket on, unless you supplied one explicitly
- An unmet prerequisite surfaces as the custom reason PREREQUISITE_FAILED, because no standard OpenFeature reason models one
- PROVIDER_CONFIGURATION_CHANGED fires when flag configuration changes, naming the keys that moved. Needs the Go SDK 2.8.0 or newer
- The Featureflip flag cleanup Action recognizes OpenFeature Go reads, so a removed flag is cleaned up at those call sites too
- Apache 2.0, the same license as every Featureflip SDK
-
Integration
OpenFeature provider for Python
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.
- Boolean, string, integer, float and object resolution through the standard OpenFeature Python client
- targeting_key maps to the user_id field that percentage rollouts bucket on, unless you already supplied one
- An unmet prerequisite surfaces as the custom reason PREREQUISITE_FAILED, because no standard OpenFeature reason models one
- PROVIDER_CONFIGURATION_CHANGED fires when flag configuration changes, naming the keys that moved. Needs featureflip 2.7.0 or newer
- Apache 2.0, the same license as every Featureflip SDK
-
Integration
The MCP server is in the official MCP Registry
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.
- Listed as io.github.canopy-labs/featureflip, installed from the @featureflip/mcp package on npm
- The listing describes the stdio transport and the three environment variables: FEATUREFLIP_TOKEN, which is required, plus the optional API URL and organization
- Each release of @featureflip/mcp publishes a matching registry version, starting with 0.1.3
- Works on every plan, Free included, with a personal or service token
-
SDKs
One date grammar across every SDK
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.
- The JavaScript, Node.js, Python, Go, Java, Ruby, PHP and .NET SDKs share one date grammar: ISO-8601, or a Unix timestamp in seconds
- A date that names no real calendar day, such as 2024-02-30 or 2023-02-29, matches nothing instead of rolling into the following month
- The Management API rejects a non-conforming operand on write, so a rule saved from this release onward cannot carry one. Rewrite any older rule that uses another format
- Analytics events go back on the queue after a failed send rather than being dropped, in every SDK including Android, Swift and Flutter
-
SDKs
Evaluation inspectors across the server SDKs
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.
- onEvaluation inspectors in the JavaScript, Node.js, Python, Go, Java, Ruby and PHP SDKs
- Flag-change notifications in the JavaScript and Node.js SDKs (client.on('update')) and the .NET SDK (FlagsChanged), batched into one call and resolved back through prerequisites
- A served variation key the flag does not define now reports an error reason and hands back your default, instead of a success reason that was quietly wrong
-
Integration
Terraform provider on the Registry
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.
- Resources for projects, environments, feature flags, per-environment flag config, segments and SDK keys
- Data sources for reading an organization, project, environment, flag or segment that Terraform does not manage
- terraform import for flags and projects that already exist, so adoption does not start with a teardown
- Source and issues at canopy-labs/terraform-provider-featureflip
-
Integration
OpenFeature providers for Node.js and .NET
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.
- Boolean, string, number and object resolution through the standard OpenFeature client
- Context mapping from OpenFeature targetingKey to the Featureflip user key, with reason and error mapping preserved
- Tracking forwards through to the OpenFeature track() API
- Apache 2.0, the same license as every Featureflip SDK
-
Integration
Manage flags from Claude Code and Cursor
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.
- One npx command and a config block, authenticated with a Personal Access Token
- Works in Claude Code, Cursor, and every other MCP client
- Tools for creating, toggling, targeting, archiving and auditing flags, plus finding the stale ones
- Included on the Free plan, not held back for paid tiers
-
API
Management API, on every plan
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.
- Personal Access Tokens for people, organization-scoped Service Tokens for CI
- Idempotency-Key on creates, so a retried request cannot double-write
- X-RateLimit headers on every response and a frozen, machine-readable error envelope
- Cursor pagination and a generated OpenAPI reference for every endpoint
Per-version detail for each SDK, including patch releases, lives in that package's CHANGELOG on GitHub. Longer write-ups of the bigger releases are on the blog.
Try what shipped
The API, the MCP server, and the Terraform provider are all on the Free plan. No card.