These two get conflated because both limit blast radius and both can be staged, monitored, and rolled back automatically. The difference is what's actually varying behind the scenes: a canary deployment routes a percentage of traffic to a different build of your service; a feature flag routes a percentage of traffic to a different code path inside a single build already running everywhere.
What a canary deployment controls
A canary is an infrastructure-layer decision: two versions of a service run side by side, and a load balancer or service mesh shifts traffic weight from the old version to the new one over time. Rolling back means shifting traffic weight back and, eventually, tearing down the new version's instances. The unit of control is "which binary handles this request," and that's a deploy-orchestration concern. See our Progressive Rollout on Kubernetes piece for what this looks like when the orchestration layer is Kubernetes itself.
What a feature flag controls
A flag is an application-layer decision: one build is deployed everywhere, and an if branch inside it (evaluated locally, in-process, against a cached Configuration) decides which path a given request takes. Rolling back means changing what the flag evaluates to, which is a Configuration change, not a redeploy. The unit of control is "which code path handles this request within the build that's already running."
Where they actually differ in practice
- Rollback speed. A flag rollback is a Configuration change propagated to already-running processes on their next cache refresh, typically within seconds. A canary rollback involves shifting traffic weight and, if instances were scaled up for the new version, tearing them down. That is usually slower, and it's an infrastructure operation, not an application one.
- Granularity. A canary's blast radius is a percentage of requests, regardless of which user sent them. A flag's blast radius can be a percentage of requests, a percentage of a specific segment (a plan tier, a region, an internal team), or a hand-picked list of subject keys. A canary can't express that targeting without splitting traffic at the infrastructure layer per segment, which most setups don't do.
- What has to be redeployed to test something new. A canary requires a new build to test anything; there's no "flip a switch to see the new behavior" without deploying different code. A flag can gate code that's already deployed but dormant, so testing a variant doesn't require a deploy at all.
- Failure mode under a bad change. A canary regression is contained to a build; rolling back removes that build's code entirely. A flag regression is contained to whichever request evaluated
true; rolling back removes the behavior while the code itself stays deployed, dormant, ready to try again once fixed.
They're not competitors
Most teams that run both use a canary to validate that a new build is stable (no crash loops, no elevated error rate from the deploy itself) and a flag to validate that a new feature is safe (correct behavior, acceptable business metrics), often for the same change, in sequence: canary the build first, then flag-gate the feature it contains. See Feature Flags vs. Guarded Rollouts for how rollfuse's own staged rollouts sit on the flag side of this line, with the same automatic-rollback guardrail mechanics a canary setup would otherwise need its own infrastructure layer to replicate.