File Snapshots and Rollback
How each production deploy stores a full file snapshot for rollback.
Every production deployment records the complete source of every project file at the time of deploy. This snapshot is stored in the deployment_files table alongside the built assets in R2. Snapshots enable rollback without rebuilding from the current editor state.
What a Snapshot Contains
A snapshot is a set of rows in deployment_files, one per project file. Each row stores:
| Field | Description |
|---|---|
path | File path relative to project root |
content | Full source text of the file |
size_bytes | File size at time of deploy |
deployment_id | Which deployment this snapshot belongs to |
project_id | Owning project |
The snapshot captures the file content as it existed when the deploy was triggered. Subsequent edits in the editor do not affect existing snapshots.
How Rollback Works
Rolling back to a previous version follows this sequence:
- Select a version in the Version History panel.
- Click Restore. Odyn reads the snapshot rows for that deployment.
- The snapshot files are written back into the editor, replacing the current working files with the source from that deployment.
Restore updates the editor file state only. It does not create a new CDN deployment, increment the version number, or update the @latest alias. To publish the restored files to the CDN, deploy again after restoring.
Snapshots vs R2 Bundles
Snapshots and R2 bundles serve different purposes:
| Aspect | Snapshot (deployment_files) | R2 bundle |
|---|---|---|
| Contains | Source files (pre-build) | Built output (post-build) |
| Purpose | Rollback, diff, audit | Serve to browsers via CDN |
| Stored in | Supabase (Postgres) | Cloudflare R2 |
| Immutable | Yes (never modified) | Yes (versioned path) |
Both are created on every production deploy. The snapshot preserves what you wrote. The R2 bundle preserves what the CDN serves.
Why Store Source, Not Just Bundles
Storing source files enables:
- Diff between versions: Compare file-by-file changes between any two deployments.
- Rebuild flexibility: If the build pipeline changes (new esbuild version, different minification settings), restoring from source produces output consistent with the current pipeline.
- Editor preview: View historical deployments in the editor as read-only snapshots without affecting the working file tree.
If only built bundles were stored, rollback would require serving potentially outdated build artifacts, and file-level diffing would not be possible.
Snapshot Lifecycle
Snapshots are created automatically on every production deploy. They are not created for staging deploys (staging is for iteration, not archival).
Snapshots are retained for the lifetime of the deployment record. Deleting a project cascades to its deployments, which cascades to their snapshots.
There is no manual snapshot creation or deletion. The system creates one snapshot per production deploy, and that snapshot remains available as long as the deployment exists.
Implications for Rollback
- Restore is always available for any production version whose deployment record exists.
- Restoring replaces the current editor files with the snapshot source. Your unsaved edits will be overwritten.
- Restore does not affect the CDN. The production output remains unchanged until you deploy again.
- After restoring, you can review the files in the editor, make additional changes if needed, and deploy when ready.
Related
- Restore and Production Deploys for the step-by-step workflow.
- Version History for navigating the deployment timeline.
- Immutable Bundles for why R2 bundles are never overwritten.
- Deploy Model for the full build pipeline.