Does anybody know whether a Durable Object is moved back to it's original colo after it's been "move

Does anybody know whether a Durable Object is moved back to it's original colo after it's been "moved" to a different colo during an outage (for example)? This is in reference to what Josh Howard said in this video with Aaron Francis. I would assume it does move back to it's original colo - but it's one of those things that are annoying to test haha, so I don't know the definitive answer.

YouTube

✂️ "We can move Durable Objects"

23 seconds · Clipped by Jacob Marshall · Original video "How Durable Objects and D1 Work: A Deep Dive with Cloudflare’s Josh Howard" by Aaron Francis

Need_Not•10/22/25, 12:04 AM

Is there a limit how far in the future an alarm is set? I want to schedule for 30d in the future if that works.

NNeed_Not Is there a limit how far in the future an alarm is set? I want to schedule for 3...

Jacob MarshallOP•10/22/25, 12:19 AM

Assuming it's still accurate, this should answer your question: https://community.cloudflare.com/t/durable-objects-alarm-limit/512367

YYoh This is neat, thanks. I imagine this works really well if requests are always r...

Larry•10/22/25, 1:39 AM

What do you mean by "scheduled handler"?

LLarry What do you mean by "scheduled handler"?

Yoh•10/22/25, 1:48 AM

I have a cron job (the scheduled export in the worker entrypoint) which interacts with some DOs. So in this handler, I get DO stubs using idFromName, call the init function so they know their own entity id, and then call whatever other DO methods I need. In this case it wouldn’t be as nice to reimagine this as a fetch call where I inject my own headers

YYoh I have a cron job (the scheduled export in the worker entrypoint) which interact...

Larry•10/22/25, 2:09 AM

Makes sense. Using Workers RPC is more efficient. If it's possible that the first access to a DO instance comes from this cron job RPC call, then your init call is the only way I can think to handle it also. However, if you can be assured that it will always have been called before the cron job, then you might be able to use the headers approach.

YYoh I have a cron job (the scheduled export in the worker entrypoint) which interact...

cloudkite•10/22/25, 3:06 AM

Nice pattern to handle this is to have init return a RPCTarget with methods you want to be public and make everything else on the DO private. This makes it impossible to access the DO without going through your init fn

Ccloudkite Nice pattern to handle this is to have init return a RPCTarget with methods you ...

Yoh•10/22/25, 3:07 AM

I love that!

cloudkite•10/22/25, 3:14 AM

You can pipeline the init call to reduce round trips and it can work out cheaper as multiple methods invoked on same rpctarget instance is counted as single session

Ccloudkite Nice pattern to handle this is to have init return a RPCTarget with methods you ...

Larry•10/22/25, 4:04 AM

Are there any footguns with that approach? For instance do such sessions timeout? Or is that a non-issue when calling from a cron Worker? Might it be if calling from another DO?

LLarry Are there any footguns with that approach? For instance do such sessions timeout...

cloudkite•10/22/25, 4:10 AM

If using the “using” keyword

it should automatically be disposed. Unsure about max or idle timeout. Good idea to have wrapper on calling side to do retries with backoff

JJacob Marshall Does anybody know whether a Durable Object is moved back to it's original colo a...

lambrospetrou•10/22/25, 9:30 AM

I answered this a few messages above: durable-objects
Yes, at the moment, DOs will move back to the original colo if it's healthy.

LLarry Are there any footguns with that approach? For instance do such sessions timeout...

lambrospetrou•10/22/25, 9:31 AM

The only footgun is that the RpcTarget might need to be recreated if the connection breaks, but if you create a new one each time it should be OK.

Llambrospetrou I answered this a few messages above: https://discord.com/channels/5953179901913...

Jacob MarshallOP•10/22/25, 10:16 AM

Ah thanks for your response! Very helpful. For my use-case it would actually be more ideal for the DO to not hop around to be closer to the requests. I know that sounds unintuitive, but I’m building an app where the choice of location is intentional, and it may be possible that requests may come from customers from anywhere in the world - and moving the DO due to a high number of requests from a distant location would be not ideal. Happy to get in touch directly for more info

JJacob Marshall Ah thanks for your response! Very helpful. For my use-case it would actually be ...

lambrospetrou•10/22/25, 10:44 AM

Yeah, I doubt something like that would be released without some flag or at least some control for the users. This is mostly long-term vision.

Llambrospetrou Yeah, I doubt something like that would be released without some flag or at leas...

Jacob MarshallOP•10/22/25, 11:01 AM

That’s a relief haha. Thanks for the info!

Llambrospetrou The only footgun is that the RpcTarget might need to be recreated if the connect...

Larry•10/22/25, 11:29 AM

If you re-create every time, do you lose the promise pipelining fewer round trips benefit?

LLarry If you re-create every time, do you lose the promise pipelining fewer round trip...

lambrospetrou•10/22/25, 11:33 AM

Not for the init() + actual call if they are pipelined.
But you can even use the same RpcTarget across requests, and followup RPCs would go straight to the target host/DO instead of the usual routing. If this matters to your app is a whole other story

Llambrospetrou Not for the init() + actual call if they are pipelined. But you can even use the...

