Blue-green deployment is a release strategy in which two identical production environments exist side by side: one, called blue, serves live traffic, while the other, called green, receives the new version. After the green environment is deployed and verified, all traffic is switched to it at once, and the blue environment remains available as an immediate rollback target.
In DevOps practice, blue-green deployment is one of the main techniques for releasing without downtime and for making releases reversible within seconds. It is typically the final stage of a continuous delivery pipeline, after build, automated tests and staging verification.
How a blue-green deployment works
The strategy separates deploying a new version from releasing it to users. The new version is installed on the idle environment while users continue to work with the current one, so problems during installation never reach production traffic.
- Blue serves all users; green is idle or holds the previous release.
- The pipeline deploys the new version to green and runs smoke tests against it through a private address.
- Operators or automated checks verify health, logs and key transactions on green.
- The router, load balancer or DNS record switches traffic from blue to green.
- Blue stays ready for instant rollback until the new release is trusted, then becomes the target for the next release.
The colors carry no meaning of their own; they simply alternate roles with every release. The environment that is idle today receives the next version tomorrow.
Ways to switch traffic
The switch must be fast, atomic and reversible. The mechanism chosen determines how quickly the cutover completes and how cleanly existing connections are handled.
| Mechanism | Switch speed | Handling of existing connections | Main caveat |
|---|---|---|---|
| Load balancer target change | Seconds | Connection draining on the old pool | Requires a balancer in front of both |
| Kubernetes Service selector change | Seconds | New connections go to green Pods | Long-lived connections stay on blue |
| Reverse proxy upstream reload | Seconds | Graceful reload finishes old requests | Configuration must be tested first |
| DNS record change | Minutes to hours | Clients move as caches expire | TTL and resolver caching delay the cutover |
| Router or gateway rule | Seconds | Depends on the gateway | Adds dependency on routing layer |
DNS-based switching is the least predictable option, because resolvers and clients may cache records beyond the configured TTL. Balancer or proxy switching is preferred whenever instant rollback is a real requirement.
Blue-green deployment compared with other release strategies
Blue-green deployment is one of several strategies for releasing changes safely. They differ in how much traffic sees the new version at first, how fast rollback is and how much extra infrastructure they require.
| Strategy | Exposure of new version | Rollback speed | Extra capacity needed |
|---|---|---|---|
| Blue-green deployment | All users at once after verification | Seconds, switch back | About double during release |
| Canary deployment | Small share first, then gradually more | Fast, shift traffic back | Small extra share |
| Rolling update | Instances replaced one batch at a time | Slower, roll forward or back | Little or none |
| Recreate | All users after downtime | Slow, redeploy old version | None |
| Feature flags | Selected users or segments | Instant, toggle off | None, but code complexity |
The key difference from a canary deployment is that blue-green exposes everyone at once, so it relies on pre-switch verification rather than on observing a small group of real users. Teams often combine both, sending a small share of traffic to green before completing the switch.
Databases and stateful components
Application servers are easy to duplicate, but shared state is the hardest part of blue-green deployment. Both environments usually use the same database, because copying production data at every release is impractical and would lose writes made during the switch.
Schema changes must therefore be backward compatible, so that the old and new versions can work with the same database. The common technique is the expand and contract pattern: first add new columns or tables without removing old ones, release the new code, and remove obsolete structures only in a later release.
| Component | Risk during switch | Recommended approach |
|---|---|---|
| Relational database | Schema incompatible with blue | Expand and contract migrations |
| User sessions | Users logged out after switch | Store sessions in a shared external store |
| Message queues and jobs | Both versions consume messages | Version messages or pause consumers on blue |
| Caches | Stale or incompatible cached data | Versioned cache keys |
| File uploads | Files written to one environment only | Shared object storage |
Costs, limits and common mistakes
The obvious cost is duplicate capacity. With fixed hardware, the idle environment represents unused servers; in cloud and container platforms, the green environment can be created only for the duration of the release, which reduces the cost to a short period of double usage.
- Environment drift between blue and green invalidates testing; build both from the same infrastructure code.
- Destructive schema changes make rollback impossible once green has written new data.
- Skipping verification on green turns the strategy into an expensive big-bang release.
- Forgetting background workers leaves scheduled jobs running on both environments.
- Tearing down blue too early removes the rollback path before the release is proven.
A rollback in blue-green deployment is only as instant as the state allows. If the new version has already written data in a format the old version cannot read, switching back restores the code but not consistency, which is why compatible data changes are the real foundation of the strategy.
The short version
Imagine a theater with two identical stages. While the audience watches a play on one stage, the crew builds and rehearses the new production on the other. When everything is ready, the audience simply turns to face the new stage.
If something goes wrong, they turn back to the old stage, which is still fully set up. Nobody has to wait for a rebuild, and the switch takes only a moment.
Where it makes a difference
A ticket sales platform cannot afford downtime, because popular events go on sale at announced times and even a minute of errors means lost sales and angry customers. Its previous practice of stopping servers for updates required late-night maintenance windows.
The team moves to blue-green deployment on its container platform. Each release creates a green set of 12 application instances next to the 12 blue ones, runs automated checkout tests against green through an internal address, and then changes the load balancer target. Database changes follow the expand and contract pattern.
Releases now happen during business hours. When one release shows a rise in payment errors within five minutes of the switch, the team switches back to blue in under 30 seconds, fixes the defect and releases again the same afternoon, with no maintenance window needed.