The Problem With "Maintenance Windows"

Telling users "the site will be down from 2-4 AM for maintenance" is a 2010 approach. In 2026, users expect 24/7 availability. E-commerce sites lose revenue every minute they're down. SaaS products lose customer trust. There's no excuse for downtime during deployments when the tools exist to avoid it.

Strategy 1: Blue-Green Deployments

Run two identical environments: Blue (current production) and Green (new version). Deploy to Green, test it, then switch traffic from Blue to Green instantly. If something goes wrong, switch back in seconds.

Pros: Instant rollback, zero risk to users during deployment
Cons: Requires double the infrastructure cost during the switch

Strategy 2: Rolling Deployments

Update servers one at a time while others keep serving traffic. Kubernetes does this natively. With Docker Compose, you can approximate it with careful scripting.

# Deploy new version while old is still running
docker compose up -d --no-deps --build web
# Old container stays up until new one is healthy

Strategy 3: Database Migrations — The Hard Part

Most deployment downtime is actually caused by database migrations, not the app restart. The fix: write backwards-compatible migrations.

Wrong approach: Rename a column in one deployment (breaks the running app)
Right approach:

  1. Deploy 1: Add new column, write to both old and new column
  2. Deploy 2: Read from new column, stop writing to old
  3. Deploy 3: Remove old column

Yes, it takes three deployments. But none of them cause downtime.

Health Checks Are Non-Negotiable

Always have a /health endpoint that returns 200 only when the app is genuinely ready. Load balancers and orchestrators use this to avoid routing traffic to containers that are still starting up.

Want to set up zero-downtime deployments for your project? Let's discuss your infrastructure.