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

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

Go, Java, .NET, Python, Node.js, PHP, Ruby, and more - with in-process evaluation on the most used languages for local, low-latency flag resolution.
Server SDKsJavaScript, TypeScript, React, Angular, Swift, and Android (Kotlin) for evaluating flags in the browser and on mobile.
Client SDKsThe OpenFeature Remote Evaluation Protocol is a standard REST contract any language can call - so even stacks without a native provider can still talk to GO Feature Flag.
About OFREPOur 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.
Self-hosted, OpenFeature-native, MIT-licensed. Use the standard SDKs, drop in a GO Feature Flag provider, and stay vendor-neutral from day one.