The most common objection to adopting a feature flag service is a fair one: “can’t I just use an environment variable?” Often, yes. Environment variables are a legitimate way to gate behavior, and reaching for a hosted service too early is its own kind of over-engineering. This post is about where the line actually is.
What environment variables do well
For a single on/off switch that changes rarely, an env var is hard to beat. It has no dependencies, no SDK, no vendor, and no failure mode beyond “the value was wrong.” A FEATURE_NEW_BILLING=true in your deploy config is completely reasonable for:
- Toggling a feature that is either fully on or fully off, org-wide.
- Config that only ever changes as part of a deploy anyway.
- Kill switches for a single service where a redeploy or restart is fast.
- Local development overrides.
If that describes your need, stop here. You do not need a service.
Where environment variables stop working
Env vars break down along five predictable axes.
1. You need to change the value without a deploy
Changing an env var means shipping a new config and restarting the process. During an incident, that is minutes you do not have. A flag you can flip from a dashboard — or an API call — turns a rollback into a click. This is the single most common reason teams move.
2. You need to target a subset of users
“On” and “off” are not enough once you want to enable something for your own team, for beta users, for one customer who reported a bug, or for everyone on the Pro plan. Encoding that in env vars means shipping user lists in config and writing the matching logic yourself, in every service.
3. You need a percentage rollout
Releasing to 5%, then 25%, then 100% — with the same users staying in their bucket as you ramp — requires consistent hashing on a stable identifier. It is not hard to write once, but it is easy to get subtly wrong, and you will reimplement it per language.
4. You need to know who changed what
“Who turned this on in production, and when?” has no good answer if the toggle lives in a deploy pipeline’s environment config. An audit trail of flag changes is often a compliance requirement, and always useful during a post-mortem.
5. Non-engineers need to flip it
If a product manager or support lead should be able to enable a feature for a customer, an env var is a non-starter. They need a UI, and that UI needs permissions.
A simple decision rule
Use environment variables when all of these are true:
- The toggle is global — every user sees the same thing.
- It changes only at deploy time.
- Only engineers ever need to change it.
- You do not need a record of who changed it.
The moment one of those stops being true, you are either adopting a flag service or slowly building a worse one inside your config management.
What a flag service adds
A feature flag platform is, roughly, four things env vars are not:
- Runtime control. Change a flag and every SDK picks it up within seconds, no deploy.
- A targeting engine. Rules over user attributes, segments, and percentage rollouts with consistent bucketing — implemented once, identical across every language.
- An audit log. Every change attributed to a person with a timestamp.
- A UI with permissions. So the right people can act without touching code.
The cost is a dependency and, depending on the vendor, a bill that scales badly. That is why ToggleTown is flat-priced and why the SDKs evaluate locally — so adding the service does not add latency or a new single point of failure. If you have outgrown env vars but not the reasons you liked them, that is the gap it is meant to fill.