A blue-green deployment is a release strategy that keeps two identical production environments. One (blue) serves live traffic while the new version is deployed and tested on the other (green). Traffic is then switched to green in one step, and switching back to blue provides a fast rollback.
What a blue-green deployment is
A blue-green deployment separates installing a new version from releasing it to users. You run two production environments that are as identical as possible. At any moment one of them, say blue, receives all user traffic. The new release is deployed to the idle green environment, where it can be warmed up, smoke-tested and verified against real dependencies. When the team is satisfied, a router, load balancer or DNS change moves traffic from blue to green. Blue stays on standby, so if something goes wrong the switch can simply be reversed.
The technique was popularized by Martin Fowler and others as a way to achieve near-zero-downtime releases and a rollback that does not depend on rebuilding or redeploying anything. After a successful release, the roles swap: green becomes the live environment and blue becomes the target of the next deployment.
How the cutover works
- Deploy to the idle environment. Green receives the new build while blue keeps serving.
- Verify. Run smoke tests, health checks and synthetic transactions against green through an internal or preview endpoint.
- Switch traffic. Change the load balancer target group, the Kubernetes Service selector, an ingress rule or DNS so that new requests go to green.
- Observe. Watch error rate, latency and saturation on green and compare them with the pre-release baseline.
- Keep or roll back. If the signals stay healthy, decommission or recycle blue; if not, switch back.
In Kubernetes, a simple variant uses two Deployments with labels such as version: blue and version: green and one Service whose selector is changed. Tools like Argo Rollouts formalize this with an active and a preview Service and optional automated analysis before promotion. On cloud platforms, services such as AWS CodeDeploy and weighted load balancer target groups offer the same pattern.
Blue-green vs canary deployment
| Aspect | Blue-green | Canary |
|---|---|---|
| Traffic shift | All at once (or in very few steps) | Gradual, e.g. 1%, 10%, 50%, 100% |
| Blast radius of a bad release | All users until rollback | Only the canary share |
| Rollback | Switch back, usually seconds | Set canary weight to zero |
| Infrastructure | Two full environments during release | Small extra capacity for the canary |
| Signal quality | Full production load immediately | Needs enough canary traffic to compare |
Many teams combine both: deploy green, send a small canary share to it first, then cut over completely. See canary deployment for the gradual approach.
What to observe during the switch
A blue-green cutover is only as safe as the signals used to judge it. Tag every span and metric with the deployed version, for example the OpenTelemetry resource attribute service.version, so dashboards can split blue and green. Useful checks in the first minutes after the switch include:
- Error rate and p95/p99 latency per endpoint, compared with the same period before the release.
- Error budget burn rate over a short window, which shows whether the release threatens the SLO.
- Saturation signals such as connection pools, CPU and cold caches, which often spike right after a cutover.
- Business signals such as checkout or login success, which catch functional regressions that return HTTP 200.
Where blue-green gets tricky
Databases. Both environments usually share one database, so a schema change must work with the old and the new version at the same time. The common answer is the expand-and-contract pattern: first add new columns or tables in a backward-compatible way, release the code, and remove old structures only in a later release. Otherwise the "instant rollback" fails because blue cannot read what green wrote.
Long-lived connections and sessions. WebSockets, gRPC streams and in-memory sessions stay on blue after the switch. Plan connection draining and keep session state outside the instances.
Cost and drift. Running two full environments doubles capacity during the release window, and an idle environment that is rarely used drifts from production configuration over time. Infrastructure as code helps keep them identical.
Background jobs and consumers. Queue consumers and schedulers in both colors may process the same work twice unless only the live color is allowed to run them.
How Obseria helps
Obseria deployment tracking records each release as an event and compares error rate, latency and SLO burn before and after the switch, split by service.version. Workflows in Obseria Automation can act as a release gate and trigger a rollback when green degrades, with SLOs as the objective criterion.
