What is a feature flag service?

The parts of a feature flag service

A feature flag is an if in your code. A feature flag service is everything outside the code that decides how that if answers. Whatever the vendor, it has the same four parts:

• A store of flags and rules. Each flag has a state per environment and the rules for who gets it: admins, named users, a percentage, everyone.
• Ways to change them. A console for people, an API, and often a CLI. In Flagger.gg, agents also get an MCP server with 11 flag tools.
• Delivery to your apps. SDKs in your services fetch the rules and keep them up to date, usually over a stream with polling as a fallback.
• A record of changes. An audit log of who changed which flag, when, from what to what, and why.

"Feature flag service", "feature flag platform", "feature flags as a service" and "feature flag management" all describe this. The difference from a config file is that a change takes effect in running apps in seconds, without a build or a deploy.

How a flag change reaches your app

Here is the path in Flagger.gg, which is typical of services that evaluate flags in your app:

1. Someone, or an agent, changes a flag: flagger set new_checkout percent --percent 10 --note "start rollout", the flag_set MCP tool, or the console. The change is stored with an event recording the actor, the note, and the state before and after.
2. The service pushes the new ruleset to every connected SDK over a server-sent event stream, within a second of the change.
3. The SDK swaps in the new rules in memory and writes them to a cache file on disk.
4. Your code calls flagger.flag("new_checkout", { userId }) in Node or Enabled(ctx, "new_checkout") in Go. That's a function call against the rules in memory, not a network request.

If the stream drops, the SDKs poll every 5 seconds and reconnect with backoff. If the service is unreachable when an app restarts, the SDK serves the last rules from its cache file. A flag that is unknown, not loaded yet, or errors is off. More on why this design matters: local evaluation.

What the service sees about your users

It depends on where flags are evaluated. Some services evaluate on their own servers, so your app sends them each user's attributes on every check. With local evaluation the rules come to your app instead, and your users never go to the service.

Flagger.gg's Go and Node SDKs evaluate in your app. User ids, emails and workspaces stay in your process; Flagger.gg stores only the targeting lists people type in, such as the user ids on a flag's target list.

Build your own, or use a service?

Many teams start with a flags table and an admin page, and for one app with a few flags that's fine. It stops being enough when you need:

• Changes in seconds across every running instance, not on the next deploy or cache expiry.
• Sticky percentage rollouts, so a user keeps the same answer as you go from 10% to 25%. See percentage rollouts.
• A kill switch that works when the rest of the admin is broken. See kill switches.
• An audit log that answers "who turned this on?" during an incident.
• Several apps or teams sharing one set of rules and one history.
• AI agents changing flags, which needs scoped permissions and a record of which agent run made each change. See scoped agent tokens.

For the full decision, with what to weigh on cost, languages, hosting and agent access, see North Bay Ventures' guide to building or buying feature flags.

Flagger.gg is built from the flag system that runs Sandboxer and Transformer in production, which began as exactly that kind of in-house table. If you already have one, moving off an in-house flag table covers importing your flags with their history, running both systems side by side in shadow mode, and cutting over.

What to check before you pick one

• SDKs for the languages you run. Flagger.gg has Go and Node SDKs; a browser/React SDK, Python and mobile are In development.
• Where evaluation happens, and what happens when the service is down.
• Hosting: hosted, self-hosted or both. Flagger.gg is hosted only and isn't open source; Unleash, Flagsmith and GrowthBook can be self-hosted (compared).
• Experiments and metrics, if you want flags tied to results. On Flagger.gg, metric-tied rollouts and experiments are In development; see GrowthBook, Statsig and ConfigCat and LaunchDarkly.
• Access for agents: an MCP server, a CLI with JSON output, and tokens you can limit. That is what Flagger.gg is built around.

For a startup's short list, see self-serve feature flags for startups.

FAQ

What is a feature flag service?

A hosted system that stores your feature flags and their rules, lets people and tools change them, and keeps SDKs in your apps up to date, so you can turn features on or off for chosen users without a deploy.

Is a feature flag service the same as feature flag management?

Mostly. Feature flag management is the practice: states per environment, targeting, permissions, an audit log and cleanup. A feature flag service is the product that does it for you.

Do I need a feature flag service, or is a database table enough?

A table is enough for one app and a few flags. Use a service once you need changes in seconds everywhere, sticky percentage rollouts, a reliable kill switch, an audit log, or agents changing flags safely.

What happens to my app if the feature flag service goes down?

With local evaluation, flag checks keep working from the rules already in memory. Flagger.gg's SDKs also keep the last rules on disk, so a restart during an outage serves them, and anything unknown is off.

Does a feature flag service get my users' data?

Not if it evaluates flags in your app. Flagger.gg's SDKs evaluate locally, so user ids and emails stay in your app; the service stores only the targeting lists you enter.

Is Flagger.gg a feature flag service?

Yes. Flagger.gg is a hosted feature-flag service for teams whose code is written by AI agents, with Go and Node SDKs, a CLI, an MCP server and a console.