What is a blue-green deployment?
It turns a bad deploy into a five-second fix instead of an overnight one, but only if the database was built to allow it.
Blue-green deployment
Blue-green deployment is a release method that keeps two identical production environments, called blue and green. A router points at whichever one is live, and a new version deploys to the idle one, gets checked, then takes over in one switch.
Say blue is live and serving every user. The team deploys the new version to green, which sits idle behind the same load balancer. Nobody sees it yet.
Once green passes its checks, the switch flips. The router sends new requests to green instead of blue. Users notice nothing, because the switch is instant and both environments were built from the same image.
Blue stays up, untouched, for a while after the switch. If something goes wrong that the checks missed, flipping back to blue takes the same five seconds the forward switch did. That is the whole appeal: rollback is not a new deploy of the old code. It is the same switch, thrown the other way.
The database is where the metaphor breaks
Application servers are stateless. Two copies of the same server, built from the same image, are interchangeable. A database is not. Blue and green almost always share one database, because running two would mean syncing every write between them in real time.
That single database has to serve both colors during the switch, and during the rollback window after it. A migration that renames a column or drops one breaks whichever color is not expecting the change. Green might need the new column; blue, still live for the rollback window, cannot survive it disappearing.
This is what separates a team that has read about blue-green deployment from one that has run it. Split every schema change into steps that each color can survive. Add the new column without removing the old one. Ship the code that uses it. Drop the old column only once blue is retired for good.
- Live: blueServing all production traffic.
- Deploy to greenNew version ships to the idle environment.
- Check greenSmoke tests run against it with no user traffic.
- Flip the switchRouter points at green. Blue keeps running.
- Watch or revertFlip back to blue in seconds if green misbehaves.
Blue never gets torn down until green has proven itself. That idle copy is the rollback.
Blue-green against the release strategy it gets mixed up with
| Criterion | Canary deployment | Blue-green deployment |
|---|---|---|
| How much traffic sees the new version first | A small slice, often 5% or less, while the rest stays on the old version. | Zero, until the switch. Then all of it, at once. |
| How the rollout widens | Gradually, raising the percentage as confidence grows. | It does not widen. There is no partial state between blue and green. |
| What a rollback looks like | Route traffic back to the old version's share, reversing the ramp. | Flip the router back to the environment that was live before. |
| Infrastructure cost while both versions exist | Usually one environment, split by weighted routing. | Two full environments running at once, even briefly. |
Common questions
01Is blue-green deployment the same as zero-downtime deployment?
Blue-green is one way to get zero downtime, but the terms are not interchangeable. Rolling deployments and canary releases can also avoid downtime, using a gradual traffic shift instead of an instant switch. "Zero-downtime" describes the outcome; blue-green describes one specific method for reaching it.
02Do I need two full copies of my database?
Almost never. Running two databases means keeping every write in sync between them, which adds more risk than it removes. Blue and green share one database instead. The discipline shifts to writing schema changes that both versions of the application can read at once.
03How long should blue stay up after the switch?
Long enough to catch a problem that only shows under real traffic, which smoke tests on green will not surface. Many teams hold the old environment for a few hours to a day. Old schema columns get dropped only after that window closes with no rollback needed.
04Why use canary deployment instead of blue-green?
Canary catches problems earlier because a small slice of real users hits the new version first, before everyone does. Blue-green catches nothing early, but its rollback is simpler: one switch, not an unwind of a partial rollout. Teams with hard uptime requirements often use both, canary for the risky change and blue-green for the release itself.
Related terms
- Observability →What tells you whether green is healthy enough to trust with the switch.
- Technical debt →A schema change with no rollback path is the debt a rushed blue-green migration leaves behind.
- Software maintenance →Where we design the deploy and rollback process for a system already carrying live data.
- Vercel →A production review of the platform we use for deploy pipelines on client builds.
