Binding reference Bindings

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

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

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.

Devflare auto-discovers by default, wires the Durable Object binding into the worker env, and lets tests use the same namespace without making you invent a fake DO harness first.

Config key
Authoring shape
Best for: Stateful sessions, locks, room state, and coordination that should not be faked as random stateless requests

Add the binding to config

The easiest honest starting point is one local Durable Object class and one binding that points at it by class name.

If the class lives in a file, Devflare discovers it with the default pattern, so the first example does not need extra DO file config.

Start with one discovered Durable Object and one binding

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']

}

]

})

Use the binding from application code

After Devflare generates the worker env, import from and keep the first Durable Objects 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.

A tiny object and one worker path

import { DurableObject } from 'cloudflare:workers'

export class Counter extends DurableObject<DevflareEnv> {

async increment(amount = 1): Promise<number> {

const current = (await this.ctx.storage.get<number>('value')) ?? 0

const next = current + amount

await this.ctx.storage.put('value', next)

return next

}

async getValue(): Promise<number> {

return (await this.ctx.storage.get<number>('value')) ?? 0

}

Local and Remote Support

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

Local runtime and tests, including cross-worker references. Start locally with with the real DO namespace in ; that lane should cover the normal Durable Objects 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 Durable Objects details.

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 counters, rooms, distributed locks, and request serialization.
If the state is really just data you query, D1 or KV may stay simpler and easier to preview.

Testing path

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.

Open the next page when you need it

Subpage

Durable Objects internals

Internals

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

Subpage

Testing Durable Objects

Testing

Pick the with the real DO namespace in path first, then move to remote checks only when the test needs them.

Subpage

Durable Objects example

Example

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