# Storage and recovery

Source: https://docs.myhub.host/deploy/storage

## Keep data across deployments

Store files that must survive replacement in a **named volume**. Mount it at the path your app writes, as in the [Compose database example](https://docs.myhub.host/deploy/compose#a-database).

Do not rely on the container's writable layer for durable data.

New instances use an immutable instance ID for storage. Redeploying or rolling back the same instance keeps its volumes. Existing legacy instances keep their current volumes; they do not move to new storage on upgrade.

## Back up your data

Use your database's supported backup tool and store the backup outside the app. Test restoring it into a separate environment.

Hub does not automatically back up app volumes. RAM snapshots support suspension and resume; they are not backup history for recovering deleted or corrupted data.

## Understand what rollback restores

| State                 | After a release rollback         |
| --------------------- | -------------------------------- |
| App code              | Uses the selected earlier build. |
| Persistent data       | Keeps its current contents.      |
| Environment variables | Keeps current values.            |
| Process memory        | Starts fresh.                    |

Back up before destructive migrations. Keep code changes compatible with earlier data schemas when you need to roll back safely.

## Share a service

Give each app its own limited credentials. Before restarting or removing a shared service, check every app that depends on it. [Dependency-aware sleep](https://docs.myhub.host/deploy/runtime#shared-services) protects registered consumers; it does not replace backups or authorization.

## Remove an app

Stopping retains its data, and you can start the same instance again. Deleting removes the app or instance and its releases. For ordinary apps, deletion retains volumes by default unless you choose to delete data.

```sh
hub app my-app rm
hub app my-app/staging rm
```

The first command deletes the app and every instance; the second deletes only `staging`. Read the confirmation and the separate data-deletion prompt. In the dashboard, **Delete** retains volumes unless you select **Also delete the data**.

For scripts, `hub app my-app rm --yes` skips confirmation and retains volumes. `hub app my-app rm --delete-data` skips confirmation and deletes the target's volumes. Deleted volumes cannot be recovered through release rollback. Managed Workspace must be removed by Hub; its removal also deletes its data.

**Reusing a deleted app or instance name never restores its retained data.** A newly created instance gets separate volumes, even when its app and instance names match the deleted one. This also applies to names previously used by legacy instances.

The CLI and dashboard do not currently offer a restore operation for retained volumes. Retention is not a recovery workflow or a guaranteed retention period; keep independent backups. The long-term retain-versus-delete default, restore authorization, and retention policy remain product decisions.

[Delete command reference](https://docs.myhub.host/cli/app/rm)