Blue-green deployment strategy
Parallel environments, traffic switch, and instant rollback.
Blue-green deployment is the gold standard for zero-downtime releases: you maintain two identical production environments—blue (current) and green (staging)—deploy the new version to green, run full tests, then switch all traffic at once. If anything breaks, you flip back instantly. No canary ramps, no gradual rollouts: the traffic switch is binary, and rollback takes seconds.
This template maps the complete cycle: deploying to green, running smoke and integration tests, switching traffic, monitoring the new environment, and the critical decision loop — if green fails, bounce back to blue immediately; if it's healthy, blue becomes your next staging environment.
When to use this template
- High-consequence systems — financial transactions, authentication, payment processing, or core infrastructure where even brief errors cost real money or trust. Instant rollback is your insurance.
- Database migration reviews — use the diagram to explain why migrations must be backward-compatible and why both environments read/write the same schema during the transition.
- Release runbooks — document your exact traffic-switch procedure, monitoring windows, and the alarm thresholds that trigger a blue rollback. Teams follow the diagram step-by-step on deploy day.
How to adapt it
Customize the testing and monitoring nodes to your infrastructure:
- Add a load test step before switching: "Run load test on Green" to catch performance regressions before traffic moves.
- Insert health checks in the monitoring loop: replace "Monitor metrics" with individual checks (CPU, error rate, p99 latency) and trigger rollback on any threshold breach.
- Add a gradual traffic shift option: instead of switching all at once, route 10%, then 25%, then 100%, giving you more time to detect problems before full rollback cost kicks in.
Visual edits regenerate clean code, so you can map your exact infrastructure and monitoring strategy without syntax overhead.
Mermaid code
Copy it anywhere Mermaid is supported — GitHub, Notion, or your docs.
flowchart TD
A[Both Blue and Green environments] --> B[Deploy new version to Green]
B --> C[Run smoke tests on Green]
C --> D{Tests pass?}
D -->|No| E[Fix issues, retry Green]
E --> C
D -->|Yes| F[Route traffic to Green]
F --> G[Monitor Green metrics]
G --> H{Errors or issues?}
H -->|Yes| I[Instant traffic switch back to Blue]
I --> J[Investigate Green failure]
H -->|No| K[Keep Green as production]
K --> L[Blue becomes staging for next release]
J --> L
Frequently asked questions
- What is blue-green deployment and why use it?
- Blue-green keeps two identical production environments side-by-side: one live (blue), one staging (green). You deploy to the inactive environment, test it fully, then switch traffic instantly. If anything breaks, you flip back in seconds—true zero-downtime deploys with instant rollback, no gradual canary ramps needed.
- What is the difference between blue-green and canary deployment?
- Blue-green switches all traffic at once to a fully-tested, identical environment; rollback is instant. Canary gradually ramps traffic to a new version on live infrastructure; it detects problems slowly but saves resources. Choose blue-green when rollback speed matters most (financial, payment, auth systems) and canary for discovery (gradual traffic = real-world testing before full switch).
- What should I test on the green environment before switching?
- Smoke tests (critical user paths: login, create resource, pay, logout), integration tests (external APIs, databases, cache), and synthetic monitors replicating production traffic patterns. You want high confidence before the switch. Automated test suites that run in seconds are ideal; manual testing defeats the speed advantage.
- How do I handle database migrations in blue-green deployment?
- Migrations must be backward-compatible so both blue and green can share the same database. Migrate the schema first (adding columns, not removing), test both environments against the new schema, then deploy. Only after both are running smoothly can you remove the old columns in a follow-up deploy. Separate schema and code deploys to keep environments in sync.
Related templates
Canary deployment strategy
Roll out new versions to a small percentage of traffic, then scale up.
Database migration flow
Safe schema changes with validation, rollback, and production cutover.
Deployment rollback decision tree
Incident detection, severity assessment, and rollback trigger criteria.