Binding reference Bindings

Use R2 for object storage, but route browser delivery deliberately

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

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.

R2 works in worker code and tests. The main discipline is deciding which files are public, which are private, and which paths should stay app-controlled.

Config key
Authoring shape
Best for: Files, uploads, generated assets, and private object delivery through a Worker

Add the binding to config

R2 is the least ambiguous storage binding to author: you bind a name in env to a bucket name in config.

The real architectural choice is not the config key. It is whether the browser talks to a public bucket, a signed upload path, or a worker-controlled route that checks auth first.

R2 binding authoring

import { defineConfig } from 'devflare/config'

export default defineConfig({

name: 'r2-worker',

bindings: {

r2: {

ASSETS: 'assets-bucket',

PRIVATE_FILES: 'private-files-bucket'

}

})

Use the binding from application code

After Devflare generates the worker env, import from and keep the first R2 path close to the route, handler, or service method that needs it.

Keep this first path small enough that the config, env binding, and user-visible behavior are easy to review together.

Serve an object through the worker

import { env } from 'devflare/runtime'

export async function fetch(request: Request): Promise<Response> {

const url = new URL(request.url)

const key = url.pathname.replace(/^\/files\//, '')

const object = await env.FILES.get(key)

if (!object) {

return new Response('Not found', { status: 404 })

}

return new Response(object.body, {

headers: {

'content-type': object.httpMetadata?.contentType ?? 'application/octet-stream'

}

})

}

Local and Remote Support

Devflare can run useful R2 application behavior locally for ordinary development and tests. Cloudflare still owns production limits, quotas, billing, and deployed account behavior.

Local runtime and tests. Start locally with with or ; that lane should cover the normal R2 application flow without requiring a Cloudflare connection.

Use Cloudflare when the assertion depends on deployed limits, account state, lifecycle behavior, billing, or other production-only R2 details.

When this binding fits best

Use R2 for large objects, uploads, or file delivery that does not belong in D1 or KV.
Keep private file delivery in a Worker route so auth and response headers stay under your control.
If the browser needs a direct public asset origin, use a public bucket on a custom domain rather than by accident.

Testing path

Do not assume local bucket URLs are a public contract your app can safely depend on.
Use after binding changes so bucket names show up correctly in .
Preview-scoped buckets are useful, but they should still be cleaned up intentionally when previews expire.

The browser-delivery rule

If the browser needs the file in local dev, route through your worker unless you intentionally chose a public bucket contract.

Open the next page when you need it

Subpage

R2 internals

Internals

Check emitted Wrangler , preview behavior, and Cloudflare-specific details.

Subpage

Testing R2

Testing

Pick the with or path first, then move to remote checks only when the test needs them.

Subpage

R2 example

Example

Copy a fuller application path when the quick example is too small.