Storage resources

How KV, D1, R2, and queue stores get their stable ids, and the three ways to attach one.

KV, D1, R2, and queue stores are account-level resources with a stable <kind>_<id>. There are three ways to attach one.

Bare name, let deploy provision it

"kv_namespaces": ["SESSIONS"]

On deploy, the CLI creates a resource named <project>-sessions, writes { "binding": "SESSIONS", "id": "kv_..." } back into sproutboat.jsonc, and uses it. This is the default. The store then survives redeploys, and another project can bind the same id.

Create it yourself, then reference the id

bunx sproutboat kv create shared-sessions
# prints kv_a1b2c3d4...

npx sproutboat kv create shared-sessions
# prints kv_a1b2c3d4...

"kv_namespaces": [{ "binding": "SESSIONS", "id": "kv_a1b2c3d4..." }]

Use the same id from two projects to share the store.

`deploy --no-provision`

A bare name then gets an ephemeral store scoped to that one deployment; it is discarded on the next deploy. Use it for throwaway tests.

Managing resources

bunx sproutboat kv list
bunx sproutboat d1 list
bunx sproutboat r2 list
bunx sproutboat queues list

npx sproutboat kv list
npx sproutboat d1 list
npx sproutboat r2 list
npx sproutboat queues list

Analytics Engine datasets are the exception: they are not provisioned and have no id, appearing on first writeDataPoint.

KV data management and export
CLI reference — kv, d1, r2, queues commands