Blue-Green Deployment

How it works

A blue-green deployment keeps two complete copies of an application environment. One (say blue) serves live traffic. The other (green) is idle or used for testing. To release, you deploy the new version to green, run smoke tests against it, and then switch traffic from blue to green in a single step. Blue is kept available so you can switch back.

The traffic switch can happen at different layers: a load balancer target group, a DNS record, a service mesh or ingress rule, or, in Kubernetes, the label selector of a Service. The key property is that users move between two fully running versions, rather than a mix of old and new instances.

The main advantage over a rolling update is fast rollback: you point traffic back at the old environment instead of redeploying it. The main cost is running two environments during the release, which increases infrastructure use for that period.

A practical example

In Kubernetes, two Deployments carry a version label (blue and green), and a single Service selects one of them:

apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
    version: blue
  ports: [{port: 80, targetPort: 8080}]

After green passes its checks, change version: blue to version: green (for example with kubectl patch) and traffic moves to the new pods. Reverting the selector is the rollback.

Common mistakes

• Sharing a database without planning schema changes. Both versions must work with the same schema, so use backward compatible migrations.
• Forgetting sessions and caches, which can log users out or serve stale data after the switch.
• Not testing green with realistic traffic before cutting over.
• Removing the old environment too soon, which removes the rollback path.
• Treating it as free: capacity quotas must allow two environments at once.

When to use it and when not to

Blue-green suits releases where fast, low risk rollback matters and the application can run in two copies. It is less attractive for very large or stateful systems where duplicating the environment is costly. Canary releases and rolling updates are alternatives that expose changes gradually; the right choice depends on risk and cost. Tools such as Argo Rollouts and Flagger support progressive delivery strategies in Kubernetes.

Related reading: CI/CD and Kubernetes. See also our automated rollback of failed deployments page.

See also

• CI/CD
• Kubernetes
• Helm Chart