Storage resources
How KV, D1, R2 and queue stores get their stable ids, and the three ways to attach one.
KV namespaces, D1 databases, R2 buckets and queues are account-level resources with a stable id of the form <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 after the project and binding (<project>-sessions), writes { "binding": "SESSIONS", "id": "kv_..." } back into sproutboat.jsonc, and uses it. This is the default. The store 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 a throwaway store for that one deployment, discarded on the next deploy. Use it for tests.
Managing resources
bunx sproutboat kv list
bunx sproutboat d1 list
bunx sproutboat r2 list
bunx sproutboat queues listnpx sproutboat kv list
npx sproutboat d1 list
npx sproutboat r2 list
npx sproutboat queues listAnalytics Engine datasets work differently: they take a bare name only and exist from their first writeDataPoint.
Related
- KV data management and export
- CLI reference: the
kv,d1,r2andqueuescommands