Deno Kv

Deno Deploy access token: Authorization: Bearer {access_token}. Tokens from Deno Deploy Dashboard → Account → Access Tokens. KV database ID from Deno Deploy Dashboard. HTTPS enforced. No OAuth2. KV databases isolated per Deno Deploy project. Local Deno runtime: kv.openKv() without auth — stored in local SQLite. Deno Deploy: each deployment gets access to its project's KV database via Deno.openKv().

Deno KV is the built-in persistent storage primitive for Deno runtimes and Deno Deploy. In Deno code: const kv = await Deno.openKv(); kv.set(["users", userId], userData); kv.get(["users", userId]). Outside Deno: the HTTP REST API at kv.deno.io enables any HTTP client to read/write KV entries using a Deno Deploy access token. Strong consistency: reads reflect the most recent write globally. Atomic transactions: commit multiple mutations atomically with compare-and-swap. Queue primitives: enqueue/listenQueue for background job patterns. Key hierarchy: array keys enable natural namespacing and range queries. Good fit for agents needing persistent state in Deno-based workflows. Confidence is docs-derived.

HTTP API at https://api.deno.com/databases/{kv_id}/datapath (for external access). Auth via Deno Deploy access token. Operations: POST /snapshot_read (batch key reads), POST /atomic_write (atomic mutations: set, delete, check). Native Deno API: const kv = await Deno.openKv(); await kv.set(key, value); const {value} = await kv.get(key); await kv.delete(key). List: for await (const entry of kv.list({prefix: ["users"]})) {...}. Atomic: kv.atomic().check({key, versionstamp}).set(key, newVal).commit(). Queue: kv.enqueue(msg, {delay}); kv.listenQueue(handler). Watch: kv.watch([key]) for real-time change notifications.

Strong consistency: writes are immediately visible globally after commit. Atomic transactions: all operations in a transaction succeed or all fail (compare-and-swap semantics). Key not found: returns {key, value: null, versionstamp: null} — not an error. Atomic check failure: returns {ok: false} — handle retry logic in application code. Queue: messages delivered at-least-once; implement idempotency in handlers. Deno KV storage limits: per-key value size limit (64KB), per-database storage limit (per Deno Deploy plan). Deno Deploy uptime at status.deno.land. HTTP API latency: slightly higher than native access (network overhead).

docs.deno.com/deploy/kv covers native API guide (set/get/list/delete/atomic), queue API, watch API, and HTTP REST API for external access. Getting started: Deno.openKv() in any Deno script — zero config for local development. Deno Deploy: KV is automatically available in deployed functions (free tier). HTTP API enables Deno KV access from non-Deno environments. Community via Deno Discord and GitHub (denoland/deno, 93k+ stars). Deno team publishes frequent blog posts on KV patterns and use cases.