Under the hood Bindings

How Devflare wires R2 from config to runtime

R2 is simpler than KV or D1 because the authored value is already the bucket name, so there is no name-versus-id resolution dance.

That simplicity is part of why R2 feels predictable in Devflare. The runtime and compiler story mostly focuses on wiring methods and generated output cleanly, not on translating names into ids.

Normalization: There is no separate id-resolution phase for the authored bucket name
Compile target: Wrangler
Preview note: Preview-scoped buckets can be provisioned and cleaned up by Devflare

Devflare normalizes the authored shape before it does anything louder

R2 is one of the cleanest bindings internally because the authored string is already the thing Wrangler expects later: the bucket name.

That means Devflare mostly needs to preserve the mapping faithfully, generate output, and expose the runtime methods cleanly in local mode.

R2 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: 'r2-worker',

bindings: {

r2: {

ASSETS: 'assets-bucket',

PRIVATE_FILES: 'private-files-bucket'

}

})

Local runtime support depends on what Devflare can model directly

The local bridge supports , , , , and on R2 buckets.
Large operations can switch to HTTP transfer inside the bridge rather than trying to force every object body through one RPC path.
exists for isolated tests, but the real local harness is usually the better default.

Compile, preview, and cleanup behavior

Compile emits directly from the authored mapping.
Preview resource lifecycle code can materialize branch-scoped bucket names, provision them, and later clean them up.
The browser URL story is intentionally left to your app architecture rather than being smuggled into the binding implementation.

Simple binding, nontrivial delivery choices

R2 config is easy. The interesting decisions are about how files flow through your app, not about how many nested objects the config needs.

R2

R2 is straightforward in config and well-supported locally, but browser-facing delivery should usually go through a Worker route instead of assuming bucket URLs.

Testing R2

R2 is local-friendly, which means you can test real object operations without inventing a storage adapter just to get off the ground.