Is blue‑green the same as canary deployment?

No. **Blue‑green** typically flips traffic 0→100% between two environments (with a rollback window). **Canary** shifts traffic gradually by percentage. Blue‑green optimizes for rollback speed and operational simplicity; canary optimizes for blast-radius reduction during ramp-up.

Can I do blue‑green if my database can’t handle two versions?

Sometimes, but you must design for backward compatibility. Use **expand/contract** migrations, avoid destructive schema changes during the rollout window, and ensure the new version can read data written by the old version (and vice versa) until you retire blue.

What’s a realistic target for rollback time?

For most web services, design for traffic rollback in **< 60 seconds**, and full customer-visible recovery in **< 5 minutes** (allowing caches and metrics to settle). If rollback takes longer than debugging, teams will debug instead—and MTTR will suffer.

What should I keep running after the flip?

Keep the old environment (blue) running and warm for a defined window—often **1–24 hours** depending on risk and traffic patterns. Use a TTL and cleanup automation so you don’t pay for zombie stacks.

Release-engineering · Dec 14, 2025 · 8 minute read

The Blue‑Green Cutover That Didn’t Wake Anyone Up (Because We Designed It That Way)

Q: What should I keep running after the flip?

Keep the old environment (blue) running and warm for a defined window—often **1–24 hours** depending on risk and traffic patterns. Use a TTL and cleanup automation so you don’t pay for zombie stacks.

Blue‑green is the simplest zero‑downtime strategy that still works at scale—if you treat cutover, verification, and rollback as product features, not tribal knowledge.

Back to all posts

The Blue‑Green Cutover That Didn’t Wake Anyone Up (Because We Designed It That Way)

Key takeaways

Implementation checklist