Larry•10/22/25, 12:01 PM

But, if I understand this correctly, the problem with using the same RpcTarget across requests is that you now have a resource on the server you have to worry about being left dangling, right?

LLarry But, if I understand this correctly, the problem with using the same RpcTarget a...

lambrospetrou•10/22/25, 12:03 PM

Well, at some point it's going to be teared down since the client worker will be evicted, but yes. If you are not careful it could end up consuming resources and resetting your DO eventually, if clients holding the RpcTarget don't terminate ever.

Ccloudkite Nice pattern to handle this is to have init return a RPCTarget with methods you ...

Yoh•10/22/25, 3:47 PM

We can't make fetch private though, so there would still be a way to bypass the init call for websocket upgrade requests, right? So there's at least one place we need to remember to call init or add the header, whichever method we use to pass in the entity id?

YYoh We can't make fetch private though, so there would still be a way to bypass the ...

cloudkite•10/22/25, 7:42 PM

Yup using a custom header for websockets upgrade request which I then store using serializeAttachment. This way don’t have to store on a variable on the DO and it can also store other context about the web socket connection

cloudkite•10/22/25, 7:48 PM

We have found it’s easier to reason about if DO instance variables are only things that can be set in constructor. Otherwise it’s easy to accidentally use a instance variable which hasn’t been set like entity ID

Ccloudkite Yup using a custom header for websockets upgrade request which I then store usin...

Larry•10/22/25, 8:00 PM

Why serializeAttachment rather than storage? Isn't the information @Yoh is talking about for the entire DO instance not just one WebSocket connection?

LLarry Why serializeAttachment rather than storage? Isn't the information @Yoh is talki...

cloudkite•10/22/25, 8:25 PM

Just found it convenient as in our case we also use the same header to pass info that’s specific to single connection

cloudkite•10/22/25, 8:27 PM

Tying it to a websocket also removes ability to use it from non-websocket context which feels cleaner

Yoh•10/22/25, 10:29 PM

I think in my case I'll keep it in DO storage, not an individual ws client connected to the DO. I might still want to know the original entity id even when I have no connected clients.

1984 Ford Laser•10/23/25, 4:44 AM

So I'm finally making the jump to SQLite in DOs and don't have any prior experience with SQL, are there any gotchas I need to be aware of when using things like VIEWs or TRIGGERs? The pipelines I'd be looking at would be at most hundreds of rows total in a table, using index columns where possible. Generated columns from JSON data also sounds interesting for some uses. My use cases would usually be write once-read a few times at most, wanna simplify how I'm storing and managing my relational data

1984 Ford Laser•10/23/25, 5:09 AM

Interesting I'll take a look. I don't want to add a bunch of extra complexity to my projects by havin to work with an ORM but if it isnt intrusive them Im down. Is it a heavy dependency?

James•10/23/25, 1:34 PM

drizzle has annoying bugs, I find it easier to stick to SQL at runtime

João Castro•10/23/25, 1:39 PM

Yup, and their types are wrong in some scenarios which can cause you headaches to debug in the future. I still find it to be good if you avoid the relational api, which is where most bugs appear

BBrayden Yes, reached out. They mentioned they'd get this merged in tomorrow or Monday.

João Castro•10/23/25, 1:41 PM

Btw, they still didn't merge this and return values for transactions remain broken with the DO driver

JJoão Castro Btw, they still didn't merge this and return values for transactions remain brok...

Brayden•10/23/25, 1:53 PM

Just pinged again

JJoão Castro Btw, they still didn't merge this and return values for transactions remain brok...

Brayden•10/23/25, 2:01 PM

Tests are running and merging for that PR right now

Ggnomesgames Yeah that's true, their type let you do invalid things. I do very basic CRUD so ...

James•10/23/25, 3:21 PM

I found good results using drizzle kit to define schema and migrations, but for runtime, I have a simple custom handler for casting types on return from the DO using the existing schema definitions in TS.

The only aspect one needs to be careful with raw SQL and this approach is consistent type casting on writes for fields like dates as numbers or string however you choose to store them.

James•10/23/25, 3:23 PM

The side perk to custom SQL is it's much much easier for an LLM to debug/refine code based on the SQL. It's a level of indirection with ORMs sometimes.

JJames The side perk to custom SQL is it's much much easier for an LLM to debug/refine ...

Larry•10/23/25, 4:34 PM

I find myself more and more optimizing my software design decisions based upon the cognizability of it to an LLM. A funny thing about my own code and LLM use is that if I have poorly named identifiers it can throw it into a doom loop. I called something "serialize" and there was JSON in the area and it constantly thought the output was a string, but it was really pre-processing before turning it into a string. Once I renamed it, the LLM had no trouble.

Aries•10/23/25, 4:38 PM

Is the lifetime of a DO predicable? How long until it kills itself?

Aries•10/23/25, 4:39 PM

I have a semi-short lived use case, for stateful requests, and don't feel like they need to store to a persistant store, but I'm worried they'll be prematurely killed.

Aries•10/23/25, 4:40 PM

Is it after 5s in-memory is wiped, or longer?

Aries•10/23/25, 4:40 PM

Can't find resources on this.