Product feature

Feature flag SDKs

Official libraries for 13 languages and frameworks. Server SDKs evaluate flags locally in sub-milliseconds, every SDK streams live updates over SSE, and the same flag returns the same answer on every platform.

Last updated:

Featureflip ships 13 official SDKs, eight for server languages and five for client platforms. A server SDK holds the flag configuration in memory and evaluates the context you pass locally, so a flag check adds no network round trip and stays sub-millisecond. Every SDK keeps its configuration current over a streaming connection, and because the evaluation logic is shared and vector-tested, a given flag and context return the same variation in every language. Anything without a dedicated SDK can call the Evaluation API directly over HTTP.

Get started free Browse the SDK docs

Server SDKs: evaluate locally

Client SDKs: stream to the browser and mobile

Prefer a vendor-neutral API? OpenFeature providers wrap the Node.js, .NET, Python, Go, Java, PHP and Ruby SDKs behind the OpenFeature standard, so you can evaluate Featureflip flags through the CNCF open standard and keep your application code portable. See the OpenFeature glossary entry for how the standard fits together, or the provider walkthrough for the setup in code.

What the SDKs give you

The same guarantees in every language: evaluate fast, stay current, fail safe, and get the same answer everywhere.

Thirteen official SDKs

Server libraries for JavaScript and TypeScript, Node.js, Python, Go, Java, C#, Ruby, and PHP, plus client libraries for React, the browser, Swift, Flutter, and Android. Each is a drop-in package published to the registry your stack already uses, so adding Featureflip is an install and a few lines rather than a new service to run.

Local evaluation on the server

Server SDKs hold the full flag configuration in memory and evaluate the context you pass locally, so a flag check is a function call with no network round trip on the request path. That keeps evaluation sub-millisecond and safe to call in a hot loop, and it means your app keeps serving flags even during a blip reaching Featureflip.

Live updates over Server-Sent Events

Every SDK keeps an open SSE connection and receives configuration changes as they happen, typically within a second or two, with no polling. Flip a flag or move a rollout in the dashboard and connected SDKs pick it up on the next evaluation, fleet-wide, without a redeploy.

One consistent API

The call shape is the same in every language: ask for a flag by key, pass the evaluation context, and give a default. boolVariation, stringVariation, and their siblings behave the same way across SDKs, so a pattern you learn in one service carries straight to the next.

The same result on every platform

The evaluation logic is shared across the SDKs and checked against one common set of test vectors, so a given flag and context return the same variation whether the check runs in Go on the server or Swift on a phone. Targeting, percentage bucketing, and prerequisites resolve identically everywhere.

Fail-safe by default

Every evaluation takes a default value, and the SDK returns it if the flag is missing or the service is briefly unreachable, falling back to the last configuration it held rather than failing the request. Flags degrade to a known-safe answer instead of taking your app down with them.

For the full API of each library, streaming options, and configuration, start with the SDK overview. Each SDK has its own reference and a quickstart. For why reconnect behavior deserves as much attention as the local cache, read the hard part of a flag outage is recovery.

Adding a flag to your app, step by step

The same four moves in any language. Install, initialize with a key, evaluate with a default, and let it stream.

  1. 1

    Install the SDK for your stack

    Add the Featureflip package from your language registry, whether that is npm, PyPI, NuGet, Maven, or another. Pick a server SDK for a backend service and a client SDK for a browser or mobile app.

  2. 2

    Initialize it with your environment key

    Create the client with the SDK key for the environment the app runs in, read from an environment variable. The key decides which environment configuration the SDK receives, so the same code serves development locally and production in production.

  3. 3

    Evaluate a flag with a default

    Ask for the flag by key, pass the context that describes the user or request, and supply a default. The SDK returns the variation, evaluated locally, and the default if the flag is missing or not yet loaded.

  4. 4

    Let it stream updates

    Leave the client running as a long-lived singleton. It keeps its configuration current over SSE, so a change you make in the dashboard reaches your app in seconds without a redeploy or a polling loop.

What it looks like in your app

A server SDK is a singleton you create once and reuse. It loads the configuration in the background, keeps it current over SSE, and evaluates locally on every call. Here it is in Node: 

