Blue-Green Deployment: How to update your app without a second of downtime
Next step
Open the bot or continue inside this section.
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
- Copy this prompt and send it to your AI chat.
- Attach your project or open the repository folder in the AI tool.
- 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
- *Blue is an active medium (v1). Users access it through Load Balancer / Nginx / Kubernetes Service / Cloud LB.
- You're putting together a new version (v2) → you're only putting it in Green.
- Run smoke tests, health checks, integration tests directly on Green (via a private URL or a separate ingress).
- All green? Switch the router/balancer to Green.
- Now Green = live (v2), Blue = standby.
- On the next rollout, the roles change.
**Traffic switching occurs in 1-5 seconds:
- Nginx:
nginx -s reloadafter changingproxy_pass. - Kubernetes:
kubectl applyupdated 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: blueorgreen. - 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):
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):
upstream backend {
server app-blue:3000; # меняем на app-green при switch
}
server {
listen 80;
location / {
proxy_pass http://backend;
proxy_set_header Host $host;
}
}
deploy.sh
#!/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:
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):
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:
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)
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:
- Add new columns / tables (v2 can work with the old circuit).
- Switch the app to v2.
- Starting data migration.
- 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
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)
" 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
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
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
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
“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.