Under the hood Bindings

How Devflare wires KV from config to runtime

Workers KV is a global key-value store for low-latency reads and lightweight shared data.

KV goes through the full Devflare pipeline: normalize authoring, resolve names when needed, then compile to Wrangler output.

The important detail is that Devflare does not force ids too early. It keeps stable names readable in source and only turns them into deploy-ready output in flows that truly require it.

Normalization: String and forms both normalize to name-based bindings first
Compile target: Wrangler
Preview note: Preview-scoped KV namespaces can be provisioned and cleaned up automatically

How authored config becomes Wrangler config

accepts a plain string, , or . Devflare normalizes those into one internal shape so later code can reason about them consistently.

Authored config can stay human-readable without making compiler or deploy code guess what each record means at the last second.

KV config and emitted Wrangler output

Use this when you need to check how the Devflare config becomes Wrangler-compatible config.

import { defineConfig } from 'devflare/config'

export default defineConfig({

name: 'kv-worker',

bindings: {

kv: {

CACHE: 'cache-kv',

SESSIONS: { name: 'sessions-kv' },

REPORTING_CACHE: { id: 'kv-namespace-id' }

}

})

What local runtime support covers

Local runtime resolution can keep the configured name as the local namespace identifier instead of forcing a Cloudflare API lookup.
The env proxy supports the real KV methods you expect in worker code, including , , , , and .
If you only need isolated unit tests, the repo also exposes and helpers.

Compile, preview, and cleanup behavior

Build and deploy flows resolve stable namespace names into ids when the output must be Wrangler-ready.
If unresolved name-based KV bindings remain at compile time, Devflare rejects the config instead of silently guessing.
Preview-scoped KV names are treated as lifecycle-managed resources, so branch-specific namespaces can be provisioned and cleaned up deliberately.

Why the split matters

Authored config can stay stable and readable even though deploy output eventually needs concrete ids. That separation is a big part of why KV feels pleasant in Devflare.

Cloudflare docs vs the Devflare layer

Cloudflare Workers KV docs is the platform reference. Use this internals page when you need to compare Cloudflare's product docs with Devflare config, generated env types, local support, and preview behavior for .

Reference

Cloudflare Workers KV docs

Cloudflare Docs

Platform reference for KV namespaces, binding APIs, limits, and Wrangler-facing setup.

Question	Cloudflare docs	This Devflare page
Primary focus	Platform reference for KV namespaces, binding APIs, limits, and Wrangler-facing setup.	How to author , what the runtime surface looks like, and how KV fits a Devflare project.
Testing and runtime lens	Cloudflare’s docs focus on the raw binding API, product semantics, and platform limits for the binding itself.	Local runtime and tests. Use the Devflare guidance when you need the honest local harness or the right remote gate instead of only the product API shape.
When to open it	When you need the platform contract, limits, APIs, or account-level product details.	When you are wiring, testing, previewing, or reviewing the binding inside a Devflare app.

KV

Author stable KV names in config, keep env typed, and run real get or put flows locally.

Testing KV

Use the default test harness first. KV is one of the bindings Devflare supports best in local tests.