OpenFeature is a CNCF-backed, vendor-neutral standard for feature flag evaluation: your application code calls the standard OpenFeature client API, and a provider underneath translates those calls to whatever flag platform you're actually running. Switching providers (or running two platforms side by side during a migration) doesn't touch a single call site in your application.
openfeature-provider is that translation layer for rollfuse: it implements the OpenFeature Go provider interface, backed by go-sdk underneath, so you get local, cached, zero-network-call-on-the-hot-path evaluation with the same bucketing and rule-matching semantics go-sdk already has, just reached through the standard API instead of rollfuse's own client type.
Install and register the provider
go get github.com/rollfuse/openfeature-provider
import (
"github.com/open-feature/go-sdk/openfeature"
rollfuseprovider "github.com/rollfuse/openfeature-provider"
)
provider, err := rollfuseprovider.NewProvider(baseURL, credential)
if err != nil {
log.Fatal(err)
}
openfeature.SetProvider(provider)
client := openfeature.NewClient("checkout-service")
NewProvider wraps the same go-sdk client construction under the hood: it accepts your Environment's base URL and Service Credential, and starts the same background Configuration fetch-and-cache cycle. Everything about local evaluation, safe fallback, and asynchronous exposure reporting that applies to go-sdk directly applies here too; only the call surface changes.
Evaluate through the standard API
enabled, err := client.BooleanValue(
context.Background(),
"checkout-redesign",
false,
openfeature.NewEvaluationContext(subjectKey, map[string]any{"plan": "growth"}),
)
if enabled {
// serve the new checkout
}
This is the exact same evaluation your service would get calling go-sdk's Evaluate directly (same cache, same bucketing, same fallback behavior on a config-not-ready state), expressed through OpenFeature's BooleanValue/StringValue/FloatValue/IntValue/ObjectValue methods instead of rollfuse's own result type.
Why this matters for a migration
If you're migrating off another flag platform, wiring your application to OpenFeature's client API first (with that other platform's own OpenFeature provider, if it has one) and only later swapping in openfeature-provider means the migration touches configuration, not application code. See our LaunchDarkly Migration Checker for scoping what a migration off LaunchDarkly specifically involves, OpenFeature or not.
See the openfeature-provider repository for the full provider API and supported OpenFeature spec version.