Why does my flag work in dev but not production?
Last updated:
Because every environment holds its own configuration, and enabling a flag in development changes nothing in production. Targeting rules and rollout percentages are per environment as well, so a flag can be on in both and still serve different values. A new environment starts every existing flag in the off state deliberately, so nothing goes live by accident.
This is the system working. Per-environment configuration is what lets you merge code behind a flag, exercise it locally, and leave production untouched until you decide otherwise.
It only feels like a bug because the flag looks like one object in the dashboard. Its state is not one value.
What is actually per environment
Four things, all of them independent:
- Whether the flag is on
- Its targeting rules
- Its rollout percentage
- The variation served on fallthrough
A flag enabled in both development and production can still behave differently in each, because rules and percentages did not travel with the toggle. Two environments both showing “on” is not evidence they agree.
The check
Open the flag and switch environments in the dashboard. Compare all four, rather than the toggle alone. Most surprises are a rollout left at 100% in development and 5% in production, which is the correct end state of a careful rollout and looks like a broken flag from a test account.
New environments start off
When you add an environment, every existing flag is created there in the off state. That is deliberate. The alternative is a new QA environment inheriting production’s configuration and quietly enabling things nobody meant to run.
The consequence is that a new environment needs its flags configured as well as its SDK key.
When it is the key rather than the config
If the flag is configured correctly in production and still does nothing, check which environment your production process actually authenticated as. The SDK key selects the environment, so a stale key in a deploy config means production is reading somebody else’s flags. That failure has its own answer.
Promoting a flag
Treat it like promoting code. Enable and exercise in development, then staging, then production, widening the rollout at each step. Nothing copies configuration between environments for you, which is inconvenient exactly once per flag and prevents a class of accident permanently.
Environment isolation is documented in Environments, and the per-environment workflow in the environments guide.
Related questions
Can I use one SDK key for every environment?
No. The SDK key is what selects the environment, so sharing one collapses dev and production onto the same flag configuration.
Why is my feature flag returning the default value?
Six reasons a Featureflip flag falls back to the default you passed, ordered by how often each one is the real cause, with the check for each.
Why did my targeting rule not match?
Rules run top to bottom and the first match wins, so an earlier rule can shadow the one you are testing. The other usual cause is a missing context attribute.
Still stuck?
The docs cover every SDK, and the free Solo plan is enough to reproduce most of these locally.