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 freeBrowse the SDK docs

Server SDKs: evaluate locally

Client SDKs: stream to the browser and mobile

Prefer a vendor-neutral API? An OpenFeature provider wraps the Node.js SDK behind the OpenFeature standard, so you can evaluate Featureflip flags through the CNCF open standard.

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.

Adding a flag to your app, step by step

The same four moves in any language. Install, initialise 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

    Initialise 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.

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 initialise 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.

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 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 are built to 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 and reconnects in the background, so a network blip does not change what your users see. 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, initialise 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 an OpenFeature provider, @featureflip/openfeature-node, that connects the OpenFeature Node.js server SDK to Featureflip. 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 is the first Featureflip SDK with an OpenFeature provider; see the OpenFeature integration guide in the docs to get started.

Add flags to your stack today

Every SDK works on the free Solo 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 freeRead 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.