Under the hood Bindings

How Devflare wires KV from config to runtime

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

Devflare normalizes the authored shape before it does anything louder

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

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

KV from authored config to generated output

Keep the binding readable in source, then inspect only the Wrangler-facing slice Devflare emits when the config is compiled.

import { defineConfig } from 'devflare/config'

export default defineConfig({

name: 'kv-worker',

bindings: {

kv: {

CACHE: 'cache-kv',

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

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

}

})

Local runtime support depends on what Devflare can model directly

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.

KV

KV bindings are first-class in Devflare: author stable 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.