Blue-Green Deployment

Blue-green deployment is a release strategy that maintains two identical, independently running production environments — conventionally labeled “blue” (the currently live version) and “green” (the new version being deployed) — and switches all live traffic from one to the other in a single cutover, rather than updating a single environment in place.

How It Works

The new version of an application is deployed and fully tested in the idle environment (green, in this example) while the blue environment continues serving all production traffic uninterrupted. Once the green environment has passed its checks, a router, load balancer, or DNS change redirects all traffic from blue to green essentially instantaneously. The blue environment isn’t torn down immediately — it’s kept running for a period as an instant rollback target, so if a problem is discovered in green after the cutover, traffic can be switched straight back to blue with no redeployment needed.

Why It’s Valuable

This approach eliminates the downtime typically associated with in-place deployments, where an application might need to be taken offline briefly to update — with blue-green, the switch between fully functional environments can be effectively instant from the user’s perspective. It also provides a fast, low-risk rollback path: reverting a bad deployment doesn’t require redeploying the previous version, just re-pointing traffic to an environment that’s still running it.

The Cost Tradeoff

The main downside is cost and complexity: running two complete production environments simultaneously, even briefly, roughly doubles infrastructure spend during the deployment window, and any resources with persistent state (particularly databases) require careful handling since they generally can’t simply be duplicated the way stateless application servers can. This is why blue-green is most commonly applied to stateless application tiers, with the data layer handled through separate migration strategies.

Handling Stateful Data During Blue-Green Switches

The main architectural challenge in blue-green deployment involves the data layer: while stateless application servers can simply be duplicated across blue and green environments, a shared database generally can’t be — most blue-green implementations keep a single shared database used by both environments, applying database schema migrations carefully in a backward-compatible way (so the old application version continues functioning correctly against the updated schema) rather than trying to duplicate stateful data stores. This requirement for backward-compatible migrations is one of the more subtle but important disciplines teams need to adopt to use blue-green deployment safely for any application with a real, persistent data layer.