Block volumes (coming soon)
Preview the planned persistent-disk product and its attachment model. Block-volume creation and billing are disabled today.
Not available yet
Block-volume creation and metering are disabled in production. The API returns
BLOCK_VOLUME_DISABLED. There is no live customer price. This page documents
the staged interface so developers can plan; it does not announce an available
product.
The planned block-volume product is a standalone persistent disk. Unlike a bucket, it holds no objects of its own and has no S3 endpoint — it is a raw filesystem mounted into one app at a path you choose.
Planned creation flow
When enabled, the dashboard flow will let you choose New volume, give it a name, and pick a size in GB (1 GB to 16 TB). The platform will provision the disk and book its capacity from the regional pool. A new volume will still need to be attached before an app can use it.
Planned attachment model
The staged interface attaches a volume to exactly one container, web, or
worker app, at a mount path you choose (for example /data). This is a
ReadWriteOnce disk:
- It can be attached to at most one app at a time.
- That app must run at most one replica. A ReadWriteOnce disk cannot be mounted by two running copies of the same app at once, so scaling an attached app beyond one replica is not available — if you need more compute, scale vertically (larger reserved CPU/memory) rather than adding replicas.
When the product is enabled, attaching will restart the app so the mount takes effect; detaching will do the same in reverse. Detaching will leave the volume itself untouched so it can be re-attached or deleted later.
One path, one volume
An app can only have one volume at a given mount path. Attaching a second volume at the same path a container already uses is rejected — detach the existing one first, or pick a different path.
Planned mount path
Whatever path you choose becomes an ordinary directory inside your app's filesystem: read and write it like any other local path. Your app's root filesystem is otherwise read-only, so the mount path is the one place your code can persist state to disk between restarts.
Planned resizing
The staged API only supports growing a volume. A future resize will remain subject to regional capacity, and shrinking will require creating a smaller volume and moving the data.
Planned durability model
The launch target is a replica-3 storage class. That is an implementation target, not a customer durability commitment today. It becomes a published commitment only after the storage class is enabled, all replica placements are healthy, and the launch node-loss drill has passed.
Planned deletion behavior
Detach first
A volume cannot be deleted while it is still attached to an app — detach it first. This protects a running app from suddenly losing a mount it depends on.
The staged contract permanently deletes a detached volume and its contents, without a retention window or recovery. If that contract ships, you will need to copy required data elsewhere before deletion.
Pricing status
There is no live block-volume price. The internal rate-card entry is dormant and still requires founder approval. The public rate and billing example will be added only when the product passes its launch gates. No block-volume charge occurs while creation and metering remain disabled.