Backups

Temps backs up managed services automatically on your schedule and stores the result in any S3-compatible bucket. Configure a schedule once, and Temps handles snapshot capture, upload, retention cleanup, and failure alerting. Restore in place or clone to a new service from any past backup.

This is the feature reference. For step-by-step setup instructions, see Set Up Backups & Monitoring. For recovery scenarios, see Restore & Recovery.

Loading diagram...

Quick start

Enable automatic backups

Go to Project Settings - Navigate to your project
Open Backups Tab - Click on "Backups" in settings
Create Backup Schedule - Set frequency and retention
Done - Backups run automatically

Create backup now

Run a backup now

Three ways to do this

1
Open the service detail page for the managed service you want to back up.
2
Click Run Backup Now.
Checkpoint: Watch the backup appear in the Backups tab and wait until its status shows completed.

# Trigger an immediate backup for a managed service
bunx @temps-sdk/cli backups run-service \
  --id <service-id> \
  --s3-source-id <s3-source-id> \
  --type full

You can also trigger a backup from the web UI: open the service detail page and click Run Backup Now.

What gets backed up

Application data

Container volumes - Persistent data written to mounted paths inside the container
File uploads - User-uploaded files stored on the service filesystem
Configuration files - App-specific configs present on the volume

Database backups

If you're using managed databases:

PostgreSQL - Full database dumps
Redis - RDB snapshots
MySQL - Database exports
MongoDB - Database dumps

Configuration

Environment variables - Encrypted backup
Deployment settings - Resource limits, ports
Domain configurations - SSL certificates, routing
Team settings - Permissions, access

Backup schedules

Create schedule

Create a backup schedule

Three ways to do this

1
Navigate to your project and open Project Settings.
2
Click the Backups tab in settings.
3
Click Create Backup Schedule and set the frequency (e.g. daily at 2 AM), backup type (full or incremental), and retention period (e.g. 30 days).
Checkpoint: Confirm the new schedule appears in the Backups tab so future runs fire automatically.

# Daily full backup at 2 AM, kept for 30 days
bunx @temps-sdk/cli backups schedules create \
  --name "daily-full" \
  --schedule "0 2 * * *" \
  --type full \
  --retention 30 \
  --s3-source-id <s3-source-id>

# Weekly full backup on Sundays at 3 AM, kept for 90 days
bunx @temps-sdk/cli backups schedules create \
  --name "weekly-full" \
  --schedule "0 3 * * 0" \
  --type full \
  --retention 90 \
  --s3-source-id <s3-source-id>

# Every 6 hours incremental backup, kept for 7 days
bunx @temps-sdk/cli backups schedules create \
  --name "6h-incremental" \
  --schedule "0 */6 * * *" \
  --type incremental \
  --retention 7 \
  --s3-source-id <s3-source-id>

Schedule options

Frequency:

Hourly - Every X hours
Daily - Once per day at specific time
Weekly - Once per week on specific day
Monthly - Once per month on specific date

Retention:

Keep backups for X days
Automatic cleanup of old backups
Configurable per schedule

Backup storage

Storage options

Local Storage (Default)

Stored on Temps server
Fast access
Included in Temps hosting

S3-Compatible Storage

AWS S3, MinIO, DigitalOcean Spaces
Off-site backup
Configurable regions

External Storage

Custom S3-compatible endpoints
Your own storage infrastructure

Configure storage

Add an S3 backup source

Three ways to do this

1
Open Project Settings and click the Backups tab.
2
Add a new S3 backup source and enter the bucket name, region, and access/secret keys (set a custom endpoint for MinIO or DigitalOcean Spaces).
3
Save the source.
Checkpoint: Confirm the source is listed so schedules and on-demand backups can target it.

# Add an S3-compatible backup source
bunx @temps-sdk/cli backups sources create \
  --name "my-s3-backups" \
  --bucket my-backups \
  --region us-east-1 \
  --access-key YOUR_KEY \
  --secret-key YOUR_SECRET

# List configured sources
bunx @temps-sdk/cli backups sources list --json

Restore from backup

List backups

# List backups for a specific schedule
bunx @temps-sdk/cli backups list --schedule-id <schedule-id> --json

# Show details for a specific backup
bunx @temps-sdk/cli backups show --id <backup-id> --json

# List all configured schedules
bunx @temps-sdk/cli backups schedules list --json

Restore backup

Restore a service from a backup

Three ways to do this

1
Open the service detail page.
2
Go to the Backups tab.
3
Click Restore next to the backup you want to restore from. An in-place restore (no new-service option selected) is DESTRUCTIVE and will OVERWRITE the existing service data — confirm the OVERWRITE prompt to proceed.
Checkpoint: Track the restore run until it reports complete, then verify application and database data.

# Restore a specific backup to a service
bunx @temps-sdk/cli services restore \
  --id <service-id> \
  --backup-id <backup-id>

You can also initiate a restore from the web UI: open the service detail page, go to the Backups tab, and click Restore next to any listed backup.

What gets restored

Application data - All volumes and files
Database data - If using managed databases
Configuration - Environment variables and settings

What doesn't get restored

Deployment history - Previous deployments stay
Analytics data - Historical analytics preserved
Team members - User access unchanged

Backup best practices

Regular backups

Daily for production - Critical applications
Weekly for staging - Less critical environments
Before major changes - Manual backup before migrations
After deployments - Backup after successful deployments

Test restores

Regularly test your restore process:

# Restore a known-good backup to the staging service
bunx @temps-sdk/cli services restore \
  --id <staging-service-id> \
  --backup-id <backup-id>

# Verify data integrity
# Test application functionality

Backup verification

Temps computes a SHA-256 checksum after each upload and stores it with the backup record. If a backup fails or the checksum does not match on retrieval, Temps emits a failure alert so you can act before you need to restore. Periodic restore tests to a staging service are the best way to confirm full recoverability.

Disaster recovery

Recovery plan

Identify the issue - What data was lost?
Find the backup - Locate the right backup
Restore backup - Restore to staging first
Verify data - Check data integrity
Restore to production - Restore when verified
Monitor closely - Watch for issues

Recovery time

Backup retrieval - Seconds to minutes
Data restoration - Minutes to hours (depends on size)
Application restart - Minutes
Total recovery - Usually under 1 hour

Backup management

Manage schedules

Disable, enable, or delete a schedule

Three ways to do this

1
Open Project Settings and click the Backups tab.
2
Find the schedule you want to manage in the list.
3
Disable it to pause future runs, re-enable it to resume, or delete it to stop future runs (past backups remain in S3).
Checkpoint: Confirm the schedule's status reflects the change in the Backups tab.

# Disable a schedule (pauses future runs without deleting past backups)
bunx @temps-sdk/cli backups schedules disable --id <schedule-id>

# Re-enable a previously disabled schedule
bunx @temps-sdk/cli backups schedules enable --id <schedule-id>

# Delete a schedule (stops future runs; past backups remain in S3)
bunx @temps-sdk/cli backups schedules delete --id <schedule-id>

Access backup files

Individual backup files are stored directly in your configured S3-compatible bucket. To download or export a backup, access it through your S3 provider's console, CLI (aws s3 cp, mc cp, etc.), or any S3-compatible client using the credentials from your backup source.

For the step-by-step setup walkthrough, see Set Up Backups & Monitoring. For in-place restore, clone-to-new-service, and point-in-time recovery, see Restore & Recovery.

Backups

Ask anything