Rollbacks

Push the rollback command and Temps takes it from there — it switches routing to the previous deployment with zero downtime and no data loss.

Quick rollback

Rollbacks revert deployments instantly. For data recovery scenarios—restoring a database, cloning a service, or point-in-time recovery from a backup—see Restore & Recovery. To configure the backups those restores draw from, see Set Up Backups & Monitoring.

Loading diagram...

Roll back to the previous deployment

Three ways to do this

1
Navigate to your project's Deployments page in the dashboard.
2
Find the previous working version you want to roll back to.
3
Open the deployment's menu (kebab/...) and choose 'Rollback to this'.
4
Temps keeps the previous deployment running, switches the domain to it, and stops the problematic deployment.
Checkpoint: Confirm the previous deployment now shows the Current badge and a success status on the Deployments page, and your app is serving the working version.

From Dashboard

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

From CLI

# List recent deployments
bunx @temps-sdk/cli deployments list --project my-app

# Rollback to previous deployment (rolls back to the previous deployment)
bunx @temps-sdk/cli rollback --project my-app

# Rollback to specific deployment
bunx @temps-sdk/cli deployments rollback --project my-app --to 456

How rollbacks work

Zero-Downtime Process

Previous deployment stays running - The old version continues serving traffic
Switch routing - Point your domain to the previous deployment
Traffic redirects instantly - Users see the working version immediately
New deployment stops - The problematic deployment is stopped
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

Roll back to a specific deployment

Three ways to do this

1
Open your project's Deployments page in the dashboard.
2
Locate the exact deployment ID you want to restore (for example 456) in the deployment history.
3
Open the deployment's menu (kebab/...) and choose 'Rollback to this'.
4
Temps switches routing to the chosen deployment with zero downtime.
Checkpoint: Confirm the targeted deployment now shows the Current badge and a success status on the Deployments page, and is serving traffic.

When you detect issues immediately:

# Rollback to the previous deployment (omit --to to roll back to previous)
bunx @temps-sdk/cli rollback --project my-app

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 to the previous deployment
bunx @temps-sdk/cli rollback --project my-app
# Canary traffic splitting is configured via the web UI

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
bunx @temps-sdk/cli deployments list --project my-app

# Output:
# ID    Status     Created              Version
# 789   success    2024-01-15 10:30    v1.2.0
# 456   deployed   2024-01-15 09:15    v1.1.9
# 123   deployed   2024-01-15 08:00    v1.1.8

Compare Deployments

See what changed between deployments:

# List deployments with full details as JSON
bunx @temps-sdk/cli deployments list --project my-app --json
# Deployment comparison is available in the web UI

Shows:

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

After rollback

Investigate the Issue

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

Fix and Redeploy

Redeploy after fixing the issue

Three ways to do this

1
Make and commit your changes to fix the code or configuration.
2
Test locally to verify the fix works.
3
Trigger a new deployment for the project from the dashboard.
4
Monitor the new deployment closely for the same issues.
Checkpoint: Watch the deployment status for 5-10 minutes and confirm it shows success status and stays healthy without the previous errors.