Skip to content

SYSTEM Cited by 5 sources

Cloudflare Workers KV

Workers KV is Cloudflare's edge-distributed, eventually-consistent key-value store exposed as a first-class Workers binding (developers.cloudflare.com/kv). Reads are served from cache at Cloudflare edge POPs; writes propagate globally.

Role

  • Low-latency read path for small values (config, feature flags, tokens, pre-computed content).
  • Eventually consistent: writes visible globally in seconds.
  • Binding-based access from Workers; no client-side KV driver.

Local / remote parity

KV is one of the binding types exposed through Local Explorer's local mirror of the Cloudflare API at /cdn-cgi/explorer/api, backed by local on-disk state managed by Miniflare (Source: sources/2026-04-13-cloudflare-building-a-cli-for-all-of-cloudflare). Local namespaces are GUI-introspectable, seedable, and callable through the same KV API shape as remote.

As auth-token store (Artifacts, 2026-04-16)

In Artifacts, KV is the auth-token-tracking store used by the front-end Worker on every Git request: the token embedded in the HTTPS URL / header is looked up in KV before the request is routed to the per-repo Durable Object. Sits alongside R2 (pack-file snapshots) and DO SQLite (hot git objects) in the Artifacts storage stratification. Canonical wiki instance of KV as the edge-replicated low-latency authn lookup tier in front of a per-unit DO. See patterns/do-backed-git-server.

Seen in

  • sources/2025-11-18-cloudflare-outage-on-november-18-2025 — Workers KV returned significantly elevated HTTP 5xx during the outage because its "front end" gateway is served by the core proxy. At 13:05 UTC teams bypassed the core proxy for Workers KV (fallback to a prior core-proxy version), reducing impact on KV itself and on every downstream service relying on KV (notably Cloudflare Access and the Cloudflare Dashboard). Canonical wiki instance of Workers KV as a hub of control-plane dependency at Cloudflare: when KV is unavailable, the knock-on effects are fleet-wide.
  • sources/2026-04-13-cloudflare-building-a-cli-for-all-of-cloudflare — KV as a binding introspectable via Local Explorer.
  • sources/2026-04-16-cloudflare-artifacts-versioned-storage-that-speaks-git — KV as the auth-token store in front of per-repo DOs.
  • sources/2026-02-24-cloudflare-how-we-rebuilt-nextjs-with-ai-in-one-week — KV as the default ISR cache substrate for vinext via KVCacheHandler: setCacheHandler(new KVCacheHandler(env.MY_KV_NAMESPACE)). Also the destination of vinext's TPR pre-rendered output ("Pre-rendered 184 pages in 8.3 s → KV cache"). Canonical wiki instance of KV as an ISR cache tier + pluggable cache handler substrate.
  • sources/2026-04-17-cloudflare-introducing-flagship-feature-flags-built-for-the-age-of-ai — KV as the edge-replicated read tier for feature-flag configuration in Flagship (private beta 2026-04-17). From the post: "When you create or update a flag, the control plane writes the change atomically to a Durable Object … Within seconds, the updated flag config is synced to Workers KV, Cloudflare's globally distributed key-value store, where it's replicated across Cloudflare's network. When a request evaluates a flag, Flagship reads the flag config directly from KV at the edge — the same Cloudflare location already handling the request." Load- bearing property named by the post: "caching is managed for you, reads are local, and you don't need a persistent connection to keep things up to date. Cloudflare KV is a great primitive for this!" — KV replaces the in-process rules cache of traditional local-evaluation flag SDKs as the distribution primitive, because Workers isolates are not long-lived processes and an SDK-resident cache would have to bootstrap from scratch on every cold isolate. Canonical wiki instance of KV as the eventually-consistent edge-replicated config-read tier in the patterns/do-plus-kv-edge-config-distribution pattern (sibling of Artifacts' auth-token role but here KV holds the config, not auth).
Last updated · 200 distilled / 1,178 read