Zero-Downtime Deployments: Updating Self-Hosted Apps Safely

Why Downtime Matters

Every second of downtime is a frustrated user. For business applications — CRMs, project management, communication tools — even brief outages disrupt productivity.

Deployment Strategies

Rolling Deployment

Replace instances one at a time. At any moment, both the old and new version are running. Users experience zero downtime.

1. Start new container with updated image

2. Health check the new container

3. Route traffic to new container

4. Stop old container

Blue-Green Deployment

Run two identical environments: Blue (current) and Green (new). Deploy to Green, test, then switch all traffic.

1. Deploy new version to Green environment

2. Test Green thoroughly

3. Switch load balancer from Blue to Green

4. Keep Blue running as instant rollback

Canary Deployment

Route a small percentage of traffic (5-10%) to the new version. Monitor for errors. If everything looks good, gradually increase to 100%.

1. Deploy new version alongside old

2. Route 5% of traffic to new version

3. Monitor error rates and latency

4. Increase to 25%, 50%, 100%

5. If issues arise, route everything back to old version

Database Migrations

The trickiest part of zero-downtime deployments. Database schema changes must be backward-compatible:

Do

Don't

Strategy: make the schema change first (backward-compatible), deploy the code, then clean up old columns in a later migration.

TinyPod's Approach

When you deploy an update on TinyPod:

1. New container starts alongside the old one

2. Health checks verify the new container works

3. Caddy switches traffic to the new container

4. Old container is stopped

If the new container fails health checks, the old one keeps running. Zero downtime, automatic rollback.