File storage

GET /v1/orgs/{orgSlug}/projects/{projectName}/storage

Whether storage is enabled, plus the prefix, quota and usage (docs/storage.md §7·§8). usedBytes is the last value the node reported, so it lags by one reporting interval — usage can go slightly over quota in between.

Object listings and signed URLs are not part of this API. The credentials live only in node-agent (§4.1), and not sending the bytes through CP twice is the decision in §5.

Requires viewer or above.

operationId getStorage

POST /v1/orgs/{orgSlug}/projects/{projectName}/storage

Idempotent — calling it twice leaves the prefix unchanged. If a retry changed the prefix, every object already stored under it would become invisible, and that loss would not show up immediately.

There is no request body. The prefix is the isolation boundary (docs/storage.md §4.4) and the quota is set by the plan (§4.5), so neither is a value the user chooses.

Once the grant is complete the node binds env.storage to the worker at the next convergence. As with env.db, no redeploy is needed.

Requires member or above. Audit storage.grant.

operationId grantStorage

DELETE /v1/orgs/{orgSlug}/projects/{projectName}/storage

Objects are not deleted. Deleting everything under the prefix has to be a CP operation made idempotent by op_id (docs/storage.md §7, the same lane as database deletion), and that lane does not exist yet — the audit record says so.

Turning it off is idempotent too. It returns 204 even when auth was never enabled.

Requires admin or above — billing stops but the objects are orphaned, so this is not treated at the same level as a deploy rollback. Audit storage.revoke.

operationId revokeStorage