Roll out a feature to 10% of users, and know exactly who gets it.
Flag Keeper is an open-source alternative to LaunchDarkly and Flagsmith for small teams. Percentage rollouts stay sticky (widening 10% to 30% never takes the feature from anyone), rules target by plan, country or app version, segments and prerequisites compose, and a kill switch is one request. Try your flags first: the page runs the same engine as the server, in your browser, and uploads nothing.
1. See what a rollout does to your users
| Variant | Users | Share |
|---|
2. Before you save a change: who flips?
Paste the config you are about to ship. The page lists how many of the same simulated users would get a different variant, and which way.
3. Run it yourself
git clone https://github.com/Duncan-Haywood/oss-monorepo && cd oss-monorepo/ventures/flag-keeper
ADMIN_KEY=$(openssl rand -hex 16) SERVER_KEY=$(openssl rand -hex 16) CLIENT_KEY=$(openssl rand -hex 16) \
FLAGS_FILE=examples/flags.json node server.mjs
curl -X POST localhost:8080/v1/evaluate -H "Authorization: Bearer $CLIENT_KEY" \
-d '{"flag":"new-checkout","context":{"key":"user-42","plan":"pro"}}'
# in your app (Node 18+ or a browser), served by your own server:
import { createClient } from "https://flags.example.com/sdk.mjs";
const flags = createClient({ url: "https://flags.example.com", key: CLIENT_KEY });
if (await flags.isOn("new-checkout", { key: user.id, plan: user.plan })) { /* new path */ }
Backends can pass mode: "local" and the SERVER_KEY to evaluate in-process from a cached config, so a flag-server outage changes nothing. One-click Render deploy, Fly.io and Docker are in the README.
Questions
Why not use LaunchDarkly, Flagsmith, Unleash, GrowthBook or PostHog flags?
Hosted flag services are polished and the right call if you want a team dashboard, SSO and an experimentation suite; they price by seats or monthly active users. Unleash and Flagsmith are open source but come with a database and several services to run. Flag Keeper is MIT and one Node process with a JSON file: percentage rollouts, targeting rules, segments, prerequisites, a kill switch and an audit log. It has no visual dashboard yet; you manage flags with the API or a JSON file in git.
Will a user keep their variant when I widen a rollout from 10% to 30%?
Yes. A user's bucket is a stable hash of the flag key and their id, and a rollout fills buckets in order, so widening only turns people on and never takes the feature away from anyone who had it. The Compare box above lists exactly who flips before you save, and the server has the same check at POST /v1/admin/impact.
What happens to my app if the flag server goes down?
With the backend SDK in local mode your app evaluates in-process from the last config it fetched, so an outage does not change anyone's variant. In remote mode, or when the server was never reachable, every check returns the fallback value you pass in, and the SDK never throws.
Is it safe to put a key in my web or mobile app?
Use the CLIENT_KEY there. It can only ask what a given user gets, it cannot read your rules, targets or segments, and it cannot edit anything. The SERVER_KEY reads the full config and belongs in your backend; the ADMIN_KEY edits flags and should only be in your own tooling. Do not send personal data you do not need as targeting attributes.
Can I use it for A/B tests?
It assigns users to variants consistently, including multivariate splits bucketed by account instead of user, and it counts how often each variant was served. It does not compute statistical significance or record conversions; send the variant to your analytics tool and analyse there.
Part of the self-hosted SaaS stack: 27 open-source tools you run yourself.