Blue-Green Deployment Explained With Practical Examples

Blue-green deployment is a release strategy that runs two identical production environments—blue (live) and green (idle)—and switches traffic to the new version in one step. Rollback means routing traffic back to the previous environment instead of redeploying old artifacts under pressure.

If you have ever shipped a bad release and spent an hour rolling forward fixes while users hit errors, blue-green deployment is worth understanding even on a small team.

The basic idea

At any moment, one environment serves 100% of user traffic. You deploy the candidate release to the idle environment, run smoke tests against it, then flip a router (load balancer, DNS, service mesh) so green becomes live. Blue stays warm for instant rollback.

Users ──► Load Balancer ──► Blue  (v1.4)  ◄── currently live
                    └──► Green (v1.5)  ◄── tested, waiting

After cutover:

Users ──► Load Balancer ──► Green (v1.5)  ◄── live
                    └──► Blue  (v1.4)  ◄── standby for rollback

The names are arbitrary; some teams use color labels, active/candidate, or version numbers.

Blue-green vs rolling deployment

Approach	Downtime	Rollback speed	Resource cost	Risk profile
Blue-green	Near zero if health checks pass	Seconds (traffic flip)	~2× prod capacity during cutover	All users move at once
Rolling	Zero if pods replace gradually	Slower; must redeploy old version	Lower extra capacity	Mixed versions during rollout
Canary	Zero	Fast if automated	Moderate	Subset of users first

Blue-green fits teams that want binary releases: either everyone is on v1.5 or everyone is on v1.4.

When blue-green shines

Database-compatible releases where schema changes are backward compatible or feature-flagged.
Statefulless web tiers behind a load balancer.
Regulated environments that require a tested standby before promotion.
Demo or sales environments that must never show half-upgraded UI.

When it gets hard

Blue-green is not magic. Pain points include:

Database migrations

If v1.5 requires a breaking schema change, you cannot simply flip traffic. Common patterns:

Expand-contract migrations: add columns compatible with both versions, deploy green, backfill, then remove old columns later.
Dual-write periods: both versions write compatible shapes temporarily.

Skipping this planning causes the classic "green is up but every write fails" incident.

Sessions and sticky state

User sessions stored only on blue servers disappear after cutover unless sessions live in Redis, a database, or encrypted cookies independent of the pod.

Background jobs

Workers on green might double-process queues if both environments run consumers during transition. Pause consumers on blue before cutover or use queue visibility timeouts carefully.

Third-party webhooks

Partners hitting a single URL need DNS or load balancer updates to point at green; webhook replay logic should tolerate duplicates during the switch window.

A minimal AWS example

A typical stack:

Two target groups behind an Application Load Balancer: tg-blue, tg-green.
ECS services or Auto Scaling groups pinned to each target group.
Route 53 or ALB listener rules weighted 100/0 toward blue.
CI pipeline deploys to green, runs synthetic checks against green's hostname or internal test listener.
Pipeline shifts ALB weights to 0/100.
Old blue becomes the next green after a soak period.

Terraform or CloudFormation should encode weights so rollbacks are repeatable, not manual console clicks.

Kubernetes variant

In Kubernetes, blue-green often maps to:

Two Deployments (app-blue, app-green) behind one Service.
Switch Service selector labels, or use Argo Rollouts / Flagger for automated promotion.

Service meshes (Istio, Linkerd) can shift traffic percentages before a full cutover—a hybrid canary-blue-green flow.

Testing before the flip

Define pass/fail gates:

HTTP health endpoints return 200 with dependency checks (DB, cache).
Synthetic login journey succeeds.
Error rate in logs below threshold for N minutes.
Load test at expected QPS without latency regression.

Automate these; human "looks fine" checks miss config drift.

Rollback procedure (write this before you need it)

Document:

Who can authorize rollback.
Exact command or IaC change to restore weights.
Maximum acceptable age of blue environment before it is too stale to rollback.
Communication template for status page updates.

Rollback in blue-green should take under five minutes if blue was not destroyed immediately after cutover.

Cost trade-off

Running double capacity is the main bill increase. Mitigations:

Scale green smaller until cutover window, then match blue.
Use blue-green only for major releases; rolling for minor patches.
Serverless or scale-to-zero green in non-peak hours for internal apps.

Comparison with feature flags

Feature flags decouple code deployment from feature exposure. Blue-green decouple infrastructure versions. Mature teams combine both: deploy green with flags off, enable flags after traffic moves, rollback via flag disable without another deploy.

Metrics that prove blue-green is working

Track release quality, not just deploy frequency:

Change failure rate after cutover vs rolling releases.
Mean time to restore (MTTR) when rollback is traffic-only.
Time spent in dual-environment mode (cost proxy).

If MTTR does not improve within two release cycles, your bottleneck is probably database migrations or missing smoke tests—not the color labels.

Organizational habits that help

Release calendar: major releases use blue-green; hotfixes use rolling.
Ownership: one on-call engineer can execute rollback without a committee.
Blameless postmortems that distinguish "bad code" from "bad process" (for example, skipping green smoke tests).

Teaching junior engineers to draw the traffic diagram on a whiteboard prevents mystique around load balancer consoles.

Classroom exercise

Sketch a three-tier app (web, API, Postgres) and answer:

Where does schema v1.5 diverge from v1.4?
Where do sessions live during cutover?
What happens to in-flight checkout transactions?

If any answer is "not sure," fix the design before automating blue-green in production.

Tooling landscape in 2026

Managed platforms encode blue-green differently:

AWS CodeDeploy supports blue-green for EC2 and ECS with automatic rollback triggers.
Spinnaker pipelines express red-black (same concept, different name) with manual judgment gates.
Render and Fly.io offer one-click deploy with previous release promotion for smaller apps.

Pick tooling that matches team size—a startup on Fly does not need Spinnaker on day one, but should still document which release is live and how to revert.

Coordinating with product and support

Before cutover, notify support with:

Expected user-visible changes (even if none).
Window when rollback might occur.
Feature flags toggled after traffic moves.

Support tickets spike when users see mixed UI states; clear communication reduces "bug" reports that are actually cached assets.

FAQ

Is blue-green the same as zero-downtime deployment?
It enables zero downtime when health checks and migrations are correct. Misconfigured databases or sessions still cause user-visible errors after the flip.

How long should blue stay warm?
Often 24–72 hours for consumer products; longer for monthly release trains. Destroy blue only after error budgets stay green.

Can small startups use blue-green?
Yes, at modest scale with managed platforms (Render, Fly.io, ECS Fargate). The discipline matters more than enterprise tooling.

What about mobile clients?
Mobile apps cache API behavior. Coordinate API backward compatibility with app store release timing; blue-green on the server does not fix old app binaries.

Summary for learners

Blue-green deployment trades extra infrastructure for fast, reversible releases. Success depends less on the color metaphor and more on migration compatibility, session storage, automated tests, and a written rollback runbook. Learn rolling and canary strategies too—but when you need to undo a bad deploy in one click, blue-green remains one of the clearest patterns in the DevOps toolkit.