File storage for apps

Use managed project storage for uploaded documents, images, attachments and generated downloads. Never store bytes in localStorage, Git, SQL or a backend disk, and never encode files as base64 to move them through an API.

• The browser sends the file straight to a signed storage address. Your backend authorizes the user and handles metadata only.
• Routine operations use the storage HTTP API from the backend and need no workflow.
• A simple gallery can use the storage listing under a server-chosen user prefix as its index. Add relational metadata in PostgreSQL only when the product needs it.

For a new file app whose access rules are unspecified, ask one question: should files be private to signed-in accounts, or shared publicly? Use the answer to choose authentication and ownership. Do not build an anonymous gallery when privacy is undecided, and do not claim per-user privacy unless path and listing rules enforce it.

1. Authorize the user and derive a private prefix on the server, such as `users/<verified-user-id>/`.
2. Ask the backend for a signed upload address by sending the file name, byte size and content type. Never send the bytes.
3. Upload the raw browser `File` with `PUT` to the signed address, using the returned content type.
4. List the user’s prefix. A completed upload appears in the next listing; no completion endpoint is needed for a storage-indexed gallery.
5. Sign the visible page of files in one batch request and render the short-lived addresses. Reuse them until shortly before they expire.

Image galleries should accept displayable raster formats: PNG, JPEG, WebP, GIF and AVIF. SVG, HTML, JavaScript and XML files are stored as downloadable attachments rather than displayed inline.