Storage

Each project gets isolated object storage. Keys are tenant-relative — you see uploads/report.pdf, never a shared global namespace — and one project can never address another’s objects. Bytes move through short-lived signed URLs, so large uploads and downloads never proxy through the API.

CLI

korve storage upload ./report.pdf                 # content type guessed
korve storage list --prefix uploads/
korve storage download uploads/report.pdf -o ./report.pdf
korve storage delete uploads/report.pdf

The signed-URL flow (API / MCP)

Uploading is two steps — create the signed upload, then PUT the bytes:

curl -X POST "https://api.korve.dev/v1/orgs/$ORG_ID/projects/$PROJECT_ID/storage/uploads" \
  -H "Authorization: Bearer korve_..." \
  -H "Content-Type: application/json" \
  -d '{"filename": "report.pdf", "contentType": "application/pdf", "byteLength": 24576}'
# → { "key": "uploads/report.pdf", "url": "...", "method": "PUT",
#     "headers": { ... }, "expiresAt": "..." }

curl -X PUT "<url>" -H "Content-Type: application/pdf" \
  --data-binary @report.pdf    # include any returned headers verbatim

byteLength must match the upload exactly, and the URL expires quickly — mint it right before sending. Downloads mirror the shape: POST .../storage/downloads with {"key": "..."} returns { url, expiresAt }. Over MCP, use the method and path returned by search:

const upload = await korve.request({
  method: "POST",
  path: `/v1/orgs/${orgId}/projects/${projectId}/storage/uploads`,
  body: { filename: "report.pdf", contentType: "application/pdf", byteLength: 24576 },
});

Full contracts in the Storage API.

From a deployed server

@korve-dev/sdk uses the injected runtime capability to mint the same short-lived upload and download grants without an organization key:

import { createKorve } from "@korve-dev/sdk";

const media = createKorve().storage("media");
const upload = await media.createUpload({
  filename: "avatar.png",
  contentType: "image/png",
  byteLength: bytes.byteLength,
});
await fetch(upload.url, {
  method: upload.method,
  headers: upload.headers,
  body: bytes,
});

The platform fixes project and environment server-side. A named bucket must already be visible to that project, and its object keys receive a private project/environment prefix. Runtime code cannot list or delete objects. Grants expire after ten minutes; treat the bearer and signed URL as secrets and never persist or log them.

Deleting objects

Deletes are idempotent. Over the raw API the key travels as a single URL-encoded path segment (/ becomes %2F):

DELETE /v1/orgs/{orgId}/projects/{projectId}/storage/objects/uploads%2Freport.pdf

The CLI handles encoding; MCP code should URL-encode the key path segment.

Roles and billing

Listing and downloading need member; creating uploads requires active billing; deleting requires admin. Storage meters storage.objects per GB-month. Direct signed-download bytes are not yet exposed as a separate customer usage line. Read the current public amounts and available meters from billing.get; see budgets and usage.

Start

Core concepts

Agents

Build

Data and work

Operate

CLI reference

API reference

CLI

The signed-URL flow (API / MCP)

From a deployed server

Deleting objects

Roles and billing

​CLI

​The signed-URL flow (API / MCP)

​From a deployed server

​Deleting objects

​Roles and billing

CLI

The signed-URL flow (API / MCP)

From a deployed server

Deleting objects

Roles and billing