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
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 Solo
- 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
-
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
-
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 Solo 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 Solo plan. No card.