OpenFeature in 2026: Feature Flags Without Vendor Lock-in

Feature flags are one of those practices that teams discover when they get burned. A big-bang release that went wrong, a rollback that took two hours instead of two minutes, a hotfix that required a late-night deploy because there was no way to turn a feature off without one. After the incident, feature flags become standard.

The second discovery happens later: you are tightly coupled to whatever flag service you chose first, and changing it means touching every evaluation call in the codebase. OpenFeature is the solution to that second problem.

What OpenFeature solves

Every feature flag service ships its own SDK with its own API. Switching from LaunchDarkly to Unleash means finding every call to launchDarkly.variation('flag-name', user, false) and rewriting it to unleash.isEnabled('flag-name'). In a large codebase, that is weeks of work and a non-trivial test surface.

OpenFeature defines a single evaluation API that all compliant providers implement. Your application code calls:

import { OpenFeature } from "@openfeature/server-sdk";

const client = OpenFeature.getClient();
const isEnabled = await client.getBooleanValue("new-checkout-flow", false);

Behind that call can be LaunchDarkly, GrowthBook, Unleash, Flagsmith, or your own flat-file flag definitions. Changing the backing provider is a configuration change at startup, not a code change in your features.

Setting up OpenFeature with GrowthBook

GrowthBook is the most commonly self-hosted option and has an official OpenFeature provider. A minimal setup in Node.js:

import { OpenFeature } from "@openfeature/server-sdk";
import { GrowthBookProvider } from "@growthbook/openfeature-node";
import { GrowthBook } from "@growthbook/growthbook";

// Initialize GrowthBook — fetches flags from your self-hosted instance
const growthbook = new GrowthBook({
  apiHost: process.env.GROWTHBOOK_API_HOST!,
  clientKey: process.env.GROWTHBOOK_CLIENT_KEY!,
  enableDevMode: process.env.NODE_ENV !== "production",
});

await growthbook.loadFeatures({ autoRefresh: true });

// Register the provider with OpenFeature — one line
OpenFeature.setProvider(new GrowthBookProvider(growthbook));

// Use OpenFeature's standard API everywhere in your app
const client = OpenFeature.getClient();

Now any part of your application that needs to check a flag uses the OpenFeature client, not the GrowthBook SDK directly. If you later switch to Unleash or LaunchDarkly, the provider line at startup changes; nothing else does.

Evaluation context: targeting without coupling

The power beyond simple booleans is targeting: a flag that is on for 10% of users, or on for all users in the “beta” group, or on only for a specific tenant ID. OpenFeature handles this through an evaluation context that you set per request:

import { OpenFeature, EvaluationContext } from "@openfeature/server-sdk";

// In your middleware or request handler
const context: EvaluationContext = {
  targetingKey: user.id,
  email: user.email,
  plan: user.plan,        // "free" | "pro" | "enterprise"
  region: req.region,
};

// This evaluation respects whatever targeting rules you defined in GrowthBook
const client = OpenFeature.getClient();
const showNewPricing = await client.getBooleanValue(
  "new-pricing-page",
  false,
  context
);

The targeting rules live in your flag provider’s dashboard. You can change who sees a feature without a deploy and without touching the code.

Hooks: what makes OpenFeature more capable than manual checks

OpenFeature hooks let you attach behavior to every flag evaluation without cluttering your feature code. The most useful patterns:

Logging hook. Record every flag evaluation for debugging:

import { Hook, HookContext, EvaluationDetails } from "@openfeature/server-sdk";

const loggingHook: Hook = {
  after(hookContext: HookContext, evaluationDetails: EvaluationDetails<boolean>) {
    logger.debug("Flag evaluated", {
      flagKey: hookContext.flagKey,
      value: evaluationDetails.value,
      reason: evaluationDetails.reason,
      userId: hookContext.context.targetingKey,
    });
  },
};

OpenFeature.addHooks(loggingHook);

Analytics hook. Send an event every time a feature is evaluated for A/B testing attribution:

const analyticsHook: Hook = {
  after(hookContext, details) {
    analytics.track("feature_evaluated", {
      flag: hookContext.flagKey,
      value: details.value,
      userId: hookContext.context.targetingKey,
    });
  },
};

These hooks apply globally, so you write them once and every flag evaluation in the application is automatically instrumented.

Choosing a provider

Provider	Hosted	Self-hosted	A/B testing	Pricing
LaunchDarkly	Yes	No	Yes	Enterprise ($)
GrowthBook	Yes	Yes	Yes	Free / $200+
Unleash	Yes	Yes	Limited	Free / Enterprise
Flagsmith	Yes	Yes	Limited	Free / $45+
Statsig	Yes	No	Yes	Free / $150+

For most small-to-mid teams, GrowthBook self-hosted covers feature flags and basic A/B testing at no infrastructure cost beyond the server you run it on. The UI is clean, the SDK coverage is good, and OpenFeature support is first-class.

If you are in enterprise and need SSO, audit logs, and SLAs, Unleash Enterprise or LaunchDarkly are the serious options. Both have OpenFeature providers, so you are not locked in.

What this looks like in a full-stack app

The pattern that works well across a full-stack app:

• Server-side evaluations (API routes, middleware) use the OpenFeature Node.js SDK directly, as above.
• Client-side feature flags for UI only (show/hide a component, toggle a layout) use the OpenFeature Web SDK with a browser-compatible provider. These are evaluated after hydration, so account for the flash of wrong content if you are gating layout.
• Feature flags for AI model routing or prompt changes work the same way. See the feature flags for AI features post for the specific patterns around non-deterministic outputs.

When a flat file is enough

Not every application needs a feature flag service. If you are shipping weekly and deploying cleanly, environment variables cover the use case. A JSON file checked into the repo with your flag defaults, loaded at startup, is fine for small teams.

The right time to graduate to a proper flag system is when you want runtime changes without a deploy, when you want targeting by user attribute, or when your release cadence is fast enough that a flag rollback is faster than a hotfix deploy.

OpenFeature makes that graduation cheaper: you write against the standard API from the start, and the provider behind it can be a flat file in development and GrowthBook in production. The calling code never knows the difference.

---

Feature flags are a deployability decision more than a tooling decision. The goal is the ability to ship code before it is “on,” to decouple deploy from release. OpenFeature just makes sure that whichever tool you back that with, you can change your mind without rewriting half the codebase. For the broader architectural context, the monorepo tooling post covers how feature flag configuration fits into a multi-package setup.