Skip to main content
Every environment has its own backups. They come in two flavors — automatic pre-merge snapshots taken before each merge, and manual snapshots you take on demand. Either kind can be restored into any target, including a new environment that takes over the original’s name if it was deleted.

​
Backup types

Both kinds are full backups — schema and data. There’s no incremental or schema-only mode.

​
What’s in a backup

​
Taking a manual backup

1

Switch to the environment you want to back up

Use the environment switcher at the top of the project chrome.
2

Open Backups

From the switcher dropdown, open the Backups view.
3

Click Create backup

The backup runs as a background job. The status moves through pending → running → completed.
4

Optionally name the backup

Add a label like pre-stripe-migration or release-v2 to make the snapshot easy to find later.
The backup appears in the list with its type (Manual), the user who created it, the timestamp, and the size.

​
Restoring a backup

A restore reverts the entire environment — schema and data — to the snapshot point. It’s not a per-change undo.
1

Find the backup

In the Backups view, locate the entry to restore. Pre-merge backups are linked from the corresponding history entry.
2

Pick the target environment

By default, restoring puts the snapshot back in the same environment it was taken from. You can also restore into a different environment — including a new environment that takes over a deleted one’s name (see below).
3

Confirm

The platform locks the target, drops its current state, and replays the backup. The status transitions through restoring and back to active when complete.
A restore replaces the target environment’s contents. Anything written to the target after the backup was taken is gone. If you might need that recent data, take a fresh manual backup of the current state first.

​
Restoring to a deleted environment

A backup outlives its environment — even if you delete feature-x, its backups stick around through the retention window. To restore them, the platform recreates the environment as part of the restore:
1

Find the backup

Backups for deleted environments are still listed in the project’s Backups view, with their original environment name shown.
2

Restore

Click Restore. If no environment with that name currently exists, the platform recreates the environment as part of the operation. The new environment inherits the backup’s schema, data, and configuration.
3

Reconfigure secrets

Auth provider secrets and OAuth credentials are not in the backup — re-enter them in the recreated environment before exposing it.
This is the recovery path when a deleted environment turns out to have held a critical migration or test fixture you need back.

​
Pre-merge backups in the merge flow

Every merge automatically produces one pre-merge backup on the target. The backup ID is recorded in the history entry alongside the merge — you don’t have to hunt for it. Common pattern: after a merge into master, if a regression surfaces, open History → find the merge → follow the backupId to the Backups view → restore.

​
Retention

Backups are retained for a configurable window per project. Once a backup ages out, it’s pruned and can no longer be restored. Manual backups can be marked retain forever to opt them out of pruning — useful for capturing release-train snapshots that you want to keep indefinitely. If you need a long rollback window for a specific merge, promote its automatic pre-merge backup to a retained manual backup before the retention window expires.

​
Permissions

Creating, listing, and restoring backups is governed by Role-Based Access. Restore is destructive — typically restricted to admin or operator roles. Read access can be granted more widely if you want broader visibility into snapshots without the ability to restore.

​
FAQ

No. The backup captures the file storage provider configuration and the references records hold to files (file IDs, paths). The actual blobs stay in the configured object store. Treat your storage provider’s own snapshot/versioning as the source of truth for file content.
Backups are full — schema and data. For schema-only operations, use the diff and merge tools, or branch a new environment in System mode.
The target is locked while the restore runs. Reads continue from the existing data until the restore completes; mutations are rejected with the environment-locked error. Once complete, the target reflects the snapshot’s state and reopens for writes.
No. Backups are project-scoped — they reference project-specific identifiers (auth keys, project ID, RBAC role IDs) that don’t translate across projects. To clone a project, branch within it.
The target stays in error state with a failure reason recorded. The platform doesn’t automatically partial-restore — either the backup applies cleanly or the environment is left as it was, in error. Recovery is to run the restore again, or restore a different snapshot.