vibecode.wiki
RU EN
~/wiki / zapusk-i-khosting / blue-green-deployment

Blue-Green Deployment: How to update your app without a second of downtime

◷ 7 min read 2/24/2026

Main chat

A chat for vibe coders: news, guides, live cases, marketplace, and finding executors.

$ cd section/ $ join vibe dev

You put together a cool bot, website or service and you need to roll out the update to the product. What if it breaks? Users will leave, metrics will fall, mood will spoil.

Blue-Green Deployment solves this problem. This is a strategy where you always have two completely identical production environments:

  • *Blue is now live, accepting all users.
  • **Green, standby, you roll out a new version.

You test Green in real conditions → all right → instantly switch traffic → Blue becomes standby (ready for the next deplo or rollback). Zero downtime, pullback in seconds, total safety.

How exactly does it work

  1. *Blue is an active medium (v1). Users access it through Load Balancer / Nginx / Kubernetes Service / Cloud LB.
  2. You're putting together a new version (v2) → you're only putting it in Green.
  3. Run smoke tests, health checks, integration tests directly on Green (via a private URL or a separate ingress).
  4. All green? Switch the router/balancer to Green.
  5. Now Green = live (v2), Blue = standby.
  6. On the next rollout, the roles change.

**Traffic switching occurs in 1-5 seconds:

  • Nginx: nginx -s reload after changing proxy_pass.
  • Kubernetes: kubectl apply updated Service (change selector).
  • AWS ALB/Cloud: Update Target Group.
  • Traefik/Caddy: Dynamic labels.

**Download ** Just bring the traffic back to Blue.

Advantages

  • Zero-downtime even with difficult migrations.
  • Instant rollback (even if 1% of users saw the bug right back).
  • Testing in 100% production environment (with real database, cache, secrets).
  • Easily integrated into CI/CD - the deploy becomes part of the piplin.
  • Ideal for Vibcoders: AI writes code → You get the entire blue-green stack in one prompt.

Configuration "through deploy"

This is the key point of the request. You're not fucking on the server.

  • *Terraform/Pulumi - Describes two environments in the code.
  • Helm + values.yaml - deploy_version: blue or green.
  • GitHub Actions / GitLab CI — each git push → build → deploy in an inactive environment → tests → switch.

The simplest implementation on VPS (Docker + Nginx) - to start

Ideal for a single server or a small project.

docker-compose.yml (with profiles):

yaml
services:
app-blue:
image: myapp:${TAG:-latest}
build:
profiles: [blue]
restart: unless-stopped
labels:
- "traefik.enable=true" # or use nginx

app-green:
image: myapp:${TAG:-latest}
build:
profiles: ["green"]
restart: unless-stopped

Nginx.conf (dynamic):

nginx
upstream backend {
    server app-blue:3000;  # меняем на app-green при switch
}

server {
    listen 80;
    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
    }
}

deploy.sh

bash
#!/bin/bash
ACTIVE=$(cat /var/run/active-slot.txt 2>/dev/null || echo "blue")
NEW_SLOT=$( [ "$ACTIVE" = "blue" ] && echo "green" || echo "blue")

docker compose --profile $NEW_SLOT up -d --build
sleep 10  # health check
curl -f http://localhost/health || exit 1

echo "$NEW_SLOT" > /var/run/active-slot.txt
sed -i "s/app-$ACTIVE/app-$NEW_SLOT/" /etc/nginx/nginx.conf
nginx -s reload

docker compose --profile $ACTIVE stop
echo "✅ Переключили на $NEW_SLOT!"

Launch: ./deploy.sh and that's it.

Full-fledged Kubernetes

Two Deployment + One Service that switches.

blue-deployment.yaml:

yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      color: blue
  template:
    metadata:
      labels:
        app: myapp
        color: blue
    spec:
      containers:
      - name: app
        image: myapp:v1
        readinessProbe:
          httpGet:
            path: /health
            port: 3000

Similarly, green-deployment.yaml (color: green, image: v2).

service.yaml (switched):

yaml
apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  selector:
    app: myapp
    color: blue   # ← меняешь на green и apply
  ports:
  - port: 80
    targetPort: 3000

Ingress always looks at myapp-service.

Switching:

bash
kubectl apply -f green-deployment.yaml
#wait ready
kubectl patch service myapp-service -p '{"spec":{"selector":{"color:"green"}}'
Blue can be removed or left as standby

Terraform + Kubernetes (full IaC configuration)

hcl
resource "kubernetes_deployment" "blue" { ... color = "blue" ... }
resource "kubernetes_deployment" "green" { ... color = "green" ... }

resource "kubernetes_service" "app" {
  spec {
    selector = {
      color = var.active_color  # "blue" или "green" — меняешь в variables.tf
    }
  }
}

terraform apply -var="active_color=green"XX

Database processing (most important)

Do not try to copy the database every time - use shared database + expand/contract:

  1. Add new columns / tables (v2 can work with the old circuit).
  2. Switch the app to v2.
  3. Starting data migration.
  4. Remove old columns (v1 is no longer used).

Tools: Flyway, Liquibase, Alembic, Prisma Migrate with --create-only.

If critical, make blue-green for RDS (AWS has built-in).

CI/CD: GitHub Actions

yaml
name: Blue-Green Deploy
on: [push]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - name: Build & Push
      run: docker build -t myapp:${{ github.sha }} && docker push ...
    - name: Deploy to inactive
      run: ssh user@server "./deploy-to-inactive.sh ${{ github.sha }}"
    - name: Tests
      run: curl -f https://staging.myapp.com/health
    - name: Switch
      run: ssh user@server "./switch.sh"

Ready-made AI prompts (copy and paste in Grok/Claude/GPT)

Prompt 1: Full stack for VPS (Docker + Nginx)

code
" Create a complete ready-to-use file set for blue-green deployment of my FastAPI (Python) application on Ubuntu VPS.
- docker-compose.yml with blue/green profiles
nginx.conf with dynamic upstream
deploy.sh with health checks, logging, rollback
- GitHub Actions workflow
Instructions for first launch and daily use.
Make it as reliable as possible, with zero-downtime and comments in Russian

Prompt 2: Kubernetes + Helm

code
Write a Helm chart for the blue-green deployment Node.js app in Kubernetes. Two Deployment (blue/green), Service with selector, Ingress. Add values.yaml with deploy version. Show me how to switch to CI/CD. Add Argo Rollouts option for automation

Prompt 3: Terraform + AWS ECS

code
Create Terraform code for blue-green deployment on AWS ECS Fargate with CodeDeploy. Two task definitions, ALB listener rules, lifecycle hooks for smoke tests. All declarative

Prompt 4: DB processing + migration

code
For my Prisma + PostgreSQL project, explain and give the code expand/contract migrations under blue-green. Show order: first migration schema, then switch app, then cleanup

Prompt 5: Analysis of your project

code
“Offer optimal blue-green implementation (VPS/K8s/Cloud) with minimal cost and maximum reliability. Give me the files

Comparison with other strategies

  • Rolling Update - Gradual replacement of pods (cheaper, but more difficult to roll back).
  • Canary – 1% → 10% → 100% of traffic (excellent for A/B, but more complex).
  • Blue-Green is the easiest and most reliable for most projects.