
flagd
OpenFeature-compliant feature flag daemon that evaluates flags from files, HTTP, gRPC, Kubernetes, or cloud storage over HTTP and gRPC.
Open source alternative to:
flagd is a feature flag daemon from the Cloud Native Computing Foundation's OpenFeature project, built around a Unix-philosophy single-purpose process. The maintainers describe it as a ready-made, open-source, OpenFeature-compliant feature flag backend: it loads flag definitions from one or more sources, evaluates them in near real time, and serves results over HTTP or gRPC. Because it implements the OpenFeature contract, applications can use the OpenFeature SDK for their language and swap flag sources or vendors without rewriting flag-checking code.
Flags are defined in JSON against a versioned schema with state, variants, defaultVariant, targeting rules, and metadata. Targeting conditions are evaluated against the request context and support deterministic fractional rollouts, semantic version comparison, and string comparison, so percentage releases and audience targeting work without a separate experimentation service. flagd can merge definitions from several sources at once: local files watched for changes, HTTP endpoints polled with ETag support, gRPC sync streams, Kubernetes FeatureFlag custom resources, and GCS, Azure Blob, or S3 buckets. Changes to a watched file or endpoint are picked up without restarting the daemon.
flagd is distributed as a static binary for x86 and ARM, an OCI image at ghcr.io/open-feature/flagd, a systemd unit, and Kubernetes manifests for sidecar or central-service deployments. The companion OpenFeature Operator handles deeper Kubernetes integration, injecting flagd and flag configuration into workloads. Telemetry is built in through OpenTelemetry metrics and traces, with Prometheus scraping available on the management port. There is no admin UI, database, or hosted tier: flags live as JSON in git, CI pipelines, or object storage. Compared with LaunchDarkly, Split, ConfigCat, Optimizely, Statsig, and Firebase Remote Config, flagd removes the vendor from the evaluation path entirely and asks teams to bring their own authoring and approval workflow.
Categories:
Build with:
Frequently Asked Questions
Does flagd have a web UI for managing feature flags?
No. flagd is an evaluation daemon, not a flag management console. Flags are authored as JSON files that conform to the flagd schema, then delivered through one of the supported sync sources such as a git repository, an HTTP endpoint, or a cloud storage bucket. Teams usually handle review and approval in their normal code review or CI process.
What flag sources can flagd read from?
flagd supports filepath sync for local JSON files, HTTP sync for remote endpoints polled with ETag support, gRPC sync streams, Kubernetes FeatureFlag custom resources through the OpenFeature Operator, and GCS, Azure Blob, or S3 object storage. Multiple URI sources can be supplied at once and their definitions are merged. File and endpoint changes are reflected in near real time without restarting the process.
How does flagd handle gradual rollouts and targeting?
Flag definitions include variants, a default variant, and optional targeting rules evaluated against the request context. The targeting engine supports conditions plus custom operations for deterministic fractional rollouts, semantic version comparison, and string comparison. Fractional evaluation uses a hashing strategy so the same user stays in the same bucket across requests, which makes percentage rollouts stable.
Which platforms does flagd run on?
flagd ships as a standalone binary for x86 and ARM on Linux, macOS, and Windows, and as an OCI image at ghcr.io/open-feature/flagd. It can run as a systemd service, a Kubernetes sidecar, or a central service behind multiple pods. There is no native desktop or mobile app.
Does flagd expose metrics and tracing?
Yes. flagd emits OpenTelemetry metrics and traces, including flag evaluation counts, result reasons, and HTTP/gRPC request metrics. With default settings a Prometheus-compatible endpoint is available at the management port, which defaults to 8014, and the same port exposes /healthz and /readyz probes. Evaluation traffic itself uses the main port, which defaults to 8013.
OpenAltFinder Score
Project Details
Repository details
Updated 11/6/2026, 3:01:19 PM
View RepositoryGet the latest open source alternatives delivered weekly.
Discover tools that give you freedom from proprietary software.








flagd vs Unleash