Skip to main content

OpenFeature Mid-2026 Update: Platform-Native Feature Flags, a New TC Member, and Spec v0.9.0

· 12 min read
Jonathan Norris
Jonathan Norris
Director Software Engineering at Dynatrace, OpenFeature GC Member

It has been a busy few months since the KubeCon EU 2026 recap. Six large platforms shipped feature flag services supporting OpenFeature, more vendors joined the ecosystem, the Technical Committee grew, and we shipped the largest specification release in over two years.

Platform-Native Feature Flags​

The biggest news of the last year is not something we built. Six well-known platforms launched feature flag services of their own, and each chose OpenFeature as a critical part of its product offering.

  • Datadog launched in late 2025 and describes its product as "built on the OpenFeature standard," now supporting OpenFeature providers across eight languages. Coverage spans server-side Java, Node.js, Python, and Ruby, plus client-side JavaScript, React, iOS, and Android.
  • Vercel Flags became generally available in April, with an OpenFeature provider. Their docs scope it to server-side use, with their own Flags SDK covering client-side and framework-native cases.
  • Cloudflare Flagship was announced in April and reached public beta in May, with providers for both the Workers runtime and the browser. Evaluation happens inside the Workers runtime rather than over the network, and the provider also runs on Node.js, Bun, and Deno.
  • Google Cloud App Lifecycle Manager added feature flags in May, now in public preview. Google describes it as "built on the OpenFeature standard, utilizing industry-standard SDKs and the flagd evaluation engine," making it an adopter of the OpenFeature flagd evaluation engine alongside the API. Notably, there is no Google-specific provider: their quickstart uses the community flagd provider as-is, with guides for Python, Java, and Go.
  • Mixpanel launched feature flags alongside its experimentation suite in June. Its eight OpenFeature providers cover server-side Go, Java, JavaScript, Python, and Ruby, plus client-side JavaScript, Swift, and Kotlin.
  • Octopus Deploy added feature flags in July, in public preview for Octopus Cloud customers. Its documentation states that "Octopus Feature Flags rely on OpenFeature as the client SDK," with providers for server-side .NET and Java, plus TypeScript in the browser.

This is what a standard is for. Each of these teams shipped a product without inventing new APIs and SDKs, so application code stays portable and teams remain free to move between them. We expect this trend to continue and welcome more vendors building on OpenFeature.

New Vendors in the Ecosystem​

Alongside the platforms above, five more projects shipped their first OpenFeature providers:

Existing vendors expanded their language coverage:

If your company has a provider that is not listed, let us know and we will add it to the ecosystem directory.

Welcoming Nicklas Lundin to the Technical Committee​

Nicklas Lundin has joined the OpenFeature Technical Committee. Nicklas is based in Stockholm and works at Spotify on Confidence, an experimentation and feature flagging platform supporting OpenFeature. He has been a dedicated contributor for several years and has driven much of the development and refinement of our mobile SDKs.

Specification v0.9.0​

Specification v0.9.0 is our first spec release since v0.8.0 in March 2024.

The most consequential change (spec#314) stabilizes the evaluation and provider sections and hardens hooks, events, and evaluation context. If you build providers or SDKs, the surfaces you depend on most are now considerably more settled.

The release also gathers up work that had been accumulating: tracking, a logging hook, hook data, a multi-provider appendix, and an observability appendix with refreshed OpenTelemetry semantic conventions. Two changes are worth calling out for implementers. Isolated API instances mean the global singleton is no longer mandatory, which unblocks micro-frontends, dependency injection, and test isolation. Provider lifecycle is now event-driven, so providers own their own status rather than having the SDK infer it, closing a class of initialization races.

Three changes are breaking (spec#280, spec#306, and spec#360), so please read the release notes before upgrading a provider or SDK implementation.

Fourteen people made their first contribution to the specification in this release.

Also Shipped​

  • OFREP gained push updates. Version 0.3.0 (protocol#67) added SSE event streams, and protocol#77 accepted three ADRs covering push notifications, cache-first local persistence, and turning off default timer polling.
  • A new C++ SDK. The C++ SDK cut its first release in June and is already at v0.1.3, with hooks, evaluation options, and the global API.
  • flagd shipped 0.16.0 and 0.16.1, adding custom sync headers (flagd#1960, flagd#1969), incremental gRPC updates (flagd#1922), and content-hash deduplication (flagd#1991), alongside a sustained run of reliability fixes.
  • The OpenFeature Operator reached v0.9.2. Note that v0.9.0 moved to native sidecar containers and now requires Kubernetes 1.29 or later.
  • Isolated API instances landed across five SDKs. .NET, PHP, and Java have shipped them in releases, with Go and Kotlin merged and awaiting a release. Library authors, micro-frontends, and parallel test suites no longer have to share one process-global singleton.
  • "DISABLED is a successful evaluation" rolled out to five flagd cores. JavaScript, Java, Go, Python, and .NET all shipped the change, each with a major version bump on the core library. A disabled flag now resolves successfully and returns your default rather than surfacing an error.
  • Long support arrived in the JVM SDKs. Java and Kotlin both added a 64-bit integer type, closing a gap where large flag values overflowed.
  • New providers. Azure App Configuration (JavaScript), localStorage (JavaScript), Optimizely (Go, with Java reaching 1.0.0), and GCP Secret Manager and Parameter Manager (Java).
  • Three breaking changes worth checking before you upgrade. Python's set_provider() is now non-blocking with a new set_provider_and_wait() (python-sdk#595), fractional bucketing was overhauled (js-sdk-contrib#1501) in a way that changes which users land in which variant, and the OFREP web provider turned default polling off.

Where We Could Use Help​

The work that moves the ecosystem furthest is rarely a single fix in a single SDK. These are the larger efforts where an extra pair of hands changes the outcome, and each one has a per-language issue you can pick up.

Come find us on CNCF Slack, at our bi-weekly community meetings, or on GitHub. We will be at KubeCon NA 2026 in Salt Lake City this November.