Feature flags vs a staging environment
Staging tests a copy of production; flags test the real thing with a few real users first. Many teams keep a development environment and skip staging, shipping to production behind a flag and widening it as checks pass. Flagger.gg has production and development environments, and no staging, by design.
Updated
What each one tests
| Staging environment | Feature flag in production | |
|---|---|---|
| Data | A copy, often stale or synthetic | Real data |
| Traffic | Your team and test scripts | Real users, a few at a time |
| Infrastructure | Similar to production, rarely identical | Production itself |
| Rolling back | Redeploy | Turn the flag off, in seconds |
| Cost | A second copy of everything to run and keep in sync | A check in the code |
Staging catches problems that only appear once code is deployed. It misses the ones that only appear with real data, real load and real users, and those are the ones flags are good at containing.
Shipping without staging
A common pattern, and the one Flagger.gg is built around:
- Develop and test locally and in a development environment, where agents may do anything.
- Merge and deploy to production with the new code behind a flag that's off.
- Turn it on for
admins, thentargets(named users or workspaces), then apercent. - Turn it on for everyone, or kill it if anything breaks.
Each Flagger.gg project has two environments, production and development, each with its own SDK key, flag states and rules. Flags are project-wide, so a flag created in one exists in both.
When staging is still worth it
- Database migrations and infrastructure changes that can't be hidden behind a flag.
- Integrations with partners who need a sandbox to test against.
- Regulated releases that require sign-off on a separate environment.
Flags don't replace tests or code review either; they limit how many people a mistake reaches and how long it lasts.
FAQ
Do I need staging if I use feature flags?
Often not. Many teams keep local and development environments, ship to production behind a flag, and widen it as checks pass. Keep staging for changes flags can't hide, like schema migrations.
Can feature flags replace a staging environment?
For most application changes, yes: a flag lets you test in production with admins or a few users first. They don't replace tests, review or staging for infrastructure changes.
Does Flagger.gg have a staging environment?
No, by design. Each project has production and development.
Is testing in production safe?
It's safe when exposure is limited and reversible: admins first, then a small sticky percentage, with a kill switch that takes effect within a second.
Ship your next change behind a flag.
Sign up, add an SDK key to your app and give your agent a token.