Both patterns exist to make rollback cheap and fast. They get there by keeping a different thing "warm" and ready to switch back to. That difference decides what each one is actually good at.
What blue-green keeps warm
Two complete environments run in parallel: "blue" (currently live) and "green" (the new version, fully deployed but not yet receiving traffic). Cutover is a router or DNS change that sends all traffic to green at once. Rollback is the same switch, reversed: instant, because blue never stopped running. The unit of rollback is the entire environment: everything about the new deploy, at once.
What feature flags keep warm
One environment runs the new code, but a flag decides, per request, which branch executes. Rollback is a Configuration change: the flag evaluates to a different variation, and already-running processes pick that up on their next local cache refresh (typically seconds, no redeploy or router change involved). The unit of rollback is whatever that flag gates: one feature, one code path, independent of everything else that shipped in the same deploy.
Where the difference actually matters
- Partial rollback. Blue-green is all-or-nothing: if a deploy bundles five changes and one is broken, rolling back reverts all five. A flag gates exactly the broken one; the other four keep running on the new build.
- Infrastructure cost. Blue-green needs double the running capacity during a cutover window: two full environments, even if only briefly. A flag needs none: one environment, one build, a boolean deciding which branch runs.
- Gradual exposure. Blue-green's cutover is binary: 0% or 100% on green, with nothing granular in between unless the router itself supports weighted traffic splitting (which starts to look like a canary, see Canary vs. Feature Flags). A flag can stage 5% → 25% → 50% → 100% natively, with a guardrail attached to abort automatically if a metric breaches mid-stage.
- What breaks and how you find out. Blue-green catches anything that breaks at the environment level (crash loops, failed health checks, infrastructure misconfiguration) because the whole environment either comes up healthy or it doesn't. A flag catches anything that breaks at the feature level, which needs an actual metric or guardrail watching that specific behavior, since the surrounding environment is unchanged and reports as healthy either way.
Combining them
Blue-green protects against a bad deploy: something structurally wrong with the new environment itself. Feature flags protect against a bad feature: something behaviorally wrong with a specific code path, structurally fine otherwise. A team running both typically blue-green's the infrastructure change and flag-gates whatever product behavior shipped inside it, so an infra-level failure gets the instant, complete rollback blue-green is built for, and a feature-level failure gets the granular, no-redeploy rollback a flag is built for, without paying the double-capacity cost of blue-greening every feature toggle individually.