What is Blue-Green Deployment?

Where the pattern came from

Daniel Terhorst-North described an early version in the mid-2000s, and Jez Humble's 2010 Continuous Delivery book made the pattern the standard reference. The motivating problem was very real for teams of that era: an in-place deploy meant a window during which the application was partly old and partly new, which was a window during which weird things could happen — half-broken pages, dropped sessions, mid-request errors. Blue-green eliminated the window by treating the two environments as atomic units.

How a release actually flows

A typical cycle: blue is serving production traffic. The team builds and deploys the new version to green. Smoke tests run against green from inside the data center. Synthetic users hit green's endpoints. A small percentage of real traffic — sometimes employees only, sometimes a single internal customer — is routed to green for confidence. Then the load balancer or DNS record flips, and green becomes the production environment. Blue stays alive, untouched, for a defined window. If anything goes wrong, the flip is reversed and blue is serving traffic again within seconds.

The database problem

The hardest part of blue-green deployment is the database, because both environments need to share one (or at minimum, the two databases have to stay in sync), and schema changes have to be backward compatible across both versions of the application for the duration of the cutover. The standard discipline is the "expand and contract" pattern: deploy schema changes additively (new columns, new tables) first, deploy the application code that uses them second, and only later remove the old schema in a clean-up release. Teams that ignore the discipline learn the hard way during their first rollback.

Blue-green vs canary

Both patterns aim to make releases safer. Blue-green is binary — at any moment, 100% of traffic is on one version. Canary is gradient — 1% on the new version first, then 5%, then 25%, with metrics watched at each step. Canary handles "the new version is slightly slower" or "the new version's error rate is 0.3% higher" better than blue-green does, because blue-green only shows you the problem after the full flip. Many mature teams combine both: blue-green for the safety property, canary inside the cutover for the gradient.

At QUANT LAB

For the platforms we ship on managed serverless infrastructure — typically Vercel for Next.js applications — blue-green is essentially built in. Each deployment gets its own immutable URL, the production alias is an atomic flip, and rollbacks take a single command. We pair that with feature flags so risky behavior changes can be staged independently of the release itself.

For clients on AWS, GCP, or Azure, our DevOps engineering practice builds blue-green into the deployment pipeline directly — ECS or Kubernetes services behind a load balancer that flips between target groups, with smoke tests and automated rollback gates. Read our platform engineering guide for the broader picture, or book a call for a one-hour review of your release process.