Storage

Files live in buckets. An app can have several, each provisioned from the console and addressed by its own uid.

Buckets

Create a bucket in the app's Storage section. Several buckets per app is the normal case — separating public assets from private uploads means you can grant access to one without the other.

How many buckets you may create is a plan limit.

Uploading and downloading

Uploads are multipart requests. Downloads stream back through the API rather than from a direct object URL, so policy is checked on the way out instead of being bypassed by a link.

File metadata lives in ordinary tables — storages, storage_files, storage_folders — so listing and searching files uses the same query API, and the same policies, as everything else. See the API Reference.

Where the bytes go

A bucket is backed either by local disk or by S3, chosen when it is provisioned. That choice is invisible to your application: the API is identical either way, so moving from local development to S3 in production changes configuration, not code.

Governance

Storage is not a side door. Reading a file is authorized exactly as reading a row is, and a file an agent may not read is one it cannot fetch through any of its three doors.

In a policy, your users' file access is three switches under People using the app: Read files, Upload files and Delete files. Downloading and uploading are granted separately, so you can let users fetch files without letting them add any. To limit a user to their own files, add the isOwner condition in the policy's advanced view to the actions that name one file (storage:read, storage:update, storage:delete). Don't add it to the listing actions: a listing names no single file, so isOwner would refuse it outright.

Next