durable-objects

Extend the DurableObject class from cloudflare:workers and configure new_sqlite_classes in your wrangler migrations. Initialize tables inside the constructor using ctx.blockConcurrencyWhile and this.ctx.storage.sql.exec for synchronous SQL queries.

Use @cloudflare/vitest-pool-workers with defineWorkersConfig pointing at your wrangler config. Access stubs via env from cloudflare:test, inspect internals with runInDurableObject, and trigger alarms instantly with runDurableObjectAlarm.

Avoid Durable Objects for stateless request handling, which plain Workers handle better, and for workloads needing maximum global distribution or high fan-out of independent requests. DOs are designed for coordination and strong consistency per entity.

Class properties are lost when the instance is evicted or crashes. Always persist critical state to SQLite storage first, then update in-memory caches, since only storage survives eviction.

No, PRAGMA user_version is not supported in Durable Objects SQLite storage. Track schema versions in a dedicated _sql_schema_migrations table and apply incremental migrations during constructor initialization.

Each DO supports one alarm at a time, and calling setAlarm replaces any existing alarm. Implement an async alarm() handler that processes scheduled work and optionally reschedules; failed alarms retry automatically, so handlers should be idempotent.