Skip to content

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

  1. Open your service detail page
  2. Go to Settings
  3. Enable Persistent storage
  4. Set the mount path (e.g. /app/uploads, /data)
  5. Choose the volume size
  6. 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

PlanMaximum volume size
Starter1 GB
Pro10 GB
Business100 GB
Enterprise100 GB

Resizing

Grow your volume without downtime:

  1. Go to the service Settings
  2. Increase the volume size
  3. Confirm the resize
  4. The volume is resized and the filesystem is expanded automatically

Automatic failover

When a compute node fails:

  1. The volume detaches from the failed node
  2. Stackpad provisions or selects a healthy node
  3. The volume attaches to the new node
  4. 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?