Is there any way to roll out a Durable Object that does not reset running instances? Even with gradu

Is there any way to roll out a Durable Object that does not reset running instances? Even with gradual deployments, eventually the Worker is reset because it's code is updated.

My ideal UX is I deploy, in-progress DOs finish, and then on the next alarm or next request, the new version comes in.

Kkyle Is there any way to roll out a Durable Object that does not reset running instan...

cloudkite•8/14/25, 7:43 PM

theres no option for that behaviour see https://community.cloudflare.com/t/durable-objects-state-during-lifecycle-events/319932/5

I would love if it was possible to have that behaviour as a flag or similar. But possibly theres tradeoffs or architectural reasons for why cloudflare hasn't implemented this

Ccloudkite theres no option for that behaviour see https://community.cloudflare.com/t/durab...

kyleOP•8/14/25, 7:54 PM

Do you know what throws the type error? Is it writing to storage? Or is it just any DO that has touched storage will exit with such?

Kkyle Do you know what throws the type error? Is it writing to storage? Or is it just ...

cloudkite•8/14/25, 8:03 PM

From the linked post: "but any old ongoing requests are able to send a response so long as they don’t throw an error first (e.g. by trying to use the storage API)."

Kkyle Is there any way to roll out a Durable Object that does not reset running instan...

Larry•8/14/25, 9:03 PM

What if a meteor hits a data center?

It adds complexity, but the general recommendation is to design your system (DOs and things that call them) such that it would be OK if the DO were to go away with no notice because there are many reasons why that might happen besides the roll out scenario you describe.

LLarry What if a meteor hits a data center? It adds complexity, but the general recomm...

kyleOP•8/14/25, 9:15 PM

I agree - it's not mission-critical if it goes away, but it's obviously a bad user-experience.

Kkyle I agree - it's not mission-critical if it goes away, but it's obviously a bad us...

gruntlord6•8/14/25, 9:18 PM

yes but something like a websocket reconnect or retrying the http request basically makes it some added latency. I know there are plans to make it so they do not reset when updated but they haven't said anything close to a timeline on that

LLarry What if a meteor hits a data center? It adds complexity, but the general recomm...

cloudkite•8/14/25, 11:11 PM

Agree doesn’t negate need to design in resilience via retries to your DO calls but reducing frequency that they can/will throw I think is still a worthy goal

Ggruntlord6 yes but something like a websocket reconnect or retrying the http request basica...

Larry•8/14/25, 11:25 PM

I hadn't heard that. That's good news if true.

Kkyle I agree - it's not mission-critical if it goes away, but it's obviously a bad us...

Larry•8/14/25, 11:41 PM

Other than potentially a bit of added latency, you can design it so the user doesn't experience any difference... although that is more complexity.

LLarry I hadn't heard that. That's good news if true.

gruntlord6•8/15/25, 12:06 AM

It was a thread here where someone from the team was tagged by another employee asking for it and they replied it's in the works but not possible atm and no timeline

wildbill•8/15/25, 3:24 PM

So i got question what does this mean I was on this website few hours ago and then this popped up

wildbill•8/15/25, 3:24 PM

Wwildbill So i got question what does this mean I was on this website few hours ago and th...

Isaac McFadyen•8/15/25, 3:26 PM

It means the developer has added a requirement to log in to access that page.

wildbill•8/15/25, 3:27 PM

Could it because the website not fully out yet and its in pre launch?

Wwildbill Could it because the website not fully out yet and its in pre launch?

Isaac McFadyen•8/15/25, 3:28 PM

Yes that's possible.

wildbill•8/15/25, 3:30 PM

OK thank you. The website is playshuffle.us

see translation•8/18/25, 6:05 PM

The DO docs describing their lifecycle is self contradictory in multiple places. Which of these is true?

see translation•8/18/25, 6:07 PM

I want to gaurantee my DO will survive for at least 30 seconds after the last request. Should I use

waitUntil

waitUntil

for this?

Ssee translation I want to gaurantee my DO will survive for at least 30 seconds after the last re...

geg•8/18/25, 6:33 PM

The 10 seconds is when the DO doesn't do any work, 70 seconds when it is doing work

see translation•8/18/25, 6:40 PM

I sometimes want to ensure the DO stays alive for at least 30 seconds (whether it has work or not), should I just use

waitUntil

waitUntil

/wait_untilwait_until . I'm using Rust

