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

Next step

Open the bot or continue inside this section.

$ cd section/ $ open @mmorecil_bot

Article -> plan in AI

Paste this article URL into any AI and get an implementation plan for your project.

Read this article: https://vibecode.morecil.ru/en/zapusk-i-khosting/blue-green-deployment/ Work in my current project context. Create an implementation plan for this stack: 1) what to change 2) which files to edit 3) risks and typical mistakes 4) how to verify everything works If there are options, provide "quick" and "production-ready".
How to use
  1. Copy this prompt and send it to your AI chat.
  2. Attach your project or open the repository folder in the AI tool.
  3. Ask for file-level changes, risks, and a quick verification checklist.

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.