Cloudflare Durable Objects Made State Local. The Objects Still Need Orchestration.

Vendor and product reality

Cloudflare Durable Objects are a commercial product of Cloudflare, Inc., delivered as part of the Workers platform and tightly coupled to Cloudflare's global edge network. Each Durable Object is defined by an exported JavaScript or TypeScript class. Cloudflare's control plane maintains the mapping from object IDs to physical placement, ensures single-instance semantics across the network, and provides a transactional storage API. The 2024 SQLite-backed storage backend extended the platform from key-value persistence to a full embedded relational store inside each object, with synchronous transaction semantics scoped to the object's single thread of execution. Storage performance is excellent because the database file lives on the same machine as the actor; there is no network round trip for hot reads or writes within a transaction.

The platform is genuinely innovative. Colocating state with compute at the edge while maintaining strong consistency is non-trivial engineering, and the actor-style programming model removes a great deal of accidental complexity from real-world stateful workloads such as collaborative editors, multiplayer game rooms, agentic session state, queue coordinators, rate limiters, and per-tenant cache layers. Cloudflare's pricing is metered per request, per duration of wall-clock execution, and per stored byte; the runtime is a fully managed service with no customer-controlled placement of the authority that decides when and where an object lives. Cloudflare also retains exclusive control over the version of the Worker bundle a given object is bound to, the bindings configuration, the eviction policy, and the rollback surface for misbehaving deployments.

This is the commercial reality. Durable Objects are a powerful primitive, and Cloudflare has shipped what is arguably the most usable stateful actor model in commercial cloud infrastructure. But the authority over the object — when it activates, when it is evicted, what code it runs, what storage it holds, what governance rules it obeys — sits inside Cloudflare's control plane, not inside the object itself. The object is a tenant on Cloudflare's substrate, and like any tenant relationship, the terms of residency are set by the landlord. This is not a criticism of the product; it is a description of the layer at which the product operates.

The architectural gap

A Durable Object activates when it receives a request. It processes the request, may modify its storage, and returns a response. Between requests, the runtime may evict the object from memory; the next request rehydrates it from storage. Alarms provide a timer mechanism, but alarms are scheduled callbacks delivered by the platform's scheduler, not autonomous execution cycles authored into the object's own definition. The execution model is, at its core, the actor pattern lifted onto edge infrastructure: messages drive behavior, and the absence of a message is the absence of behavior. The object cannot decide, on its own and without external prompting, that the time has come to evaluate its state, run a check, or take an action.

A memory-resident execution object inverts this relationship. It carries its own execution cycle as part of its definition. It self-evaluates on each cycle: inspecting its memory, determining whether action is appropriate, executing if its internal predicates are met, and recording the result back into governed state. It does not wait for an external request to decide whether to act. It does not require the platform to know when the next tick should occur. The execution rules are intrinsic to the object, and they travel with it across substrates rather than being encoded in the host's scheduler, the host's bindings, or the host's configuration files.

The deeper gap is governance. Durable Objects store arbitrary key-value pairs or SQLite rows. The storage is persistent and consistent, but there is no schema for what the state means at the semantic layer, no governance validation on state transitions, and no lineage record describing how state evolved across cycles. The object holds data; it does not govern it. Two Durable Object instances of the same class running the same code may diverge into structurally different states, and nothing in the platform records why, because nothing in the platform speaks the language of fields, constraints, or lineage. The application can build such a layer on top, of course, but then the application is implementing governance in user code that ships separately from the object's data, with no architectural guarantee that the governance code and the data remain coupled across deployments, rollbacks, or migrations.

Most critically for portability: the rules that constrain the object — when it may execute, what mutations are valid, who may invoke which methods, what invariants must hold across a transition — do not ship with the object. They live in the deployed Worker bundle, in the bindings configured on Cloudflare's control plane, and in the operator's runbook. Move the SQLite file elsewhere and the rules are lost. Roll back the Worker bundle and the governance rules silently change while the data remains the same. There is no cryptographic binding between the object's state and the rules under which that state was produced or may be modified. From an audit perspective, the object is data without governed provenance.

What memory-resident execution provides

