Skip to main content

OpenFeature support

GO Feature Flag is built on OpenFeature - the open standard for feature flagging. You write against a vendor-neutral API, not our proprietary client, so you are never locked in.

The open standard

What is OpenFeature?

OpenFeature is an open standard for feature flag management, hosted by the Cloud Native Computing Foundation (CNCF). It defines a single, vendor-neutral API and a set of SDKs so developers can use feature flags in a consistent way, whatever backend powers them.

The key idea is the provider: your application talks only to the OpenFeature SDK, and a provider plugs a specific backend into that standard API. Change the provider and your evaluation code stays exactly the same.

OpenFeature sits between your application and a feature flag backend: your app calls the standard OpenFeature SDK, and a provider connects that SDK to a specific service - here a generic 'Flags-R-us' vendor.

Why building on an open standard matters

No vendor lock-in

Your app evaluates flags through the standard OpenFeature API, not a proprietary client. Swap GO Feature Flag for another provider later and your evaluation code stays the same.

One API, every language

The same concepts and method signatures across Go, Java, Python, JavaScript, and more - so teams share one mental model instead of learning a different SDK per stack.

Backed by the CNCF community

OpenFeature is a CNCF incubating project, shaped in the open by many vendors and contributors. The standard outlives any single tool you build on top of it.

Our commitment

We ship providers, not a custom SDK

At GO Feature Flag we believe in open standards and vendor neutrality - so we made a deliberate choice: not to build any proprietary SDKs and to rely entirely on OpenFeature. Instead of a client library you would have to learn and get tied to, we maintain native OpenFeature providers in many languages.

GO Feature Flag has been committed to the standard since OpenFeature’s early days. We ship native providers, support OFREP (the OpenFeature Remote Evaluation Protocol), and follow the spec closely so we stay compatible across the whole ecosystem. The payoff for you: adopt feature flags fast, with no lock-in and no proprietary infrastructure to learn.

OpenFeature logo
How it fits together

OpenFeature SDK, GO Feature Flag provider, relay proxy

In your code you use the standard OpenFeature SDK together with a GO Feature Flag provider. The provider connects to the relay proxy you host in your own infrastructure, which reads your flag configuration from the store of your choice.

Evaluation runs in one of two modes: remote evaluation (the provider asks the relay proxy for each evaluation) or in-process evaluation (the provider syncs the configuration and evaluates locally, with no network call on the hot path). Either way, the same evaluation data is collected for observability.

Your application uses the OpenFeature SDK with a GO Feature Flag provider; the provider talks to the GO Feature Flag relay proxy hosted in your infrastructure, which reads your flag configuration from the store of your choice.

Getting started with OpenFeature and GO Feature Flag

Use it in your language

Helping steer the standard

A seat at the OpenFeature table

Our commitment goes beyond implementing the spec - we help shape it. GO Feature Flag’s creator, Thomas Poignant, served on the OpenFeature Technical Committee and was elected to the OpenFeature Governance Committee for the 2026-2028 term. That means the perspective of a maintainer who runs feature flagging in production feeds directly into where the standard goes - and that GO Feature Flag and OpenFeature stay in sync.

Read about joining the OpenFeature Governance Committee

Start with OpenFeature and GO Feature Flag

Self-hosted, OpenFeature-native, MIT-licensed. Use the standard SDKs, drop in a GO Feature Flag provider, and stay vendor-neutral from day one.

Frequently asked questions

What is OpenFeature?
OpenFeature is an open standard for feature flagging, hosted by the CNCF. It defines a vendor-neutral API and a set of SDKs so you can use feature flags without coupling your code to one specific platform. A "provider" plugs a particular backend - like GO Feature Flag - into that standard API.
Why does GO Feature Flag not have its own SDK?
On purpose. Rather than build proprietary SDKs, GO Feature Flag ships OpenFeature providers and relies entirely on the OpenFeature SDKs. That keeps you on the standard, avoids lock-in, and lets us focus on a simple, lightweight backend instead of maintaining a client library per language.
What is OFREP?
OFREP - the OpenFeature Remote Evaluation Protocol - is a standardized REST contract for evaluating flags remotely. GO Feature Flag implements it, so any language can evaluate flags over a standard HTTP API even when no native provider exists yet.
Do I need the relay proxy to use GO Feature Flag with OpenFeature?
Yes. The OpenFeature providers and OFREP talk to the GO Feature Flag relay proxy running in your infrastructure. The relay proxy reads your flag configuration and serves evaluations to the providers - either remotely or by syncing the configuration for in-process evaluation.
Can I switch feature flag providers later?
That is the whole point of building on a standard. Because your application calls the OpenFeature API, moving to another OpenFeature-compatible provider mostly means swapping the provider registration - your flag evaluation code does not change.
Is GO Feature Flag involved in OpenFeature itself?
Deeply. GO Feature Flag has followed the standard since OpenFeature's early days, ships native providers, and supports OFREP. Its creator, Thomas Poignant, served on the OpenFeature Technical Committee and was elected to the OpenFeature Governance Committee for the 2026-2028 term.