g7 Limitations
These are the current boundaries of what g7 can do.
Upload size
100 MiB per PUT. A single put() call (or PUT through the management proxy) cannot exceed 100 MiB. Larger objects are not supported — there is no multipart upload.
Unsupported features
No multipart upload. Objects must be uploaded in a single request. Chunked or resumable uploads are not available.
No conditional writes. There is no If-None-Match or If-Match semantics on put(). Last write wins.
No object versioning. Overwriting an existing key replaces it permanently. There is no version history or soft-delete.
No list delimiter. list() does not support a delimiter parameter for simulating a directory hierarchy. Use prefix filtering and parse paths in application code.
No custom metadata. Objects store a content type (the contentType option on put()) but no arbitrary key-value metadata and no stored Cache-Control — set caching headers when you serve the object.
No server-side copy. There is no copy or move operation. To copy an object, read it and write it under the new key.
Access
Buckets are private by default. A Cell binding is the primary access path, but it is not the only one. For access from outside a Cell, three mechanisms exist:
- Public-read buckets —
ribo bucket create <name> --public(orribo bucket set <name> --public) allows anonymousGET/HEADon a bucket's objects. Listing and writes are never public. - Pre-signed URLs — short-lived signed URLs for a single upload or download, minted via the management API (
POST /v1/buckets/:bucket/presign). - S3-compatible endpoint —
https://g7.tissue.systemsaccepts SigV4-signed requests with per-bucket credentials, so external tools and standard S3 clients can read and write directly.
See Managing Buckets for details.