Blue-green, canary, and feature flags: a taxonomy

Blue-green, canary, and feature flags are three distinct tools that solve related but different problems. Teams often conflate them or treat them as interchangeable. They are not. Understanding which problem each one solves determines which one belongs in your deployment pipeline and which two do not.

Blue-green: infrastructure-level switchover

Blue-green deployment maintains two identical production environments. Traffic runs on blue. The new version deploys to green. When green is verified, traffic switches. Rollback is a routing change back to blue. This is an infrastructure-layer strategy — it solves the problem of zero-downtime deployment and fast rollback, not the problem of progressive exposure to users.

• Best for: stateless services that need zero-downtime deployment and fast rollback
• Not suited for: database schema migrations (both environments share a DB), cost-sensitive workloads (double the infra)
• Rollback time: seconds (DNS or load balancer switch)
• Operational complexity: medium — requires identical environment maintenance

Canary: progressive traffic exposure

Canary deployment routes a small percentage of production traffic to the new version — 1%, 5%, 20% — and monitors metrics before widening exposure. This is a traffic-management strategy. It solves the problem of discovering bugs that only appear under real production load, not in staging. The key requirement is real-time monitoring that you are actually watching.

• Best for: high-traffic services where staging does not faithfully replicate production load
• Requires: real-time error rate and latency monitoring with automatic or manual halt triggers
• Rollback time: minutes (reroute percentage back to zero)
• Operational complexity: high — requires traffic routing infrastructure and active monitoring

Feature flags: code-level exposure control

Feature flags (or feature toggles) control which users see a feature at the code level, independently of deployment. A feature can be deployed to production — in the codebase, passing tests, running on servers — but not exposed to users until the flag is enabled. This decouples deployment from release, which is the most powerful shift in deployment practice available to most teams.

• Best for: controlled rollouts, A/B testing, kill switches for risky features
• Decouples deployment from release — ship code any time, release when ready
• Enables targeting by user segment, geography, or account — gradual exposure without infrastructure changes
• Operational complexity: low to medium (flag service required); risk: flag debt accumulates quickly without discipline

Feature flags are the highest-leverage deployment tool for most teams because they solve the release problem, not just the deployment problem.

Which to use and when

• Zero-downtime infrastructure swap → blue-green
• Progressive traffic exposure with monitoring → canary
• Decoupling code deployment from feature release → feature flags
• Most teams at 15–100 engineers → feature flags + simple deploy, skip the rest until the pain is real