Choosing container storage

Your container can write to two kinds of storage, and the difference matters: one is fast local scratch space that is wiped whenever a replica restarts, the other is durable and survives restarts, redeploys, and rescheduling. Picking the right one comes down to a single question — does this data need to outlive the replica that wrote it?

Updated 3 Aug 20263 min read

The two options at a glance

	Ephemeral storage	Persistent storage
Survives a restart?	No	Yes
What it is	Fast local scratch space	Replicated block SSD, kept in three copies
Attached	Automatically, to every replica	You define named volumes and mount paths
Works with autoscaling?	Yes	No — fixed replica count required
Good for	Temporary files, buffers, `/tmp`	Databases, uploads, state you must keep
Billing	First 3 GB free, then per GB per month	Per GB per month, per replica

Ephemeral scratch space

Every container ships with a small amount of fast, local scratch space with no setup required — you write to the container's filesystem and it lands here. It is the right home for anything temporary: files written while a request is in flight, cached build artefacts, upload buffers you then push elsewhere, or anything you would have written to /tmp.

The catch is in the name. Ephemeral storage lives only for the lifetime of the replica. When a replica restarts, scales away, or is rescheduled, everything in its ephemeral storage is gone. That is by design — the trade-off for its speed is that it is not durable. Because it is discarded on restart, it works fine with autoscaling.

See Ephemeral storage for sizing and the exact free allowance.

Replicated persistent volumes

Persistent storage gives your container a place to keep state that survives restarts, redeploys, and rescheduling. Each volume you define has a name, a mount path inside the container, and a size, and the platform keeps every byte in three independent copies so a single disk failure cannot take your data offline.

Reach for it when losing the data would be a problem: a database's data directory, uploaded files you have not yet moved to object storage, or any state your application must retain across restarts.

Two things to keep in mind:

Each replica gets its own independent copy of every volume, and you pay for each. Two replicas with a 10 GB volume means two 10 GB volumes.
Persistent volumes cannot be combined with autoscaling. Scaling up would create new volumes and scaling down would destroy data, so a container with persistent volumes runs at a fixed replica count.

Volumes are deleted with the container, with no recovery period — back up anything important to an external service before terminating. See Persistent storage for volume sizing, mount-path conventions, and per-replica billing.

Which should I use?

Ask what happens if the data disappears when a replica restarts:

No problem — use ephemeral scratch space. It is free up to the included allowance, fast, and works with autoscaling.
That would lose something important — use a persistent volume, accept a fixed replica count, and back up anything you cannot recreate.

Many containers use both: ephemeral scratch for temporary working files, and a persistent volume for the state that has to stick around.

Sizing and cost

Both kinds of storage are billed. Ephemeral storage includes a free allowance and charges per GB per month beyond it; persistent storage is charged per GB per month for every replica, reflecting the three-copy replication. Start small in both cases and increase only when you need to — you pay for what you allocate, and the Console shows the full cost preview before you save. For how storage fits into your overall bill, see how billing works.