Cloudflare cuts Durable Object cold starts with better placement
Reactivated Durable Objects now restart on the machine that last ran them whenever possible, so SQLite-backed instances skip reloading their data from scratch.
Cloudflare changed how it decides where a Durable Object restarts after going idle. Reactivated objects now start on the machine that last ran them whenever possible, instead of wherever has free capacity, so their data doesn’t need to be loaded again from scratch.
The change rolled out across all regions on 9 November and needs no configuration. It matters most for SQLite-backed Durable Objects, which carry state that previously had to be re-read on every reactivation after a period of inactivity.
Why it matters: this is exactly the pattern behind per-user state, WebSocket coordination objects and session storage, the kind of Durable Object that goes quiet between bursts of activity and then needs to respond instantly. Fewer cold starts there means fewer latency spikes on the first request after idle time, with no code change required on your end.