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 environmentFeature flag in production
DataA copy, often stale or syntheticReal data
TrafficYour team and test scriptsReal users, a few at a time
InfrastructureSimilar to production, rarely identicalProduction itself
Rolling backRedeployTurn the flag off, in seconds
CostA second copy of everything to run and keep in syncA 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:

  1. Develop and test locally and in a development environment, where agents may do anything.
  2. Merge and deploy to production with the new code behind a flag that's off.
  3. Turn it on for admins, then targets (named users or workspaces), then a percent.
  4. 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.

Sign up