alawadi.cloudDocs

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.

On this page