Free — no signup required

Blue/Green Deployment: The Instant Switch

2 min read

The Light Switch Approach

Blue/Green deployment is designed for two things: instant cut-over and instant rollback. The name comes from the convention of labeling the two environments with colors.

You maintain two complete, identical production environments simultaneously:

  • Blue: The currently live environment running the old version (v1). Real users are hitting this right now.
  • Green: An exact clone of the environment running the new version (v2). No real users are touching it yet.

A load balancer (or DNS, or an ingress controller) sits in front of both environments and decides where traffic goes. Currently, it sends 100% of traffic to Blue.

You deploy v2 to Green and test it thoroughly — run smoke tests, integration tests, manual verification. Since no real users are on Green, you can break things without consequence. When you are confident Green is ready, you update the load balancer configuration. Instantly, 100% of real traffic starts flowing to Green. Blue is now idle but still running.

Rollback in Seconds

The killer feature of Blue/Green is rollback speed. If something goes wrong with Green after the switch, you flip the load balancer back to Blue. The old version never stopped running — it was just idle. Rollback takes seconds, not minutes.

The Database Problem

Blue/Green is powerful, but it has one major architectural constraint: the database. Both Blue and Green typically share the same database. If v2 requires a schema change — say, renaming a column from user_name to username — you face a dilemma:

  • If you apply the schema change before the switch, v1 (still live on Blue) breaks immediately because it references the old column name.
  • If you apply the schema change after the switch, v2 on Green breaks because the column it expects does not exist yet.

The solution is expand-and-contract migrations (also called the "parallel change" pattern):
1. Expand: Add the new column username without removing user_name. Write code in v2 that writes to both columns.
2. Switch: Flip traffic to Green (v2). Both columns exist; v1 on Blue could still roll back safely.
3. Contract: After you are confident in the rollout, run a migration to drop the old user_name column.

This requires discipline and planning, but it is the only safe way to do Blue/Green with stateful applications.

Infrastructure Cost

The obvious downside of Blue/Green is cost. You are running two full production environments simultaneously. For large-scale systems, this can double your infrastructure bill during deployments. Some teams mitigate this by scaling down the idle environment to a minimal footprint between deployments.

This is one of 18 chapters

Every chapter is free — Kubernetes, Terraform, SRE, distributed systems, and more — with fast daily review built in.

Sign up free