// npm install @featureflip/node
import { FeatureflipClient } from '@featureflip/node';

const client = FeatureflipClient.get({
  sdkKey: process.env.FEATUREFLIP_SDK_KEY,
});

// evaluated locally, in-memory; returns the default if anything is missing
if (client.boolVariation('new-checkout', { user_id: user.id }, false)) {
  renderNewCheckout(user);
}

The shape is the same in every SDK: get a client with your environment key, then call a variation method with a flag key, a context, and a default. Pick your platform from the SDK overview, and see the Node quickstart for the full first-flag walkthrough.

What sub-millisecond evaluation means, and how we measured it

A server SDK evaluation is a function call against a flag configuration that already sits in your process memory. Nothing is fetched. The SDK matches the context you passed against the flag's rules and segments, hashes your user key if a percentage rollout applies, resolves any prerequisite flags, and returns a variation.

We time that evaluator on production traffic through our own hosted Evaluation API. The clock starts when the evaluator receives a flag, a context and the environment's segments, and it stops when a variation comes back. Loading the configuration sits outside the window on purpose, because that is a startup cost your request path pays once and never again.

Across a 30-day production window ending September 19, 2026:

Evaluation completed in Share of evaluations
Under 50 microseconds89%
Under 100 microseconds96%
Under 500 microseconds98.5%
Under 1 millisecond99.5%
Mean0.054 ms

That is our own traffic in production rather than a lab benchmark. The figure also does not move with how busy we are, because a dictionary lookup and a short run of comparisons over data already in memory costs the same at a hundred evaluations a day as at a million.

The measurement is taken in our Evaluation API, which runs the same evaluator your server SDK runs. Every server SDK is checked against one shared set of test vectors generated from that engine, so the algorithm and the answers it gives are identical across languages. On your side it runs on your own hardware, against however many flags you have defined.

The number covers evaluation and nothing else. Your application code, the network between your users and your servers, and whatever your web framework does on either side of the call are all outside it. Client SDKs in a browser or on a phone receive pre-evaluated values over their streaming connection, so a flag read there is a local lookup too, though getting those values to the device crosses the network once.

One flag model across your whole stack

The SDKs are the delivery layer for everything else Featureflip does, and they present it the same way in every language:

  • Targeting and percentage rollouts resolve in the SDK. You pass the evaluation context; the SDK applies the rules, the rollout bucketing, and any prerequisites locally, and hands back the variation.
  • The environment is chosen by the key. The SDK key you initialize with decides which environment configuration the client reads, so the same build serves development and production.
  • Streaming keeps every client in sync. A change in the dashboard reaches your Go backend and your Swift app over the same SSE mechanism, so nothing drifts between platforms.
  • Front-end and back-end share one source of truth. A client SDK in the browser and a server SDK in your API evaluate against the same configuration, so a user sees a consistent experience across both.
  • The configuration itself is scriptable. The Management API creates and toggles the flags your SDKs serve, so CI can seed a flag before the code that references it deploys.
  • Cleanup reaches the same languages. When a flag is finished, the cleanup Action removes its code across TypeScript, JavaScript, Java, Go, Python, C#, PHP and Ruby, and across the mobile stack too: Kotlin, Swift and Dart. The flag leaves your Android and iOS code the same way it leaves your API, by pull request.

That is what lets one flag drive a progressive rollout across services, a kill switch that trips everywhere at once, and an A/B test whose assignment matches on the server and the client.

Frequently asked questions

