Blue-Green Deployment with a Reversible Switch
Run two identical environments, deploy to the idle color, verify it against production checks, switch traffic atomically, and keep a tested rollback path.
Objective
Release a new version with near-zero downtime and an instant rollback by switching traffic between two prepared environments.
Environment
- Two identical runtime environments (blue and green)
- A router, load balancer, or DNS layer that can switch traffic atomically
- Database changes compatible with both versions during the switch window
- Health checks and smoke tests that run against a color before cutover
Steps
1. Prepare the idle environment
Deploy the new version to the color that is not serving production traffic, using the same configuration and migration version as the target release.
Expected state: The idle color passes health checks and has no production traffic.
2. Run production-like verification
Execute smoke tests, contract tests, and a read-only check against real data through the idle color's internal endpoint.
Expected state: The new version handles representative requests without errors before any user sees it.
3. Switch traffic
Change the router or load balancer to send all traffic to the new color in one controlled operation, then watch error rate and latency.
Expected state: 100% of traffic reaches the new color; dashboards show no regression.
4. Hold a rollback window
Keep the old color running and its database compatibility intact until the rollback window closes.
Expected state: A single switch back restores the previous version if a defect appears.
5. Retire the old color
After the window, scale down the old environment and remove its routing rules.
Expected state: Only one color remains active, with no stale resources.
Decision points
Should the database migration run before or during the switch?
- Expand-contract migration compatible with both versions
- Breaking migration applied at cutover
Use expand-contract. A breaking migration makes rollback impossible without restoring data.
How long should the rollback window stay open?
- Until the next business-day peak has passed
- Only a few minutes after the switch
Cover at least one peak or a full business cycle for high-risk changes.
Expected outcome
The release reaches all users after passing checks in an isolated environment, and rollback requires only a routing change.
Verification
Compare error rate, p95 latency, and key business metrics before and after the switch; confirm the idle color passed the same checks and that the old color can still serve if switched back.
Cleanup
Remove the old color's routing rules and capacity after the rollback window, and delete temporary test credentials.
Two environments, one switch
Blue-green deployment separates release from exposure. The new version is deployed and tested in an environment that receives no production traffic. When it passes, the router switches traffic. If something is wrong, the router switches back. The old version stays warm during the rollback window, which makes recovery a routing decision rather than a rebuild.
upstream app {
server 10.0.1.10:3000; # blue
# server 10.0.2.20:3000; # green
}Changing the active upstream and reloading the proxy is one example; a managed load balancer, service mesh, or DNS weight change can provide the same atomic switch. Avoid switching traffic gradually unless you are intentionally running a canary. The value of blue-green is the clean, reversible cutover.
Database compatibility is the hard part
Both colors may serve traffic during the rollback window. A migration that removes a column or changes its type can break the old color immediately. Use expand-contract: add the new structure, deploy code that writes both shapes, switch reads, then remove the old structure in a later release. If the migration cannot be made compatible, the rollback plan must include a data restore, which is slower and riskier.
Verify before and after the switch
Run health checks against the idle color before the switch, then compare the same metrics after. A green health check only proves the process started. Smoke tests should exercise the critical user path with real dependencies. Keep the old color’s logs and metrics available during the rollback window so a comparison is possible.