Skip to main content
Standard S3 write operations land data on the bucket’s tape as certified tracks.
Writes need two things set up first: a SigV4 credential with write scope, and the bucket tape’s on-chain delegation to the gateway. Configuration covers both.

​
PutObject

A single-request upload. The gateway handles it one of two ways, depending on how your client sends the payload: signed-hash uploads are buffered and verified against the checksum before anything lands, while declared-size, chunked, and unsigned payloads stream with bounded memory. The ceilings are gateway configuration (256 MiB buffered, 5 GiB overall by default). What lands on-chain depends on size too: one track for objects up to 64 MiB, segment tracks plus a manifest for anything larger. Certified either way (how tracks work). Object keys follow the protocol’s naming rules, up to 1024 bytes (names). The gateway additionally rejects keys containing control bytes (below 0x20, or 0x7F), which keeps keys well-formed for standard tooling.

​
Multipart uploads

For large files and unreliable links: create the upload, send parts, complete. Each part is independently retryable, so a failed part re-uploads without restarting the whole transfer. Multipart state is store-backed and survives a gateway restart. An upload you started yesterday completes today. The S3-standard 5 MiB minimum part size applies (smaller parts return EntityTooSmall), and listing in-flight uploads and aborting both work.

​
Overwrites

Writing to an existing key is last-write-wins: a new track under the same name, with reads resolving to the latest write (objects). There is no versioning. The previous track still occupies capacity until you delete it (deletions).