Main features
- Boolean, string, number and JSON flags
- Targeting rules on evaluation context attributes
- Deterministic fractional assignment for rollouts and experiments
- Semantic version and string comparison operators
- Flag sources from files, HTTP, gRPC, Kubernetes, S3, GCS and Azure Blob
- Merging of flag definitions from several sources
- Evaluation over gRPC, HTTP and OFREP
- In-process evaluation through OpenFeature providers
- OpenTelemetry traces and metrics
- Kubernetes operator for sidecar injection
What flagd does
flagd is the feature flag evaluation engine maintained by OpenFeature, the vendor-neutral feature flagging standard that is a CNCF incubating project. It is deliberately small: it reads flag definitions, watches them for changes and evaluates flags. It has no UI, no management console and no database of its own, and it is configured through command-line options.
Flags can be booleans, strings, numbers or JSON objects. Targeting rules compare attributes of the evaluation context, with extra operators for semantic versions and string matching, and a fractional operation assigns users to variants deterministically, which covers percentage rollouts and experiment assignment.
Where flags come from
You give flagd one or more sources, and it merges them. Supported sources are local files, HTTP endpoints, gRPC sync services, Kubernetes custom resources, and objects in Amazon S3, Google Cloud Storage or Azure Blob Storage. Changes to a source are reflected in evaluations without a restart.
In practice this means flags usually live in Git, are reviewed in pull requests, and are published to one of these sources by your CI pipeline or by the Kubernetes operator.
How evaluation works
flagd offers two modes, both used through the OpenFeature SDK and the flagd provider for your language:
- RPC evaluation: the application sends the evaluation context to a flagd instance, running as a sidecar or as a central service, over gRPC or HTTP, and gets the result back. flagd also implements OFREP, the OpenFeature Remote Evaluation Protocol.
- In-process evaluation: flagd streams the aggregated flag definitions over gRPC, and the provider evaluates flags inside the application. No user data leaves the process.
The documentation lists providers for Go, Java, Node.js, PHP, .NET, Python, Rust and the web.
Self-hosting flagd
flagd is distributed as a binary and a container image, and the OpenFeature Operator can inject it as a sidecar in Kubernetes. It needs no database or cache. Evaluation traces and metrics are exposed for OpenTelemetry, and a FIPS 140-3 mode is documented.
Hosted version
None. flagd is a community project under OpenFeature with no company selling a hosted edition.
Limitations
flagd is an engine, not a product for non-developers. There is no dashboard, user management, audit log or approval workflow; you build those around it with Git and CI. It does not analyze experiments; fractional assignment only splits traffic, and results must be measured elsewhere. Mobile apps need a provider that speaks OFREP or another OpenFeature provider.
Who it suits
flagd suits platform teams that run Kubernetes, want flags managed as code, and want application code tied only to the OpenFeature standard rather than to a vendor. It is also a natural local or test back end for teams that use OpenFeature with another provider in production. GO Feature Flag takes a similar file-based approach with more built-in exporters and notifications; Unleash or Flagsmith add a full management UI.
Technical details
Built with
- Go
GitHub topics
- go
- golang
- openfeature
Reviewed by the OpenSourcePicks editors from the project's repository and documentation. Something out of date? Tell us.