Michael JohnsonAfter a deployment, an active Cloudflare Durable Object can now continue running its current code until it enters hibernation or the configured time limit expires. On October 30, Cloudflare made deferred updates the default, with a maximum delay of five minutes. For developers, this changes how already-running objects behave during a rollout: an update does not have to interrupt them immediately, and supported WebSocket connections may survive the transition to a new version.
What happens during deployment
Durable Objects are addressable objects with persistent identity and state, which Cloudflare uses, among other things, to coordinate clients, long-running tasks, and WebSocket sessions. Only one code version runs for a given object at a time. As a result, an immediate replacement can reset an active instance, interrupting its work or connections.
The default behavior is now a deferred transition. After deployment, an active object continues serving requests on the old version. If it enters hibernation first, the new version starts when it is next accessed. If five minutes pass and the object is still active, it is reset and takes the new version. The Worker deployment itself completes separately: the delay applies to when an already-active object begins executing the new code.
Who benefits
The change matters for services where a single object holds work across requests—for example, a long-running session, coordination among multiple clients, or a WebSocket connection. Deferred transition creates a window in which such an object can naturally finish its current activity or go to sleep before updating. For WebSockets, Cloudflare specifies a condition: connections using the Hibernation API remain connected when the object takes the new code after hibernation.
The practical takeaway for teams is to identify which active objects may remain busy for more than a few minutes and determine which WebSocket API they use. That will determine whether the new deployment behavior gives the application a chance for a graceful transition or whether the connection will end during a forced update.
Five minutes is a window, not a guarantee
Cloudflare describes deferred updates as best effort: an object may be reset earlier, for example during a runtime update. If it has not entered hibernation by the end of the maximum delay, the platform applies the new version by resetting it. Important state should therefore be saved in durable storage, and operations should be designed with possible retries in mind. Cloudflare’s documentation recommends persisting state that must survive deployments, rather than relying on the active instance’s memory.
Teams can override the behavior in their Durable Objects configuration: they can set immediate updates or choose a different delay for the deferred transition. Immediate mode is useful when the new version must take effect at once, such as for an urgent fix; a longer delay may give objects more time, but also extends the period during which some instances serve the old version.
What to check before your next deployment
Check request compatibility between the Worker and Durable Object during periods when they may be running different versions. Verify that critical state is stored persistently rather than only in memory. For WebSockets, determine whether the application uses the Hibernation API: ordinary connections may end when the update is applied. If deployment requires an immediate transition, check the explicit mode setting instead of relying on the new default.
Cloudflare has changed the default deployment trade-off: active objects get a limited time to transition naturally, while teams retain the option to speed up updates through configuration. The most useful steps for developers are to check old/new version compatibility, state persistence, and WebSocket type before the next deployment.
