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
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
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.