flagd: a feature flag daemon that reads its configuration from a URI

What flagd is: a daemon, not a hosted service

flagd is described as a feature flag daemon with a Unix philosophy, and the README restates it as a ready-made, open source, OpenFeature compliant feature flag backend system. The Unix framing is the design brief. A daemon is a long-running process, its inputs are files and endpoints, its output is a protocol, and it does one thing. The feature list is short and every entry maps to that shape. It is OpenFeature compliant and speaks your language, through the providers listed in the OpenFeature ecosystem. It is easy to extend to new languages, because the providers are separate. It supports multiple data sources simultaneously. Feature flag updates occur in near real-time. It contains a powerful and flexible rule targeting engine and deterministic percentage-based rollouts. And flag evaluation traces and metrics are exposed and compatible with OpenTelemetry. The primary language is Go, the licence is Apache 2.0, and the homepage is flagd.dev.

Starting it: a port and a --uri, and the URI is the whole configuration

The quick start is a single command. You run flagd start with a port and a --uri pointing at a remote sample file, and flagd is running. The --uri can be a local file or any remote endpoint, and you use the file: prefix for local files, with gRPC and http having their own requirements, which the README links to the documentation for. Multiple --uri parameters can be specified, and in other words flagd can retrieve flags from multiple sources simultaneously, which is the mechanism behind the multiple data sources feature. That design is what makes the daemon composable: the source of truth is a document, and where that document comes from is a runtime decision rather than a compile time one. The quick start also notes that flagd can be run as a standalone binary or a container, and for Kubernetes it can be run as part of the Kubernetes Operator.

flagd start \
  --port 8013 \
  --uri https://raw.githubusercontent.com/open-feature/flagd/main/samples/example_flags.flagd.json

The container path, and the Windows caveat that is a Docker limitation

The container invocation runs the image with --rm -it, a name, a published port mapping from 8013, and the same start command with the remote --uri, so the container is stateless in exactly the way the binary is. If you want the flags locally instead, you can download the file with wget and then point the container at it with a volume mount, using the file: URI form. The Windows note is repeated in both the container and the local mode instructions, and it is not really about flagd: in Windows you should use a WSL system for both the file location and the Docker runtime, because mixed file systems do not work, and the README links that as a known Docker limitation. That is a useful piece of honesty, since the same class of problem catches people with flags mounted from a Windows host into a Linux container.

docker run \
  --rm -it \
  --name flagd \
  -p 8013:8013 \
  -v $(pwd):/etc/flagd \
  ghcr.io/open-feature/flagd:latest start \
  --uri file:./etc/flagd/example_flags.flagd.json

Evaluating a flag: one HTTP POST to a gRPC style path

Once it is running, flagd performs flag evaluations over either HTTP or gRPC, and the HTTP example uses cURL with a POST to a path that looks like a gRPC method, ResolveString under the flagd.evaluation.v1.Service service, with a JSON body carrying the flagKey and a context object. The result is a JSON object with three fields, the value, the reason, and the variant. The reason is where the interesting information lives for a rollout, because it tells you why the flag resolved the way it did, and here it is DEFAULT. The README also shows the Windows equivalent with cmd and a set json variable, and recommends a WSL terminal instead. And it confirms the operational property that makes the daemon useful, that updates to the underlying flag store, for example a JSON file, are reflected by flagd in realtime and no restart is required. Boolean, integer, float and object flag types are also supported.

curl -X POST "http://localhost:8013/flagd.evaluation.v1.Service/ResolveString" \
  -d '{"flagKey":"myStringFlag","context":{}}' -H "Content-Type: application/json"

{
  "value": "val1",
  "reason": "DEFAULT",
  "variant":"key1"
}

How you plug it into an application, and what OpenFeature buys you

The integration step is deliberately thin, and it is the point of the OpenFeature dependency. You use an OpenFeature provider in a language of your choice, chosen from the ecosystem page filtered for FlagD, and the provider speaks to the daemon. The provider is the piece that knows the protocol and the language, and the daemon is the piece that knows the flags. The consequence is that the language side is swappable, which is what the easy to extend to new languages claim means in practice, and it is why the README frames flagd as speaking your language. The daemon itself is agnostic, and the cost of that abstraction is that a provider is a dependency you take, and the value of it is that the same flag service works from a Java service, a Go service and a browser bundle without any of them knowing about the others.

The repository holds two things, a daemon and a proxy

The top level of the repository is more than a single binary. There is a flagd/ directory for the daemon itself, a flagd-proxy/ directory for the proxy component, core/ for shared code, a config/ directory, samples/ with example flag files, schemas/ and spec/ directories, a docs/ directory built with MkDocs, a playground-app/ directory, a test-harness/ directory, a systemd/ directory for the service unit, and a Dockerfile plus a Makefile. The samples directory is worth noting, because it holds the same example flags in several formats, example_flags.flagd.json, example_flags.flagd.yaml, example_flags.json and example_flags.yaml, along with secondary variants, so you can see which shape your flag definitions should take. The proxy existing alongside the daemon means the deployment topology is a separate decision from the daemon itself.

Build matrix, FIPS variant and the release discipline

The Makefile is where the engineering decisions are visible. There are separate targets for building and pushing the daemon and the proxy, and the daemon build is a buildx build stamped with a version from git describe, a short commit hash and a date, across platforms including linux/arm64, and the push target covers linux/ppc64le, linux/s390x, linux/amd64 and linux/arm64, so this project builds for s390x and ppc64le rather than only for the two architectures that dominate. The FIPS variant is the most interesting part. It builds against the CMVP-certified Go Cryptographic Module v1.0.0 with certificate number 5247, and the literal version is required because the certified and inprocess aliases vary by toolchain, and the fips140 tag makes the binary require that module at startup rather than merely report on it. That distinction matters for a daemon that is deployed into regulated environments. The releases are tagged per component, flagd/v0.18.0 and flagd/v0.17.1 alongside flagd-proxy/v0.9.12, all on 2026-10-15,.

Editorial conclusion

flagd suits a team that wants an OpenFeature compliant flag backend without a hosted vendor, and that is comfortable with configuration-as-a-file and a process to operate. It is the wrong choice if you need flags served from a database with a management UI, because the model is a URI pointing at documents rather than a store with an editing surface, and a poor fit if you need multi-region replication of flag state, since the architecture here is a single daemon with multiple sources. Before adopting it, read the documentation for the sync types, because gRPC and http sources have their own requirements separate from the file source, and note that a proxy component exists alongside the daemon, so the deployment topology is a choice rather than a given.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. open-feature/flagd on GitHub
3. Project website
4. README
5. Releases