Under the hood Bindings

How Devflare wires R2 from config to runtime

R2 is Cloudflare object storage for files, uploads, generated assets, and private objects.

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

How authored config becomes Wrangler config

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

bindings: {

r2: {

ASSETS: 'assets-bucket',

PRIVATE_FILES: 'private-files-bucket'

}

})

What local runtime support covers

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.

Cloudflare docs vs the Devflare layer

Cloudflare R2 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 R2 docs

Cloudflare Docs

Platform reference for buckets, object APIs, public-versus-private delivery, and account features.

Question	Cloudflare docs	This Devflare page
Primary focus	Platform reference for buckets, object APIs, public-versus-private delivery, and account features.	How to author , what the runtime surface looks like, and how R2 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.

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.