---
title: Storage resources
description: "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

```jsonc
"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

<CodeGroup>

```sh Bun
bunx sproutboat kv create shared-sessions
# prints kv_a1b2c3d4...
```

```sh npm
npx sproutboat kv create shared-sessions
# prints kv_a1b2c3d4...
```

</CodeGroup>

```jsonc
"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

<CodeGroup>

```sh Bun
bunx sproutboat kv list
bunx sproutboat d1 list
bunx sproutboat r2 list
bunx sproutboat queues list
```

```sh npm
npx sproutboat kv list
npx sproutboat d1 list
npx sproutboat r2 list
npx sproutboat queues list
```

</CodeGroup>

:::warning
A resource cannot be deleted while a deployment still binds it.
:::

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

## Related

- [KV data management and export](/storage/manage-kv-data)
- [CLI reference](/reference/cli) — `kv`, `d1`, `r2`, `queues` commands