temps

Rollbacks

When a deployment has issues, roll back to a previous working version instantly—no downtime, no data loss, just a quick recovery.

Loading diagram...

Quick Rollback

From Dashboard

  1. Go to Deployments - Navigate to your project's deployments page
  2. Select Previous Deployment - Find the working version you want to roll back to
  3. Click Rollback - One click to switch back
  4. Done - Your app is now running the previous version

From CLI

# List recent deployments
temps deployments list --project my-app

# Rollback to previous deployment
temps deployments rollback --project my-app

# Rollback to specific deployment
temps deployments rollback --project my-app --deployment-id abc123

How Rollbacks Work

Zero-Downtime Process

  1. Previous deployment stays running - The old version continues serving traffic
  2. Switch routing - Point your domain to the previous deployment
  3. Traffic redirects instantly - Users see the working version immediately
  4. New deployment stops - The problematic deployment is stopped
  5. No data loss - All data remains intact

What Gets Rolled Back

  • Application code - Reverts to previous version
  • Environment variables - Uses previous deployment's environment
  • Container image - Uses previous container image
  • Domain routing - Points to previous deployment

What Doesn't Change

  • Database - Data remains unchanged
  • File storage - Uploaded files stay intact
  • Environment settings - Project-level settings unchanged
  • SSL certificates - Certificates remain valid

Rollback Strategies

Immediate Rollback

When you detect issues immediately:

# Rollback the latest deployment
temps deployments rollback --project my-app --latest

Use when:

  • Deployment fails health checks
  • Critical errors appear immediately
  • Performance degrades significantly

Automatic Rollback

Configure automatic rollback on failure:

# Deployment configuration
deployment:
  auto_rollback:
    enabled: true
    conditions:
      - health_check_fails: 3  # Rollback after 3 failed checks
      - error_rate_threshold: 0.1  # 10% error rate
      - response_time_threshold: 5000  # 5 seconds
    delay: 60  # Wait 60 seconds before rolling back

Use when:

  • Deploying to production
  • Critical applications
  • Unattended deployments

Canary Rollback

Roll back only a percentage of traffic:

# Rollback 50% of traffic to previous version
temps deployments rollback --project my-app --canary 50

Use when:

  • Testing if the issue is resolved
  • Gradual migration back
  • A/B testing scenarios

Deployment History

View History

See all your deployments and their status:

# List all deployments
temps deployments list --project my-app

# Output:
# ID       Status    Created              Version
# abc123   ACTIVE    2024-01-15 10:30    v1.2.0
# def456   STOPPED   2024-01-15 09:15    v1.1.9
# ghi789   STOPPED   2024-01-15 08:00    v1.1.8

Compare Deployments

See what changed between deployments:

# Compare two deployments
temps deployments compare \
  --project my-app \
  --deployment-1 abc123 \
  --deployment-2 def456

Shows:

  • Code changes (Git diff)
  • Environment variable changes
  • Resource limit changes
  • Configuration differences

After Rollback

Investigate the Issue

  1. View deployment logs - See what went wrong
  2. Check error tracking - Review errors from the failed deployment
  3. Compare configurations - See what changed
  4. Test locally - Reproduce the issue

Fix and Redeploy

Once you've fixed the issue:

  1. Make changes - Fix the code or configuration
  2. Test locally - Verify the fix works
  3. Deploy again - Create a new deployment
  4. Monitor closely - Watch for the same issues

Keep Previous Deployment

The previous deployment stays available for:

  • Reference - Compare with new deployments
  • Quick rollback - Roll back again if needed
  • Debugging - Investigate what changed

Best Practices

Before Deploying

  • Test in staging - Deploy to staging first
  • Review changes - Check what's different
  • Set up monitoring - Enable alerts
  • Have a rollback plan - Know how to roll back

During Deployment

  • Monitor health checks - Watch deployment status
  • Check error rates - Monitor for errors
  • Watch performance - Track response times
  • Be ready to rollback - Have the rollback command ready

After Deployment

  • Monitor for 5-10 minutes - Watch for issues
  • Check key metrics - Verify everything works
  • Test critical paths - Verify important features
  • Keep previous deployment - Don't delete it immediately

Rollback Limitations

What Can't Be Rolled Back

  • Database migrations - Schema changes persist
  • External API changes - Third-party integrations
  • File system changes - Files written to disk
  • Environment variable changes - If changed at project level

Manual Intervention Required

Some changes require manual fixes:

  • Database schema changes - May need migration rollback
  • External service changes - API contract changes
  • Breaking configuration - Invalid configuration files

Next Steps

Was this page helpful?