Persistent Block Storage
Persistent block storage gives your services durable, network-attached volumes. Files, uploads, and application state live on volumes that move with your service — if a node goes down, your data automatically follows to a healthy node.
How it works
Block volumes are network-attached Hetzner volumes formatted with ext4. They’re mounted into your service’s container at a configurable path. The volume persists across:
- Redeploys — your data is still there after a new version is deployed
- Node failures — the volume detaches from the failed node and reattaches to the new one automatically
- Container restarts — data survives crash recovery
Adding persistent storage
- Open your service detail page
- Go to Settings
- Enable Persistent storage
- Set the mount path (e.g.
/app/uploads,/data) - Choose the volume size
- Click Save
The volume is provisioned and mounted at the specified path. Your service is redeployed to pick up the new volume.
Mount path
Volumes are mounted at /mnt/block/{volumeName} by default, but you can configure a custom mount path in your service settings. Common paths:
/app/uploads— user-uploaded files/app/data— application state/app/storage— general-purpose storage
Volume sizes
| Plan | Maximum volume size |
|---|---|
| Starter | 1 GB |
| Pro | 10 GB |
| Business | 100 GB |
| Enterprise | 100 GB |
Resizing
Grow your volume without downtime:
- Go to the service Settings
- Increase the volume size
- Confirm the resize
- The volume is resized and the filesystem is expanded automatically
Automatic failover
When a compute node fails:
- The volume detaches from the failed node
- Stackpad provisions or selects a healthy node
- The volume attaches to the new node
- Your service restarts with the data exactly where you left it
This happens automatically — no manual intervention needed.
What persistent storage is NOT for
Databases and caches don’t use block storage — they have their own backup and recovery systems (WAL archiving, scheduled dumps, RDB snapshots). Block storage is designed for:
- User uploads and media files
- Application state and config files
- Build artifacts and generated content
- Any data your web app writes to the filesystem
For file storage accessible via API (S3-compatible), use Object Storage instead.
What’s next?
- Object storage — S3-compatible file storage
- Backups — database backup and restore
- Architecture — how Stackpad handles node failures