resources.storage needs no configuration. Each namespace is a directory under:
Objects reach it the way SQL reaches a database: the guest holds no bucket, path, or credential and sends each operation across its private link under the deployment’s workload token, which the control plane resolves to exactly one namespace.

​
Writes are atomic

Writes are staged under $TINY_DATA_DIR/storage/.staging and renamed into place, so a reader sees either the previous object or the new one — never a partial file.
That staging directory sits beside the environment directories rather than inside a namespace, which keeps a half-written object out of listings and out of quota accounting.

​
Platform limits

An operator does not configure these, but should know them: A manifest’s maxSize is the per-namespace quota on top of those. It is measured against the namespace as it will be after the write, so replacing an object does not charge for the copy it replaces. Exceeding it is a RESOURCE_LIMIT_EXCEEDED refusal, never a truncated write.

​
Two body-size limits, not one

The single-host nginx configuration sets client_max_body_size 20m, which bounds what a browser can upload through an app.The app’s own writes to storage go over the private link and are bounded by the 32 MiB object limit instead. These are different limits on different hops — raise the nginx one if you want larger browser uploads.

​
Metering

Bytes moved are metered as storage_bytes, split into reads and writes by the operation field on each usage record.

​
Durability

Objects live on the control-plane host’s disk. They are not replicated, and snapshots are sibling directories on the same filesystem — so a lost disk loses them along with any SQLite database beside them.Back up $TINY_DATA_DIR as one unit. See Backups.
An S3/R2-backed ObjectStore is the intended replacement. Because storage sits behind one interface, swapping it means implementing that interface rather than changing anything an app sees. It is not implemented in this repository.

​
Retention is recorded, not enforced

retention on a storage declaration describes how long deleted objects are kept for recovery. It is recorded on the claim and is not yet enforced by a reaper — do not plan capacity around it reclaiming space.