OpenFeature is an open specification for feature flagging, with SDKs that implement it in the major languages. Feature flags let a team turn behaviour on or off at runtime, release to a percentage of users, or target a cohort, without deploying new code. Each flag vendor ships its own SDK, so flag calls spread through the codebase and tie it to one product. OpenFeature puts a standard API in the application and moves the vendor-specific part into a provider, which means the backend, whether a commercial service, an open-source server or a file, can be replaced by configuration. The project joined the CNCF Sandbox in June 2022 and was accepted as Incubating, with the announcement published on December 19, 2023. It integrates with OpenTelemetry so flag evaluations can be traced alongside requests.
CNCF daily · Sprint 1, day 7 · Feature Flagging
At a glance
| Category | Feature Flagging |
| CNCF status | Incubating. Sandbox June 2022; Incubating announced December 19, 2023 |
| Written in | Specification plus SDKs in many languages, including Go, Java, JavaScript, .NET, PHP, Python and Ruby |
| License | Apache 2.0 |
| Core concepts | API, client, provider, evaluation context, hooks and flag evaluation details |
| Reference backend | flagd, a small flag evaluation daemon, with a Kubernetes operator |
| Remote protocol | OpenFeature Remote Evaluation Protocol (OFREP) for HTTP evaluation |
| Providers | Commercial and open-source backends, including LaunchDarkly, Split, CloudBees, Flagsmith, Flipt, GO Feature Flag, Harness, PostHog and Unleash |
Architecture
flowchart TB
APP[Application code<br/>OpenFeature API and client] -->|evaluate flag with context| SDK
subgraph S[OpenFeature SDK]
SDK[Client and evaluation<br/>context merging] --> HOOKS[Hooks<br/>logging, tracing, metrics]
SDK --> PROV[Provider<br/>vendor adapter]
end
PROV -->|in process or remote| FLAGD[flagd<br/>sidecar or service]
PROV -->|vendor API| VENDOR[Commercial or open-source<br/>flag service]
FLAGD --> SRC[Flag definitions<br/>file, ConfigMap, Git, HTTP]
OP[OpenFeature Operator<br/>FeatureFlag resources] -->|injects and configures| FLAGD
HOOKS --> OTEL[OpenTelemetry<br/>traces and metrics]
| Component | Responsibility |
|---|---|
| API and client | The stable interface that application code calls to evaluate boolean, string, number and object flags with a default value. |
| Provider | The adapter between the API and a flag backend. Swapping providers changes the backend without touching call sites. |
| Evaluation context | Data such as user ID, region or plan, passed with each evaluation so the backend can target and split traffic. |
| Hooks | Extension points before and after evaluation, used for logging, validation, metrics and tracing. |
| flagd | A lightweight daemon that evaluates flags from a definition source and streams changes, usable as a sidecar or shared service. |
| OpenFeature Operator | Manages flag definitions as Kubernetes resources and injects and configures flagd for annotated workloads. |
| OFREP | A standard HTTP protocol for remote flag evaluation, so a provider can be written once for many backends. |
Design principle. OpenFeature standardises the application-facing contract and leaves the decision logic to the backend. A flag evaluation always returns a value, falling back to a default in code if the provider fails, so a flag service outage does not stop the application.
Production reference design
A common pattern on EKS, GKE, AKS or on-premises Kubernetes: flagd as a sidecar managed by the operator, flag definitions kept in Git, and the SDK wired into application code and tracing.
- Choose the backend. Use flagd with flags in Git for a self-hosted, GitOps approach, or select a vendor provider if product teams need a managed UI and experimentation. The application code stays the same either way.
- Install the operator. It depends on cert-manager for its webhook certificates:
Check the chart name and its prerequisites against the version you install.helm repo add openfeature https://open-feature.github.io/open-feature-operator/ helm install open-feature-operator openfeature/open-feature-operator \ -n open-feature-operator-system --create-namespace - Declare flags as resources and keep them in Git, delivered by Argo CD or Flux:
Verify the schema against the operator version, since the flag definition format is evolving.apiVersion: core.openfeature.dev/v1beta1 kind: FeatureFlag metadata: { name: orders-flags, namespace: orders } spec: flagSpec: flags: new-checkout: state: ENABLED variants: { "on": true, "off": false } defaultVariant: "off" targeting: if: - { "in": [ { "var": "region" }, ["ap-south-1"] ] } - "on" - "off" - Enable injection on the workload with annotations, so the operator adds a flagd sidecar that reads the flag resource:
metadata: annotations: openfeature.dev/enabled: "true" openfeature.dev/featureflag: "orders-flags" - Use the SDK in the application. Set the provider once at start-up, evaluate with a default value and a context:
Use the provider package for flagd or your vendor, and read its docs for the connection settings.import { OpenFeature } from '@openfeature/server-sdk'; const client = OpenFeature.getClient(); const on = await client.getBooleanValue('new-checkout', false, { region: 'ap-south-1' }); - Add hooks for visibility. Attach the OpenTelemetry hook so each evaluation appears on the request trace, and record flag values in logs, which makes a flag-related incident easy to trace.
- Govern the lifecycle. Give each flag an owner and an expiry, remove it after full rollout, and review stale flags regularly.
Typical production uses include progressive delivery behind a flag, kill switches, targeted rollouts by region or plan, A/B tests and switching providers without a code change.
Operational considerations
- Always set safe defaults. The default in code is what runs if the provider is unreachable. Choose it as the safest behaviour, usually the old path.
- Treat flags as technical debt. Long-lived flags multiply code paths and test cases. Track owners and remove flags once a rollout is complete.
- Mind evaluation context. The context may carry user identifiers. Send only what targeting needs, and avoid personal data where you can.
- Watch the latency path. In-process and sidecar evaluation is fast, but a remote provider adds a network call. Cache sensibly and set timeouts.
- Control who can change flags. A flag change is a production change. Keep definitions in Git with review, or enforce access control and audit logs in the vendor service.
- Track specification maturity. The core API is stable, but parts such as the remote protocol and flag definition format are still evolving. Pin SDK, provider and operator versions.
Adoption
- The CNCF incubation announcement names the vendors LaunchDarkly, Split, CloudBees and Flagsmith as supporters, and lists providers including ConfigCat, DevCycle, Flipt, GO Feature Flag, Harness, PostHog and Unleash.
- The same announcement names end users eBay, Google, SAP and Spotify.
- It reports growth since the Sandbox: about 700 percent more repository stars, 350 percent more forks and 627 percent more Slack members, with over 200 contributors at the time.
Alternatives
| Solution | Model | Best suited to |
|---|---|---|
| Vendor SDKs directly (LaunchDarkly, Split and others) | Proprietary SDK tied to one service | Teams committed to a single vendor |
| Unleash | Open-source feature flag server, also an OpenFeature provider | Self-hosted flag management with a UI |
| Flagsmith, Flipt and GO Feature Flag | Open-source flag platforms, with OpenFeature providers | Teams that want open source with different UI or storage trade-offs |
| Homegrown flags (config files, environment variables) | Simple custom code | Small systems with few, short-lived flags |
| Progressive delivery tools (Argo Rollouts, Flagger) | Traffic shifting at the deployment layer | Canary releases without in-code flags |
Strengths and limitations
| Strengths | Limitations |
|---|---|
| One API in the code, with the backend swappable by provider | It standardises the client side only, so backend features still differ |
| Wide provider and language support, commercial and open source | Provider quality and feature coverage vary |
| Hooks and OpenTelemetry integration make flags observable | Parts of the specification, such as the definition format, are still maturing |
| flagd and the operator allow a GitOps, self-hosted setup | Flags add code paths and need active clean-up |
| Defaults make evaluations safe when the backend is down | Remote evaluation adds latency and a dependency if not cached |
Recommendation
Adopt OpenFeature as the flag API in new services and as the migration path away from vendor-specific SDKs, starting with flagd and Git-managed flags or a provider for your existing vendor. Set safe defaults, add the OpenTelemetry hook, and give every flag an owner and an expiry. Assess a full flag management platform behind it if product teams need a UI, audit trail and experimentation.
References: CNCF project page · CNCF blog: OpenFeature becomes a CNCF Incubating project · SiliconANGLE: CNCF names OpenFeature an incubating project · OpenFeature documentation · OpenFeature on GitHub