Stop 17 · CI/CD & DeploymentTopics · 5/9

Blue-Green Deployment

In short

What if deploying meant flipping a switch, and rolling back meant flipping it back? That's blue-green: two full copies of production, with only one live at a time.

A release strategy running two identical production environments (blue and green) — deploying to the idle one, then switching traffic over instantly, enabling zero-downtime releases and instant rollback.

The purple blob pulls a lever that sends passengers from an old blue train to a new green one.

Think of it like this

Two platforms, one announcement

Passengers wait on platform 1 for the old train. The railway parks a fresh train on platform 2, checks the brakes and lights, then announces 'please move to platform 2'. If something seems wrong, everyone walks back. Nobody waits on a train being repaired.

Watch it happen

The switch from v1 to v2

Users

Load balancer

Blue (v1)

Green (v2)

GET /orders

1/5Users hit the load balancer, which currently sends all traffic to blue, running v1.

The big ideas

What you need to know

Two identical environments

Blue and green have the same servers and config. Only one takes live traffic at any moment.

Instant switch

The cutover is a router or load balancer change, not a slow rollout, so new requests go to v1 or v2, never a mix.

Rollback is a flip

Keep blue running for a while after the switch. Going back is the same one-line change.

The database is shared

Both colours usually use one database, so schema changes must work for v1 and v2 at the same time.

See it in code

Walk through the code

nginx

1# /etc/nginx/conf.d/app.conf2upstream blue  { server 10.0.0.11:3000; }3upstream green { server 10.0.0.12:3000; }4 5server {6  listen 80;7  location / {8    proxy_pass http://green;   # was http://blue9  }10}11 12# Test the config, then reload without dropping connections:13# sudo nginx -t && sudo nginx -s reload

1/3Two upstreams: blue runs v1, green runs v2. Both are up.

Managed load balancers do the same with a target-group switch. The idea is identical: two pools, one pointer.

Save yourself the pain

Common mistakes

Oops

Dropping a database column in the same release that stops using it.

Do this instead

Blue still needs that column during the switch. Remove it in a later release, once blue is gone.

Oops

Shutting down blue the moment green goes live.

Do this instead

Keep blue warm for an hour or a day. That's your instant rollback.

Your mission

Flip between two versions

~30 min

Quick check

Green is live and a bug shows up 10 minutes later. What's the fastest safe fix?

Go deeper

1Diagram how traffic switches from the old to new environment in blue-green.
2Learn why this strategy makes rollback nearly instant compared to redeploying an old version.
3Understand the cost trade-off: you need double the infrastructure running briefly.