Guides

Backups

Nightly encrypted backups of every project, and how to restore one into a new project.

Every project on a Starbase with backups configured is backed up automatically every night. Each backup is encrypted with a key that is separate from the one that protects your secrets, and stored in a bucket on a different host than the project's own storage. The project Overview shows the last backup, and the Databases page lists the recent ones.

What a backup includes

  • Every database of the project (a full pg_dump), including your app's Robodev Auth users and queued jobs, which live in the project database.
  • Every storage object, with its key, public flag and content type. Objects that did not change since the previous night are not copied again.
  • Project settings: Robodev Auth, password protection, email settings and templates, push settings.
  • Secrets and AI provider keys (still encrypted), members, the agent workspace and the latest deployment's files.

What is not included

  • The Robodev URL (slug) and custom domain: a domain stays on the source project.
  • Deploy keys, deploy claims, pairings and pending invites.
  • Request logs, metrics, deploy history beyond the latest deployment, push devices, agent sessions, security reviews, repository links and artifacts.
  • Backups of a deleted project are kept for up to 12 months but cannot be restored from the dashboard or CLI.

Retention

Starbase keeps the newest backup of each of the last 7 days, of each of the last 4 weeks and of each of the last 12 months, plus the newest backup of every existing project. Older backups are deleted automatically. Every week one random backup is restored into a scratch database to prove it can be restored.

List backups

terminal

robodev backup list

Prints the recent backups with their id, start time (UTC), age, size, status and databases. Any project member or a deploy key can list. The Databases page shows the same list with a copyable restore command per backup.

Restore a backup

terminal

robodev backup restore bkp_abc123 --into my-app-restore

A restore always creates a NEW project in the same organization and never changes the source project. It needs a signed-in project admin or organization admin (robodev auth); a deploy key is refused. The command waits and prints each step, then the new project's id and URL. Run robodev link <newProjectId> in a folder to work on the copy. --no-wait returns the restore id at once.

  • Databases, storage, settings, secrets, members and workspace files are restored, then the latest deployment is redeployed. If only that redeploy fails, the data is kept and the restore reports a warning; run robodev deploy.
  • If anything else fails, the half-restored project is deleted and the restore reports the error.
  • Retention can delete an old backup while it is being restored (it was the oldest of its week or month). The restore then fails, the half-restored project is deleted, and you can restore a newer backup instead.
  • The new project gets a new id and default URL. You become an admin of it if you are not an organization admin.

Secrets after a key change

Secrets are restored as stored, still encrypted. If the Starbase's secret encryption key changed since the backup was taken, encrypted values cannot be read: the restore skips secrets, AI keys, the Apple private key and push credentials, restores everything else, and lists what it skipped. Set them again with robodev secrets set (and re-enter Apple and push credentials on the project's settings pages).

The same operations are available over MCP: list_backups, restore_backup and get_backup_restore, in robodev mcp and the hosted Robodev connector, with the same permissions.