durable-objects
cloudflare/skills
Build stateful, coordinated applications on Cloudflare's edge using Durable Objects.
What is durable-objects?
This skill enables building, debugging, and reviewing Cloudflare Durable Objects code for persistent state management and coordination. Use it when you need strong consistency, per-entity storage, real-time coordination, or scheduled work tied to specific entities.
- Create and manage Durable Object classes with SQLite storage and RPC methods
- Implement coordination patterns like chat rooms, multiplayer games, and collaborative documents
- Configure wrangler bindings and migrations for Durable Objects
- Design sharding strategies and parent-child relationships for scalability
- Write and test Durable Object code with Vitest integration
- Handle WebSocket connections, alarms, and scheduled per-entity work
How to install durable-objects
npx skills add https://github.com/cloudflare/skills --skill durable-objects- Cloudflare Workers project with wrangler configured
- Understanding of TypeScript and async/await patterns
- Familiarity with SQL for SQLite schema design
How to use durable-objects
- 1.Define a Durable Object class extending DurableObject with constructor initialization using blockConcurrencyWhile()
- 2.Configure wrangler.jsonc with durable_objects bindings and migrations specifying new_sqlite_classes
- 3.Create stub instances using getByName() for deterministic routing or newUniqueId() for unique instances
- 4.Implement RPC methods (not fetch handlers) for communication with the Durable Object
- 5.Use ctx.storage.sql.exec() for synchronous SQLite operations or ctx.storage for KV storage
- 6.Set alarms with setAlarm() for scheduled per-entity work and implement the alarm() handler
- 7.Test using Cloudflare's Vitest integration following the testing reference documentation
Use cases
- Building a chat room system where each room is a separate Durable Object instance
- Implementing an inventory or booking system requiring strong consistency guarantees
- Creating a multiplayer game with per-game Durable Objects for state coordination
- Developing a real-time collaborative document editor with persistent connections
- Setting up subscription renewal or game timeout logic using alarms
- Backend engineers building stateful edge applications
- Full-stack developers implementing real-time coordination features
- Cloudflare Workers developers needing persistent state beyond KV storage
- Teams building multi-tenant SaaS platforms with per-entity data isolation
durable-objects FAQ
Use Durable Objects when you need strong consistency, per-entity state, coordination (chat, games, collaborative docs), persistent connections, or scheduled work tied to specific entities. Use plain Workers for stateless request handling.
getByName() creates a deterministic stub—same input always routes to the same instance, ideal for named entities like chat rooms. newUniqueId() generates a unique ID each time; store the mapping externally if you need to retrieve it later.
No—blockConcurrencyWhile() should only be used during initialization in the constructor. Using it on every request kills throughput by serializing all operations.
Always persist critical state to SQLite storage first. Memory state can be lost on eviction or crash. Use memory only for caching data you've already persisted.
Use setAlarm() to schedule work at a specific time. In the alarm() handler, process the work and call setAlarm() again to reschedule if needed. Each Durable Object can have only one active alarm.
Full instructions (SKILL.md)
Source of truth, from cloudflare/skills.
name: durable-objects description: Build, debug, or review Cloudflare Durable Objects code for persistent state and coordination.
Durable Objects
Build stateful, coordinated applications on Cloudflare's edge using Durable Objects.
Retrieval Sources
Your knowledge of Durable Objects APIs and configuration may be outdated. Prefer retrieval over pre-training for any Durable Objects task.
Fetch the relevant doc page when implementing features.
When to Use
- Creating new Durable Object classes for stateful coordination
- Implementing RPC methods, alarms, or WebSocket handlers
- Reviewing existing DO code for best practices
- Configuring wrangler.jsonc/toml for DO bindings and migrations
- Writing tests with Cloudflare’s Vitest integration
- Designing sharding strategies and parent-child relationships
Reference Documentation
./references/rules.md- Core rules, storage, concurrency, RPC, alarms- Testing reference - Current Vitest documentation, migration choices, and test selection
./references/workers.md- Workers handlers, types, wrangler config, observability
Search: blockConcurrencyWhile, idFromName, getByName, setAlarm, sql.exec
Core Principles
Use Durable Objects For
| Need | Example |
|---|---|
| Coordination | Chat rooms, multiplayer games, collaborative docs |
| Strong consistency | Inventory, booking systems, turn-based games |
| Per-entity storage | Multi-tenant SaaS, per-user data |
| Persistent connections | WebSockets, real-time notifications |
| Scheduled work per entity | Subscription renewals, game timeouts |
Do NOT Use For
- Stateless request handling (use plain Workers)
- Maximum global distribution needs
- High fan-out independent requests
Quick Reference
Wrangler Configuration
// wrangler.jsonc
{
"durable_objects": {
"bindings": [{ "name": "MY_DO", "class_name": "MyDurableObject" }]
},
"migrations": [{ "tag": "v1", "new_sqlite_classes": ["MyDurableObject"] }]
}
Basic Durable Object Pattern
import { DurableObject } from "cloudflare:workers";
export interface Env {
MY_DO: DurableObjectNamespace<MyDurableObject>;
}
export class MyDurableObject extends DurableObject<Env> {
constructor(ctx: DurableObjectState, env: Env) {
super(ctx, env);
ctx.blockConcurrencyWhile(async () => {
this.ctx.storage.sql.exec(`
CREATE TABLE IF NOT EXISTS items (
id INTEGER PRIMARY KEY AUTOINCREMENT,
data TEXT NOT NULL
)
`);
});
}
async addItem(data: string): Promise<number> {
const result = this.ctx.storage.sql.exec<{ id: number }>(
"INSERT INTO items (data) VALUES (?) RETURNING id",
data
);
return result.one().id;
}
}
export default {
async fetch(request: Request, env: Env): Promise<Response> {
const stub = env.MY_DO.getByName("my-instance");
const id = await stub.addItem("hello");
return Response.json({ id });
},
};
Critical Rules
- Model around coordination atoms - One DO per chat room/game/user, not one global DO
- Use
getByName()for deterministic routing - Same input = same DO instance - Use SQLite storage - Configure
new_sqlite_classesin migrations - Initialize in constructor - Use
blockConcurrencyWhile()for schema setup only - Use RPC methods - Not fetch() handler (compatibility date >= 2024-04-03)
- Persist first, cache second - Always write to storage before updating in-memory state
- One alarm per DO -
setAlarm()replaces any existing alarm
Authorization
Durable Objects do not have separate roles or permissions; access follows the Worker that implements them. Retrieve the current Durable Objects authorization guidance before granting observability or Data Studio access, and scope the Workers role to the intended Worker or Workers product.
Anti-Patterns (NEVER)
- Single global DO handling all requests (bottleneck)
- Using
blockConcurrencyWhile()on every request (kills throughput) - Storing critical state only in memory (lost on eviction/crash)
- Using
awaitbetween related storage writes (breaks atomicity) - Holding
blockConcurrencyWhile()acrossfetch()or external I/O
Stub Creation
// Deterministic - preferred for most cases
const stub = env.MY_DO.getByName("room-123");
// From existing ID string
const id = env.MY_DO.idFromString(storedIdString);
const stub = env.MY_DO.get(id);
// New unique ID - store mapping externally
const id = env.MY_DO.newUniqueId();
const stub = env.MY_DO.get(id);
Storage Operations
// SQL (synchronous, recommended)
this.ctx.storage.sql.exec("INSERT INTO t (c) VALUES (?)", value);
const rows = this.ctx.storage.sql.exec<Row>("SELECT * FROM t").toArray();
// KV (async)
await this.ctx.storage.put("key", value);
const val = await this.ctx.storage.get<Type>("key");
Alarms
// Schedule (replaces existing)
await this.ctx.storage.setAlarm(Date.now() + 60_000);
// Handler
async alarm(): Promise<void> {
// Process scheduled work
// Optionally reschedule: await this.ctx.storage.setAlarm(...)
}
// Cancel
await this.ctx.storage.deleteAlarm();
Testing
Read the testing reference before configuring a suite or writing Durable Object tests. It routes to current setup, APIs, and examples and identifies the behavior to cover.
Related skills
More from cloudflare/skills and the wider catalog.

nextjs-on-cloudflare
Build and deploy Next.js apps on Cloudflare Workers using vinext.

sandbox-migrate-to-next
Migrate Cloudflare Sandbox apps from stable SDK to 1.0 preview (@next).

sandbox-next
Build Cloudflare Sandbox apps on the SDK 1.0 preview line with isolated Linux containers.

sandbox-sdk
Build secure, isolated code execution environments on Cloudflare Workers.

sandbox-stable
Build and maintain Cloudflare Sandbox apps on the stable @cloudflare/sandbox package.

turnstile-spin
Set up, repair, or migrate Cloudflare Turnstile bot verification end-to-end in your frontend and backend.