Memory-resident execution is the primitive in which an object carries, as a first-class part of its definition, its own execution cycle, its own governed memory schema, and its own rules for what counts as a valid mutation. The object's memory is not an opaque blob; it is a typed, schema-bound region with declared fields, declared invariants, and declared transitions. Each cycle of the object is a self-evaluation pass: the object reads its own memory, applies its execution predicates, and either acts, declines to act, enters an inquiry mode pending additional information, or transitions to dormancy because its task is complete. Lineage is recorded as a structural feature of the memory itself, not as an optional log written by the host or the application.

The behavioral consequences are concrete. A memory-resident object that detects that its own confidence in some governed field has dropped below a declared threshold enters a non-executing inquiry mode autonomously, without needing an external orchestrator to notice the drop. An object that determines from its own state that its task is complete enters dormancy and refuses further mutation attempts that would violate completion invariants — even if the host substrate would otherwise route a request to it. An object that receives relevant new information evaluates whether the information is admissible under its mutation rules before incorporating it, and the admission decision is itself a governed event that lineage records with the rule version that admitted it.

Equally important is what memory-resident execution refuses. It refuses the assumption that authority over the object lives in a control plane outside the object. The constraints, the schema, the cycle, and the lineage rules are properties of the object as an artifact, cryptographically bound where appropriate, so that the object remains the same governed entity regardless of which substrate is currently hosting its execution. The substrate becomes interchangeable; the object's identity, behavior, and audit surface do not. An auditor inspecting a memory-resident object six months after it ran can verify, from the object alone, what rules governed each transition, what inputs it admitted, and why each cycle produced the output it did. None of this depends on the cooperation of the substrate operator.

Composition pathway

Durable Objects and memory-resident execution are not competitors. They compose cleanly along a layering line. Durable Objects supply the substrate properties that are genuinely difficult to build: a globally addressable identity, single-threaded actor semantics, low-latency colocated SQLite storage, a managed eviction and rehydration lifecycle, and Cloudflare's network reach. Memory-resident execution supplies the layer above: the schema-bound governed memory, the intrinsic execution cycle, the mutation rules, and the lineage record. The two layers meet at a serialization boundary that is well defined on both sides.

In a composed deployment, a Durable Object class is the host shell. Its storage backend persists the serialized governed memory of the memory-resident object, and its alarm mechanism fires the next self-evaluation tick, but the contents of the cycle — what is read, what is checked, what is written, what is refused — are determined by the memory-resident object's own rules, not by handler code in the Worker. The Durable Object becomes a transport and persistence host. The memory-resident object remains the authority over its own state and behavior, and that authority is portable: the same governed object can run inside a Durable Object today and inside a different host substrate tomorrow without altering its semantics. The migration is an operational event, not a semantic event.

This composition also resolves the eviction question. Cloudflare may evict the actor from memory at any time, for capacity reasons, for region failover, or for routine deployment. From the perspective of the memory-resident object, eviction is just a long pause between cycles; rehydration replays from the governed serialization, and the lineage record makes the resumption auditable. The platform's lifecycle decisions become operational details, not semantic events. The object does not lose its history when the actor is evicted, because the history was recorded in the object's own governed memory rather than in the actor's volatile working set.

Commercial and licensing posture

Cloudflare offers Durable Objects under its standard Workers commercial terms, with metered pricing and the usual platform-level service obligations. Customers who build directly on Durable Objects accept that the authority surface — placement, eviction, version rollouts, account-level controls, billing, and access to the underlying storage — is operated by Cloudflare. This is appropriate for many workloads and is not, in itself, a defect. For applications whose governance requirements are bounded by the operational reach of the host, Durable Objects alone are an excellent fit.

The memory-resident execution primitive is offered by Adaptive Query as a separately licensable specification and reference implementation. Its purpose is precisely to keep the authority over governed state and execution rules with the object, and therefore with the licensee, rather than with whichever substrate is currently hosting the object. Composing the two is a supported pattern: customers may license the memory-resident execution primitive, run it inside Durable Objects for the operational benefits Cloudflare provides, and retain the ability to migrate the same governed objects onto alternative substrates — including private infrastructure, alternative edge networks, or future substrates that do not yet exist — without renegotiating the semantic layer or rebuilding the governance surface. The commercial line is drawn at the boundary the architecture already implies. Cloudflare licenses the substrate. Adaptive Query licenses the object that runs on it.