Binding reference Bindings

Use Durable Objects when coordination or state really belongs with a single object identity

Devflare treats Durable Objects as a real first-class surface in config, local runtime, and tests, not as an awkward plugin hanging off the side of the worker.

That makes DO-heavy apps easier to reason about locally, but it also means you should be honest about the preview and migration caveats that come with them.

Config key: bindings.durableObjects
Authoring shape: Record<string, string | { className: string; scriptName?: string }>
Best for: Stateful sessions, locks, room state, and coordination that should not be faked as random stateless requests

Author it in the simplest shape that still says what you mean

A DO binding can be as simple as a class name string when the object lives in the same worker package.

When the object lives in another worker, keeps that relationship explicit instead of scattering script names and class names across the repo.

Durable Object authoring in one worker

import { defineConfig } from 'devflare/config'

export default defineConfig({

name: 'chat-worker',

files: {

durableObjects: 'src/do/**/*.ts'

bindings: {

durableObjects: {

ROOM: 'ChatRoom',

LOCK: { className: 'WriteLock' }

}

})

When this binding fits best

Use Durable Objects when state or coordination should live behind one object identity, not when you merely want a fancy singleton.
They are a good fit for rooms, counters, distributed locks, and request serialization.
If the state is really just data you query, D1 or KV may stay simpler and easier to preview.

Notes worth keeping visible

DO-heavy apps need extra preview care because same-worker preview URLs do not cover every real DO deployment case.
does not currently apply Durable Object migrations, so migration-sensitive previews need a stronger plan.
Test and review worker naming carefully when DO bindings cross worker boundaries.

The preview caveat is real, not optional trivia

If previews must exercise real Durable Object behavior, branch-scoped preview workers are often safer than hoping same-worker preview URLs will be enough.

Cloudflare docs vs the Devflare layer

Cloudflare Durable Objects docs is the platform reference. This page is the Devflare translation layer: keep readable in source, understand the typed env surface, and know which local, preview, or remote lane actually matches the binding.

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.	First-class 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.

Go deeper only if this one-page guide stops being enough

Subpage

Durable Objects internals

Internals

See normalization, Wrangler , and the preview or runtime details behind the authored shape.

Subpage

Testing Durable Objects

Testing

Start from with the real DO namespace in and only escalate when the binding or deployment model genuinely needs it.

Subpage

Durable Objects example

Example

Adapt one small end-to-end path before you hide the binding behind a bigger abstraction.