Storage Billing

Storage is charged for the data you keep beyond the shared template image. Creating more sandboxes from the same template does not mean paying for another full copy of that image each time. See the current storage rate.

What you pay for#

• Your incremental filesystem data: changes such as project files, installed dependencies, and other writes beyond the template's shared base image.
• Data you choose to retain in snapshots: unchanged data shared with the sandbox or another snapshot is counted once within your team.
• Saved memory state: a retained memory checkpoint when you use memory pause/resume. The configured running RAM limit is a separate compute measure; it is not automatically charged again as stored memory.

A fork starts by sharing the source's saved data. Within your team, creating a fork or snapshot does not charge for a second full copy of that shared data. New writes add storage as the copies diverge.

What Sandbox0 pays for#

Shared base images, internal recovery checkpoints, platform maintenance copies, object-store version history, and data awaiting background cleanup are platform costs. You do not pay extra because Sandbox0 keeps recovery data or takes time to reclaim physical storage. Compression, encryption, and internal indexing overhead are also excluded from billable RootFS storage.

A concrete example#

Suppose you create 100 sandboxes from one template with a 1 GiB base image, and each sandbox retains 100 MiB of its own changes:

You pay for about 9.77 GiB, not 110 GiB. Multiply that by the storage rate shown on Pricing for a full storage month. Shared snapshot/fork data is counted once; snapshots that retain additional older changed data add only that retained data. Saved memory checkpoints, if present, also add storage.

You control how long data stays billable#

Pausing stops compute charges and keeps your data, so retained storage continues to accrue. Resuming does not create a second billable copy of the same saved filesystem. Storage is prorated by the time you retain it, using a 730-hour storage month; there is no full-month storage minimum.

Delete sandboxes you no longer need, and delete or expire snapshots you no longer want to keep. Billing stops for data when its last user-owned reference is released, without waiting for physical cleanup. A snapshot or fork can keep data billable after the original sandbox is deleted because you still retain that data there.

The storage quantity reflects persisted changed filesystem blocks rather than the provisioned disk capacity or just the sum of visible file sizes. RootFS data is measured before compression; it is not charged according to how well a file compresses. Storage usage can appear after the persisted usage is processed; processing delay does not extend your retention time.

Read Pause And Resume and Snapshot And Restore for lifecycle controls.