Small values.Right where your app needs them.

Use KV when a value has a name and you want to retrieve it directly: a feature flag, a cached response, a small configuration object or an expiring session value. A Fortly project has its own key-value store, organized into namespaces. The Worker binding, management API and console all reach the same values, so investigating a saved flag does not require guessing which service or account holds it.

A Worker declares kv_namespaces in its wrangler configuration. Its binding is the name used on env; the namespace is named by the config’s id. Bindings that name the same namespace inside one project share those keys. Another project has its own store, even when its namespace has the same name. Existing Cloudflare namespace data is not copied by deploying the configuration.

Writes are visible on the next read. This is different from a store with a propagation delay, but it does not make a read followed by a write an atomic transaction. Use PostgreSQL when you need relational constraints, coordinated updates or queries across records. Keep KV for workloads that fit independent named values, and protect any session or security decisions in your application code.

Open Storage, choose Key-value, then select a namespace and key. The value inspector keeps saved content, size, JSON metadata and expiry together. Text values and metadata can be edited in the same save. Revert discards the local draft. Switching keys, namespaces or Storage tabs asks before discarding unsaved edits, so an investigation can become an edit without silently losing the change.

Keys are limited to 512 UTF-8 bytes, values to 1 MiB and JSON metadata to 1,024 bytes. The console validates byte length rather than assuming a character always takes one byte. Add key accepts a namespace, value, optional expiry and optional metadata. It checks for an existing key and directs you to edit it; the underlying API still uses last-write-wins semantics rather than atomic create-if-absent.

Editing preserves the existing expiry. Because writes require at least 60 seconds of remaining lifetime, saving a key in its final minute is refused rather than accidentally turning it into permanent data. Wait for expiry or use a separate key if that suits the application. A failed read offers Retry, and an accepted save followed by a failed readback explains that the write succeeded.

Worker code can get text, JSON, an ArrayBuffer or a stream, read metadata, put a value with expirationTtl or expiration, list by prefix and delete keys. Bulk get accepts up to 100 keys. Prefix search in the console helps you inspect a naming convention such as customer: or feature: without loading unrelated values. List pagination remains scoped to the namespace you selected.

The project’s binding inventory links straight to the matching namespace, and the Storage workspace offers a copyable configuration example. Programs outside the Worker can use the documented KV API with an account token kept on the server. Never place an account token in browser code merely to make a key-value request work; it carries administrative account access.

KV namespaces are separate from the project’s PostgreSQL database. Managed point-in-time recovery does not rewind them. Deleting the project deletes its keys, and clearing a namespace or deleting a key has no Undo. Store larger objects in Files or an R2-compatible bucket, and decide what application data must be durable, reconstructable or exported before using a cache as a source of truth.

Open the detailed guide for configuration examples, access requirements, limits and troubleshooting. Then use your own project to verify the full flow before depending on it in production.

Read the KV guide · Explore the full platform