What Is Blue-Green Deployment? A Plain English Explanation

Deployments are scary. Every engineer who's pushed a bad release to production at 2 AM knows this feeling. Blue-green deployment exists specifically to make that fear go away — or at least reduce it significantly.

Let me explain what it actually is, without the buzzwords.

The Problem It Solves

Imagine you're deploying a new version of your application. The traditional way: you take down the old version, deploy the new one, and hope it works. If something breaks, you scramble to roll back while users are getting errors.

Blue-green deployment solves this by keeping the old version running while the new version goes live, then switching traffic instantly.

What Blue-Green Deployment Actually Is

You maintain two identical production environments:

• Blue — the current live version serving all your users
• Green — the new version you just deployed

When ready to release:

1. Deploy new version to Green
2. Test Green thoroughly
3. Switch all traffic from Blue to Green in one step
4. Blue becomes your instant rollback option

If Green breaks — switch back to Blue in seconds. Zero downtime, zero user impact.

A Real Kubernetes Example

# Blue deployment (currently live)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: blue
  template:
    metadata:
      labels:
        app: myapp
        version: blue
    spec:
      containers:
      - name: myapp
        image: myapp:v1.0.0

The Service points to blue via label selector:

apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  selector:
    app: myapp
    version: blue
  ports:
  - port: 80
    targetPort: 8080

To switch to Green:

kubectl patch service myapp-service \
  -p '{"spec":{"selector":{"version":"green"}}}'

To roll back:

kubectl patch service myapp-service \
  -p '{"spec":{"selector":{"version":"blue"}}}'

The entire switch takes less than a second.

Blue-Green vs Canary Deployment

The Downside Nobody Talks About

You need double the infrastructure. Two identical production environments means double compute and memory costs.

Database migrations are hard. If your new version requires a different schema, you need backward-compatible migrations so both versions can work with the same database simultaneously. This is genuinely the hardest part of blue-green in practice.

When to Use Blue-Green Deployment

Use it when:

• Downtime is unacceptable (payment systems, e-commerce checkout)
• You need instant rollback capability
• Your releases are thoroughly tested before going live

Consider alternatives when:

• Infrastructure is very expensive (canary is cheaper)
• You have complex database migrations
• Your team is small and managing two environments adds overhead

Tools That Make This Easier

Argo Rollouts is purpose-built for this:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: myapp
spec:
  strategy:
    blueGreen:
      activeService: myapp-active
      previewService: myapp-preview
      autoPromotionEnabled: false

Much cleaner than managing two Deployments manually.

The Bottom Line

Blue-green is simple in concept: keep the old version running until the new one is proven, then switch instantly. Once you've rolled back from a bad release in under 10 seconds with zero user impact, you'll never want to go back to the traditional approach.

Want to implement this properly? Check out our guide on canary deployments with Flagger.