Open source feature flags: what to look for
“Open source feature flags” covers tools as different as a self-hosted platform with its own database and a flag that is just a file in your repo. The license tells you the code is free to read. It tells you nothing about where the flag state lives, how a user gets a variant, or what catches a broken flag before it ships. Evaluate any open source feature flag tool on five things: licensing versus hosting, where state lives, how bucketing works, whether CI catches a mistake, and the real cost of running it yourself.
Most teams find this out after they have already picked one. A team self-hosts an open source flag server because the license is free, stands up a database and a UI to go with it, and six months later the flag state lives in that service, disconnected from the code. That is the same drift problem a closed-source dashboard has. The license was never the thing causing the pain.
This is a checklist for picking an open source feature flag tool, with how GrowthBook, Flagsmith, Unleash, PostHog, and dif actually answer each question.
Key Takeaways
- “Open source” describes the license, not the architecture. GrowthBook, Flagsmith, and Unleash are open source and still run as a separate server with its own database; dif is open source (MIT) and runs from files in your repo, with no server.
- Self-hosted feature flags still cost you something: a database, an upgrade cadence, and someone who owns the uptime of a service that was supposed to simplify things.
- Check whether assignment is a pure function of the user id (deterministic bucketing) or needs a live lookup. dif hashes the user id and salt and never stores an assignment.
- CI validation matters more than a license:
dif validatecatches a broken flag, a bad weight, or a stale reference before merge, the same way a broken build fails.- Open source LaunchDarkly alternatives covers the proprietary-versus-open question in full; this post is about picking among the open source options themselves.
What “open source” actually tells you
A license is a legal fact about the code. The Open Source Definition covers redistribution and modification rights, and it says nothing about whether the tool needs a database, a background service, or a dashboard you have to keep patched.
Four tools, four different shapes, all genuinely open source:
- GrowthBook is open source and runs as a separate app with its own database. Strong stats engine, warehouse-native analysis, a real app to operate.
- Flagsmith and Unleash are open source feature-flag servers. Both are self-hostable, and both are a backend plus a UI your app calls over the network.
- PostHog bundles flags and experiments into a larger product-analytics platform. Also self-hostable, also a service with its own footprint.
- dif is open source (MIT) and needs no server for the core workflow. The CLI and SDK run entirely from Markdown files in your repo.
None of these are more or less “open source” than the others. The license is the same kind of free. What differs is what you have to run.
Where the flag state lives (self-hosted feature flags)
Self-hosting a feature flag tool usually means one of two things, and they are not the same job.
The first is hosting a service: a database, a web app, and the operational work of keeping both patched and up. GrowthBook, Flagsmith, and Unleash all fit here. You own the uptime, the backups, and the version upgrades of a system that exists to answer “is this flag on.” The Unleash repository documents the Postgres instance it needs; GrowthBook’s self-hosting guide walks through the same shape, a database plus an app server.
The second is hosting nothing, because the flag is a file. In dif, a flag looks like this:
---
id: new-checkout
status: active
owner: sam@acme.com
surface: checkout
hypothesis: >
Inlining the address form lifts completed checkouts.
variants:
- id: "off"
weight: 90
- id: "on"
weight: 10
metrics:
primary: completed_checkout
created: 2026-10-04
---
## Brief
Ramp to 25% once the guardrails hold for a week.
That file lives next to the code it gates, gets reviewed in a pull request, and its history is git log. For a PM, a stale flag is now a code-review problem, something a reviewer can flag in a diff, not a row in an admin panel nobody opens. For an engineer, there is no service to patch: dif init scaffolds a dif/ directory for the .md format in your repo, and there is no server behind it.
How a user gets a variant: check the bucketing, not just “targeting”
Every feature flag tool will tell you it supports targeting. The question that actually matters is whether assignment is a pure function of the user id, or whether it needs a live lookup against a service.
dif’s answer: a user’s variant is the first four bytes of SHA-256(salt || user_id), taken modulo 10,000 and mapped against the variant weights. Nothing is stored. The same input produces the same output every time, computed locally with no network call, so a user never flickers between variants across page loads or devices. Each flag gets its own salt, so being in the 10% for one flag does not correlate with being in the 10% for another.
This matters whether you pick dif or not. Ask any open source feature flag tool: is the variant computed from the user id, or does it depend on a round trip to fetch current state? A tool that fetches a config once and buckets locally is fine. A tool where the assignment itself lives behind a service call is a flakier dependency on your render path.
Does CI catch a broken flag, or does production?
A license does not validate anything. What catches a typo in a flag name, a set of weights that do not sum to 100, or two experiments silently colliding on the same surface is a validation step, and whether that step runs in CI depends on where the flag state lives.
When flags live in a dashboard, validating them means validating inside that dashboard’s own UI, separate from your normal build. When flags are files, the same CI that runs your tests can run the check. dif validate is one pass that confirms weights total 100, the owner is a real email, and every referenced surface and attribute exists, and warns when the app source has an orphan dif("...") call site pointing at a flag that no longer exists:
$ dif validate
error E005 dif/experiments/active/new-checkout.md:1:1: variant weights sum to 90, expected 100
help: Distribute the variants so the weights total 100.
warning W001 src/pricing.tsx:42:1: orphan ref: `old-pricing-test` is not an active experiment
help: Either create the experiment or remove the dif() call.
✗ 1 error(s), 1 warning(s)
A broken flag fails the pull request the same way a broken test does. Files checked in CI make that possible; the license has nothing to do with it.
The real cost of self-hosting an open source feature flag tool
“Free” and “open source” describe the code. They do not describe the infrastructure bill, which is where the real comparison happens.
| Dimension | dif | GrowthBook | Flagsmith | Unleash |
|---|---|---|---|---|
| License | Open source (MIT) | Open source | Open source | Open source |
| What you run to self-host | Nothing; CLI and SDK run from your repo | App server plus its own database | Backend plus a UI | Server plus Postgres |
| Where flags live | Markdown files in your repo, reviewed in PRs | The app's own database | The server's database | The server's database |
| CI validation of flags | Built in (dif validate) | Via the app's own checks | Via the app's own checks | Via the app's own checks |
| Hosted option | dif Cloud, $50/mo for 1M events, unlimited seats | Cloud plan available | Cloud plan available | Cloud plan available |
| Agent-readable state | Yes (context.json) | No | No | No |
The pattern holds across the three server-based tools: self-hosting means operating a service, and the hosted plan exists specifically so you do not have to. dif’s CLI and SDK skip that choice for the core flagging workflow, because there is no server to self-host or pay someone else to run.
Picking one
Picking among open source feature flags comes down to what you are willing to run. Choose a self-hosted server like GrowthBook, Flagsmith, or Unleash if you want a dashboard your team can use without touching git, or if GrowthBook’s warehouse-native stats engine is the priority. You are accepting a database and an upgrade cadence as the cost of that UI.
Choose PostHog if you already want product analytics, session replay, and flags together, and the heavier footprint is not a concern.
Choose dif if your team already lives in pull requests and you want flags and experiments reviewed the same way as code, with no service to run for the core workflow and no dashboard that can drift from what is actually deployed.
npm install -g @dif.sh/cli
dif init
No account, no API key. See the feature flags page for the full workflow, or the CLI reference for every verb.
FAQ
Is there a good open source alternative to LaunchDarkly? Yes, several: GrowthBook, Flagsmith, Unleash, PostHog, and dif are all open source feature flag tools. Open source LaunchDarkly alternatives covers that comparison in detail; this post is about choosing among the open source options.
What’s the difference between open source and self-hosted feature flags? Open source describes the license: the code is free to read, fork, and modify. Self-hosted describes what you run. Most open source feature flag tools are also self-hosted servers with their own database, but it is possible to be open source with nothing to self-host, which is dif’s model.
Do open source feature flags cost anything to run? The license is free, but running a server-based tool costs you a database, hosting, and upgrade time, even if you never pay the vendor. Factor that in alongside any hosted plan’s price.
Can I use open source feature flags without running a server? Yes, with a file-based tool like dif, where the CLI and SDK work entirely from files in your repo. GrowthBook, Flagsmith, and Unleash are built around a server and do not offer that option for their core flagging.
How do open source feature flags handle targeting and bucketing? Most hash a user attribute into a bucket and map it to a variant by weight. The detail worth checking is whether that computation is a pure function of the user id, done locally with no stored assignment, or depends on a lookup against a running service.
Is dif free to use? Yes. The CLI and SDK are MIT licensed and free, with no account or API key required. dif Cloud is an optional hosted layer at $50/mo for 1M events, unlimited seats, for teams that want managed analytics on top.