What is a feature flag?
A feature flag is a switch in your code that turns a feature on or off, for everyone or for chosen users, without a deploy. You ship the code dark, then turn it on for admins, a list of users, a percentage or everyone, and turn it off in seconds if something breaks.
Updated
How a feature flag works
A flag is a named condition around a code path. The code for both paths ships in the same deploy, and the flag decides at run time which one a given user gets:
if (flagger.flag("new_checkout", { userId, email, isAdmin })) {
return renderNewCheckout(cart);
}
return renderCheckout(cart);The flag's state lives outside the code, in a flag service. Changing it changes what users see within seconds, with no build, no deploy and no rollback of the code. That separates two things that used to be one step: deploying code and releasing a feature.
"Feature flag", "feature toggle", "feature switch" and "feature gate" all mean the same thing.
Who sees the feature
A flag is more than on or off. In Flagger.gg each flag has one of five states in each environment:
| State | Who sees the feature |
|---|---|
off | No one |
admins | Your admins only |
targets | Listed users (by id or verified email) and workspaces, plus admins |
percent | A sticky share of signed-in users, plus admins |
on | Everyone, including anonymous visitors |
A typical release walks the flag up that table: admins first, then a few named customers, then 10% and 50%, then everyone. See percentage rollouts for how the percentage stays sticky.
Where the check runs
A good flag check is fast and can't take your app down. Flagger.gg's Go and Node SDKs keep the whole ruleset in memory and evaluate each check locally and synchronously, with no network call. Rule changes stream to the SDK within a second, and the last good ruleset is cached on disk, so a restart during an outage serves the last rules. The users you check flags for are never sent to Flagger.gg.
Failures are safe by design: a flag that is unknown, not loaded yet or hit an error is off.
What teams use flags for
- Dark launches: merge unfinished work to main and deploy it switched off.
- Gradual rollouts: expose a change to a few users, watch it, widen it.
- Kill switches: turn off a broken feature at once, without a redeploy. See kill switches.
- Beta access: turn a feature on for named customers or workspaces.
- Agent-written code: when AI agents ship many changes a day, each one lands behind its own flag. See feature flags for AI agents.
FAQ
What's the difference between a feature flag and a feature toggle?
None. They're two names for the same thing: a switch in code whose state is set outside the code.
Do feature flags slow down my app?
Not if they're evaluated locally. Flagger.gg's SDKs check flags against an in-memory ruleset, so a check is a lookup and a few comparisons, with no network call.
What happens if the flag service is down?
With Flagger.gg, your app keeps serving the rules it already has in memory, and a restart loads the last good ruleset from disk. A flag the SDK doesn't know is off.
When should I remove a feature flag?
Once the feature is on for everyone and stable, delete the flag and the old code path. Old flags left in code are flag debt; see flag cleanup.
Can I sign up for Flagger.gg today?
Yes. Sign-up is open at app.flagger.gg with an email link or Google, and each account gets its own project with production and development environments.
Ship your next change behind a flag.
Sign up, add an SDK key to your app and give your agent a token.