Storage and recovery
Choose storage based on whether your data must survive a process restart, a new deployment, or a host failure. Each requires different protection. Persistent storage does not by itself provide a backup, a restore point, or high availability.
| Data | Where to keep it | Boundary |
|---|---|---|
| Application records | Managed Postgres or another database | A restart is different from restoring deleted or corrupt data. Test a separate export and restore path. |
| Cache and queue data | Managed Redis | Decide whether the workload can rebuild its state or needs its own recovery plan. Managed Redis has no eviction policy and no append-only file: if it runs out of memory, it restarts and recent writes can be lost. Keep data you cannot lose in Managed Postgres. |
| Files shared by applications | Managed Object Storage | The automatically created default bucket is private. Make a bucket public from the bucket browser in the dashboard only if anyone may read its files. |
Sandbox files follow other rules: only files on an attached Persistent Volume at /workspace, or in a snapshot you took, outlive a sandbox. See storage and billing.
Keep files after a sandbox ends
The Volumes page in the dashboard manages named volumes and their attachments. Attach a volume when creating the sandbox and write to /workspace. Stop the current sandbox before attaching the volume to another.
To keep a whole sandbox, memory included, save it with lizard sandbox snapshot <id> and start a copy later with lizard sandbox restore <snapshot-id>; see snapshots.
Restore a deleted resource
A deleted project stays in the trash for 3 days with its apps and databases, and so does a deleted database. Restore them in that time from Danger zone in the workspace or project settings; after that Lizard deletes them for good.
- An app you delete on its own goes to the trash only if you deployed it from files with
lizard up; restoring it rebuilds it from that upload. An app deployed from GitHub is deleted at once. - Sandboxes, their volumes and snapshots have no trash. Deleting them, or the project they belong to, removes them at once.
- Deleting a workspace has no trash either.
Plan a database restore
Before a migration or release that changes data:
- Choose an export method for the database and version in use.
- Store the export separately from the resource being changed.
- Restore into a separate test database and verify the application can read it.
- Record the restore duration and the latest data included in the export.
Do not assume scheduled backups, point-in-time recovery, multi-node replication, or a restore-time guarantee from a database being managed. Confirm the current service agreement and available controls for your resource.
Environment references
An application should read its database connection from an environment reference. A connection string is a credential; avoid printing it to verify an update. A connection check such as SELECT 1 proves more than seeing the variable in a shell.
Related guides
Updated