Ssee translation I sometimes want to ensure the DO stays alive for at least 30 seconds (whether i...

geg•8/18/25, 6:43 PM

you don't need waitUntil, when you do anything such as setInterval() it will stay active for up to 70 seconds, but you will pay for the full 70 seconds so not really worth doing that in any case

see translation•8/18/25, 6:45 PM

I don't (think?) I have setInterval in rust land. I was going to try to use waitUntil for that purpose. Perhaps a better thing to do would be to shell out to JS.

Ssee translation I don't (think?) I have setInterval in rust land. I was going to try to use wait...

geg•8/18/25, 6:47 PM

It's just an example, and waitUntil doesn't do anything, and it's most likely cheaper to just put state in storage rather than keep the DO active

see translation•8/18/25, 6:49 PM

The problem is that I'm using Worker KV (because DO storage value size is too small) which isn't globally consistent for ~30 seconds. So if the DO dies in this time, and restarts, it may fetch an outdated value.

see translation•8/18/25, 6:50 PM

So I want the DO to stay alive for at least 30seconds to ensure Worker KV's state has propagated.

Ssee translation The problem is that I'm using Worker KV (because DO storage value size is too sm...

lambrospetrou•8/18/25, 6:50 PM

If the reason you want the DO to stay alive is correctness, I suggest changing your algorithm somehow. The DO can die at any point due to unexpected issues for example.
What do you want to achieve exactly? Also, KV has up to 60s propagation, not 30s.

see translation•8/18/25, 6:53 PM

I'm storing a document in Worker KV which the DO manages. I switched to using worker KV because r2 cold reads took around 200ms on average, worker KV was faster.

Llambrospetrou If the reason you want the DO to stay alive is correctness, I suggest changing y...

see translation•8/18/25, 6:57 PM

I have been thinking about that, it would be nice to know how likely that is to happen. If it is rare enough I think the errors/inconsistencies could be manageable

Ssee translation I have been thinking about that, it would be nice to know how likely that is to ...

lambrospetrou•8/18/25, 6:58 PM

I still don't know what you are trying to solve by keeping it alive. So, the DO writes a new value to KV. What next? Why do you need the DO alive?

see translation•8/18/25, 6:59 PM

The DO is the source of truth for the document. When it boots up it loads the last value from Worker KV. But if it dies and reboots within 30 seconds of the last write to worker KV it might get an older version of the document.

see translation•8/18/25, 7:00 PM

clients connect to the DO and update the document (using the loro CDRT library)

Ssee translation The DO is the source of truth for the document. When it boots up it loads the la...

lambrospetrou•8/18/25, 7:03 PM

KV provides a read your own writes guarantee within the same colo, but in this case I wouldn't depend on that in case the DO boots in a different colo.
So, my suggestion if correctness matters is to store the KV value in the DO itself first, then in the KV so that DO is the source of truth. You can chunk it to fit the DO storage. Are you using SQLite DOs?

Or, at least you should keep an update_atupdate_at timestamp in the item stored in KV, and when the DO writes a new value to KV also write into its own storage that timestamp, so when you boot you will know if the value from KV is the latest or not. Unfortunately, though, even if you detect it's not the latest you won't be able to get the latest from KV maybe up to 60s.
So, again, if the DO is the source of truth, its own storage should be used and makes things much simpler to reason about.

see translation•8/18/25, 7:21 PM

I'm using DO KV store. Do you think SQLite would be better? I have some semi-relational data.

I am currently storing the document "updates" in the DO KV. The updates can be applied idempotently, so I could do a thing where I apply them to the document fetched from the Worker KV to ensure it's the latest version

see translation•8/18/25, 7:21 PM

I do have a "updated_at" in the Worker KV metadata.

see translation•8/18/25, 7:23 PM

My first impression was that storing binary blobs in the SQLite would be... not great?

see translation•8/18/25, 7:27 PM

@lambrospetrou My documents can be up to ~3MB but most are around a couple hundred KB. Do you think this would work better in SQLite? Or faster?

Ssee translation @lambrospetrou My documents can be up to ~3MB but most are around a couple hundr...

lambrospetrou•8/18/25, 7:28 PM

In SQLite DOs each row can hold close to 2MB. In a personal project I just chunk large items into multiple rows of 1.5MB each. 3MB should be totally OK to store in SQLite DOs.

see translation•8/18/25, 7:32 PM

Interesting, what sort of schema are you using? Do you write over existing blobs when they change? Or do you just add a new row with the changed version?

see translation•8/18/25, 7:33 PM

@lambrospetrou I'm curious how a row in the schema indicates it a partial blob, or like the Nth blob.

Ssee translation Interesting, what sort of schema are you using? Do you write over existing blobs...

Larry•8/18/25, 7:40 PM

Note, even with SQLite-backed DOs, you can still use the DO KV API. They just use a hidden table. That said, with chunking, I would lean towards a compound primary key (id, chunk)(id, chunk) if you went with a replacement model. You don't need to use all of the segments in order for it to take advantage of the automatic primary key index. So, ...WHERE id=<some-id>...WHERE id=<some-id> will return all of the chunks whether there is one or many.

Ssee translation @lambrospetrou I'm curious how a row in the schema indicates it a partial blo...

lambrospetrou•8/18/25, 7:46 PM

See https://github.com/lambrospetrou/tiddlyflare/blob/2f6cd98eab2d77f8319cca21922dea3a8ca41d9a/src/durable-objects.ts#L232 from one of my projects.
This is the read part that makes sure I only read complete versions with all their chunks written: https://github.com/lambrospetrou/tiddlyflare/blob/2f6cd98eab2d77f8319cca21922dea3a8ca41d9a/src/durable-objects.ts#L426

GitHub

tiddlyflare/src/durable-objects.ts at 2f6cd98eab2d77f8319cca21922de...

Hosting platform for TIddlyWikis. Contribute to lambrospetrou/tiddlyflare development by creating an account on GitHub.

LLarry Note, even with SQLite-backed DOs, you can still use the DO KV API. They just us...

Jehu•8/18/25, 9:28 PM

Is the pricing for SQLite-do k/v api row-based? Or is it the same as non-SQLite-do k/v?

JJehu Is the pricing for SQLite-do k/v api row-based? Or is it the same as non-SQLite-...

lambrospetrou•8/18/25, 10:30 PM

Separate, and yes it's row based and storage used based: https://developers.cloudflare.com/durable-objects/platform/pricing/#storage-billing

Burrito•8/19/25, 1:20 PM

DO SQLite has a minimum of ~4 KB if you store anything at all, are those 4 KB charged?

BBurrito DO SQLite has a minimum of ~4 KB if you store anything at all, are those 4 KB ch...

gruntlord6•8/19/25, 1:31 PM

anything past the free limit is charged IIRC, so you won't be charged for 4kb but you would be charged for every 1gb over the free tier