Which languages and frameworks does Featureflip have SDKs for?
Featureflip publishes 13 official SDKs. On the server there are libraries for JavaScript and TypeScript, Node.js, Python, Go, Java, C#, Ruby, and PHP. On the client there are libraries for React, the browser, Swift, Flutter, and Android. Anything without a dedicated SDK can integrate directly with the Evaluation API over HTTP, so no platform is left out.
Do the SDKs evaluate flags locally or call an API?
Server SDKs evaluate locally. Each one holds the full flag configuration in memory and matches the context you pass in process, so a flag check is a function call with no network round trip on the request path. That keeps evaluation sub-millisecond and safe to call in a hot loop. The configuration is kept current in the background over a streaming connection, so local evaluation never means stale flags.
How fast is a flag evaluation, and how do you measure it?
A server SDK evaluation is an in-memory function call, so it costs a function call and a handful of comparisons with no network round trip. Measured on production traffic through our hosted Evaluation API over the 30 days to September 19, 2026, about 89% of evaluations finished inside 50 microseconds, 96% inside 100 microseconds and 99.5% inside a millisecond, with a mean of 0.054 ms. That timing covers the evaluator itself: matching rules and segments, hashing the rollout bucket, and resolving prerequisites. Loading the configuration happens once at startup and sits outside the measurement. Your own SDK runs the same evaluator, checked against shared test vectors, on your hardware.
How do the SDKs get updates when I change a flag?
Every SDK keeps an open Server-Sent Events connection to Featureflip. When you change a flag, a targeting rule, or a rollout in the dashboard, the new configuration streams to connected SDKs within a second or two, fleet-wide, and takes effect on the next evaluation. There is no polling interval to tune and no redeploy, though server SDKs can fall back to polling if a streaming connection cannot be held.
What happens if an SDK cannot reach Featureflip?
The SDKs fail safe. Every evaluation call takes a default value, and the SDK returns it whenever the flag is missing or has not loaded yet. If the streaming connection drops, the SDK keeps serving from the last configuration it received while it reconnects in the background, retrying with capped exponential backoff and falling back to polling when a stream will not hold. A running SDK does not give up reconnecting, and every reconnect pulls a full configuration snapshot rather than only resubscribing to future changes, so a flag you changed or deleted while an instance was disconnected gets corrected instead of sitting stale. None of that needs an operator to restart anything, and flags degrade to a known-safe answer rather than throwing on the request path.
Are flag evaluations consistent across different SDKs?
Yes. The evaluation logic is shared across the SDKs and verified against one common set of test vectors, so the same flag and the same context produce the same variation in every language. Targeting rules, percentage-rollout bucketing, and prerequisite resolution all behave identically, which means a user bucketed into a variation by your Go backend gets the same variation from your Swift app.
How do I get started with a Featureflip SDK?
Install the package for your stack from its registry, create the client with the SDK key for your environment, and call the variation method for the flag you want. For example, in Node you run npm install @featureflip/node, initialize with FeatureflipClient.get, and call client.boolVariation with a flag key, a context, and a default. Each SDK has a quickstart in the docs that walks through installation and your first evaluation in a few minutes.
Does Featureflip work with OpenFeature?
Yes. Featureflip ships seven OpenFeature providers: @featureflip/openfeature-node for the OpenFeature Node.js server SDK, Featureflip.OpenFeature for the OpenFeature .NET SDK, featureflip-openfeature-provider for the OpenFeature Python SDK, github.com/canopy-labs/featureflip-go-openfeature for the OpenFeature Go SDK, io.featureflip:featureflip-openfeature for the OpenFeature Java SDK, featureflip/featureflip-openfeature for the OpenFeature PHP SDK, and featureflip-openfeature for the OpenFeature Ruby SDK. You get the vendor-neutral OpenFeature API — the same evaluation calls, targeting context, and tracking — while Featureflip serves your flags, so switching cost is a configuration change rather than a rewrite. Node.js, .NET, Python, Go, Java, PHP and Ruby are the languages covered today and more are planned; see the OpenFeature integration guide in the docs to get started.

Add flags to your stack today

Every SDK works on the Free plan: 10 flags, 2 environments, no credit card. Paid plans use flat pricing with no per-seat and no per-evaluation fees, however much traffic you serve.

Get started free Read the SDK docs

Related

SDK overview (docs)

Choose the right SDK, see how keys are used, and jump to each language reference and quickstart.

Environments (feature)

The SDK key selects the environment, so one build serves dev, staging, and production.

Targeting (feature)

Pass an evaluation context and the SDK applies your attribute rules and segments locally.

Percentage rollouts (feature)

Deterministic bucketing runs in the SDK, so every platform pins a user to the same variation.