Cloudflare Durable Objects now wait before applying new code
Deploys used to reset active objects immediately, killing in-flight work and open connections. The new default gives them up to five minutes to finish first.
Cloudflare changed how Durable Objects pick up new code on 30 October. Previously, a deploy applied immediately: an active object reset there and then, which could interrupt in-flight work and terminate open connections. Now the default strategy is “deferred”, and an active object keeps running its current code for up to 300 seconds (five minutes) while it waits to hibernate, or until that delay runs out, whichever comes first.
Deferral is best effort, not a guarantee: Cloudflare is explicit that it doesn’t promise every in-flight operation finishes, and a runtime update can still reset the object before max_delay is reached. You can tune or bypass it per deployment:
"durable_objects": {
"code_update_strategy": { "mode": "deferred", "max_delay": 120 }
}Passing { "mode": "immediate" }, or the --durable-objects-code-update-mode immediate CLI flag, restores the old instant-reset behaviour for a single deploy.
Why it matters: if your Durable Objects hold WebSocket connections or long-running state, this is a quieter rollout than before, but it also means a deploy no longer takes effect everywhere at once. Anything that assumes “deploy means every object is on new code immediately” (an incident fix, a hotfix behind a bug) now needs the immediate flag instead.