Why does my flag work in dev but not production?
Last updated:
Every environment holds its own configuration, so enabling a flag in development changes nothing in production. Targeting rules and rollout percentages are per environment as well, which means a flag can read as 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.
Per-environment configuration is what lets you merge code behind a flag, exercise it locally, and leave production untouched until you decide otherwise. The system is doing its job here.
It feels like a bug because the flag presents as a single object in the dashboard, when its state is really one value per environment.
What is actually per environment
These four are independent of each other:
- 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. Seeing “on” in two environments tells you very little about whether 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. That costs you a minute per flag and rules out a whole class of accident for good.
Environments explains why the isolation is drawn where it is. The environments guide walks the promotion workflow step by step.
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.