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 outlive a sandbox. See storage and billing.
Keep files after a sandbox ends
The Persistent Volumes tab 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.
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