durable-objects

name	durable-objects
description	Create and review Cloudflare Durable Objects. Use when building stateful coordination (chat rooms, multiplayer games, booking systems), implementing RPC methods, SQLite storage, alarms, WebSockets, or reviewing DO code for best practices. Covers Workers integration, wrangler config, and testing with Vitest.

Durable Objects

Retrieval-First Development

Prefer retrieval from official docs over pre-training for Durable Objects tasks.

Resource	URL
Docs	https://developers.cloudflare.com/durable-objects/
API Reference	https://developers.cloudflare.com/durable-objects/api/
Best Practices	https://developers.cloudflare.com/durable-objects/best-practices/
Examples	https://developers.cloudflare.com/durable-objects/examples/

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/vitest-pool-workers
• Designing sharding strategies and parent-child relationships

Reference Documentation

• ./references/rules.md - Core rules, storage, concurrency, RPC, alarms
• ./references/testing.md - Vitest setup, unit/integration tests, alarm testing
• ./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

Prefer Alternatives 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;
  }
}

  {
   (: , : ): <> {
     stub = env..();
     id =  stub.();
     .({ id });
  },
};

Core Rules

1. Model around coordination atoms - One DO per chat room/game/user, not one global DO
2. Use getByName() for deterministic routing - Same input = same DO instance
3. Use SQLite storage - Configure new_sqlite_classes in migrations
4. Initialize in constructor - Use blockConcurrencyWhile() for schema setup only
5. Use RPC methods - Not fetch() handler (compatibility date >= 2024-04-03)
6. Persist first, cache second - Always write to storage before updating in-memory state
7. One alarm per DO - setAlarm() replaces any existing alarm

Anti-Patterns

• 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 await between related storage writes (breaks atomicity)
• Holding blockConcurrencyWhile() across fetch() or external I/O

Durable Object Facets (April 2026)

Facets allow a single DO instance to expose multiple independent "facets" — each with its own RPC interface — enabling fine-grained access control and modular design.

import { DurableObject, DurableObjectFacet } from "cloudflare:workers";

export class UserFacet extends DurableObjectFacet {
  async getProfile(): Promise<UserProfile> {
    // Read-only access to user data
    return this.ctx.storage.sql.exec<UserProfile>(
      "SELECT * FROM profiles WHERE id = 1"
    ).one();
  }
}

export class AdminFacet extends DurableObjectFacet {
  async deleteUser(): Promise<void> {
    this.ctx.storage.sql.exec("DELETE FROM profiles WHERE id = 1");
  }
}

export class UserDO extends DurableObject<Env> {
  user = this.facet(UserFacet);   // Expose as stub.user.getProfile()
  admin = .(); 
}

• Each facet is accessed via stub.<facetName>.<method>()
• Use facets to separate read vs write, public vs admin interfaces
• Docs: https://developers.cloudflare.com/durable-objects/api/facets/

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");

Storage limit: Each DO instance has a 10 GB SQLite storage limit.

SQL transactions: Explicit BEGIN/COMMIT/ROLLBACK are not supported. Each sql.exec() call is auto-committed. For atomic multi-statement writes, use blockConcurrencyWhile() to prevent interleaving (but note: no rollback on partial failure).

Point-in-Time Recovery (PITR)

// List available bookmarks
const bookmarks = await this.ctx.storage.sql.getBookmarksForRestore();

// Restore to a specific bookmark
await this.ctx.storage.sql.restoreFromBookmark(bookmarks[0]);

PITR allows restoring a DO's SQLite database to a previous state. Useful for recovering from application-level data corruption.

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 Quick Start

import { env } from "cloudflare:test";
import { describe, it, expect } from "vitest";

describe("MyDO", () => {
  it("should work", async () => {
    const stub = env.MY_DO.getByName("test");
    const result = await stub.addItem("test");
    expect(result).toBe(1);
  });
});