Under the hood Bindings

How Devflare wires Durable Objects from config to runtime

Durable Objects give Workers a named place for stateful coordination, storage, and alarms.

Durable Object bindings normalize into a stable binding shape, compile into Wrangler , and participate in Devflare’s own DO bundling path.

This is one of the places where Devflare feels the most application-aware. It is not only compiling config — it is discovering DO classes, bundling them, and keeping local runtime behavior coherent.

Normalization: Local strings, explicit objects, and cross-worker refs normalize into one DO binding model
Compile target: Wrangler
Preview note: DO apps often need branch-scoped preview workers instead of same-worker preview URLs

How authored config becomes Wrangler config

DO bindings accept a string, an explicit object, or a cross-worker reference produced by . Devflare normalizes those into one internal shape before later steps inspect them.

That normalized shape is what lets config, compiler, and test-context setup all speak the same language even when a DO comes from another worker package.

Durable Objects 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: 'counter-worker',

files: {

fetch: 'src/fetch.ts'

bindings: {

durableObjects: {

COUNTER: 'Counter'

}

migrations: [

{

tag: 'v1',

new_classes: ['Counter']

}

]

})

What local runtime support covers

The local test context can auto-detect cross-worker DO refs and stand up the required multi-worker Miniflare shape for them.
The DO bundler discovers classes from , emits worker-compatible code, and even handles special cases like usage.
Tests can use the normal DO namespace ergonomics instead of a custom fake API surface.

Compile, preview, and cleanup behavior

Compile emits and optional for each binding, which is what Wrangler-facing output expects.
Cross-worker DO references are resolved before compile output is treated as final.
Preview and deploy workflows need to respect real DO migration and preview caveats instead of pretending the platform limitations disappeared.

This is where coherent tooling matters most

If a tool cannot keep DO authoring, local runtime, and test setup coherent, DO-heavy apps get painful fast. Devflare’s value is that these pieces stay part of one story.

Cloudflare docs vs the Devflare layer

Cloudflare Durable Objects 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 Durable Objects docs

Cloudflare Docs

Platform reference for object identity, storage, alarms, migrations, and deployment caveats.

Question	Cloudflare docs	This Devflare page
Primary focus	Platform reference for object identity, storage, alarms, migrations, and deployment caveats.	How to author , what the runtime surface looks like, and how Durable Objects 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, including cross-worker references. 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.

Durable Objects

The fast Devflare payoff is simple: put one counter object in a file, call it from the worker, and call the same object directly in tests.

Testing Durable Objects

Durable Objects are well-supported in the default Devflare harness, which means you can test real object behavior without hand-building a fake namespace first.