Durable Objects Rules & Best Practices
Choose one object per entity that needs coordinated state. Keep essential data in durable storage; in-memory state must be reconstructible. Prefer SQLite for new classes, and inspect the backend of existing classes before selecting APIs. For idle WebSocket servers, prefer hibernation and plan for state restoration.
Fetch the relevant current documentation before implementing or reviewing changes.
| Task | Documentation |
|---|---|
| Choose object boundaries, deterministic routing, parent-child relationships, or initialization | Rules of Durable Objects |
| Choose SQLite or maintain an existing KV-backed class | SQLite storage API; Legacy KV storage API |
| Review storage gates, external I/O races, transactions, or schema initialization | Rules of Durable Objects; SQLite storage API; Durable Object State |
| Configure class lifecycle changes | Class exports; Legacy class migrations |
| Set placement hints or jurisdiction constraints | Data location |
| Create stubs, invoke RPC, or use HTTP handlers | Invoke methods; Namespace API |
| Schedule per-object work and handle retries | Alarms |
| Restore WebSocket connection state after hibernation | Use WebSockets |
| Handle exceptions, restarts, and shutdowns | Error handling; Object lifecycle |
For verification, use Testing Durable Objects. Keep API signatures, configuration, limits, and implementation examples in the linked docs.