Are you not able to spin up more instances? When a container is shown as inactive in the dash I dont

Are you not able to spin up more instances? When a container is shown as inactive in the dash I dont think it actually exists anymore, and should disappear on its own eventually

11984 Ford Laser Are you not able to spin up more instances? When a container is shown as inactiv...

Paul•10/29/25, 7:54 PM

I'm seeing them just stick around, for 4 days now, have't tested any longer.

1984 Ford LaserOP•10/29/25, 7:54 PM

Yeah they dont still exist, they arent taking up any space. I think youre stressing over nothing

Paul•10/29/25, 7:55 PM

Well if you are building a real SaaS, and making claims about the way ephemeral compute environments actually dispose of data after use, you want to be 100% sure

Paul•10/29/25, 7:56 PM

The State = Inactive actually leads me to belive these instance could actually be re-hydrated, so their state must still exist

PPaul The State = Inactive actually leads me to belive these instance could actually b...

1984 Ford LaserOP•10/29/25, 7:57 PM

Because you can reboot them from scratch

1984 Ford LaserOP•10/29/25, 7:58 PM

Here's some docs on this topic: https://developers.cloudflare.com/containers/platform-details/architecture/#container-shutdown

Persistent disk
All disk is ephemeral. When a Container instance goes to sleep, the next time it is started, it will have a fresh disk as defined by its container image. Persistent disk is something the Cloudflare team is exploring in the future, but is not slated for the near term.

Persistent disk
All disk is ephemeral. When a Container instance goes to sleep, the next time it is started, it will have a fresh disk as defined by its container image. Persistent disk is something the Cloudflare team is exploring in the future, but is not slated for the near term.

Paul•10/29/25, 7:58 PM

Ok, so it's not like "paused" where the container instance is somehow frozen

PPaul Ok, so it's not like "paused" where the container instance is somehow frozen

1984 Ford LaserOP•10/29/25, 7:59 PM

No it delete

Paul•10/29/25, 8:01 PM

Ok thanks @1984 Ford Laser for the clarification. I just wanted to make sure I wasn't going to rack petabytes of frozen container instances just waiting to be re-hydrated. But sounds like that is not how it works, anything in a State of Inactive is actually just totally deleted.

PPaul Ok thanks @1984 Ford Laser for the clarification. I just wanted to make sure I w...

1984 Ford LaserOP•10/29/25, 8:04 PM

You can track your active usage in the Metrics tab of the container dash

11984 Ford Laser You can track your active usage in the Metrics tab of the container dash

Paul•10/29/25, 8:06 PM

Yes the usage shows what I expect, just paying for the execution time. I just want to be 100% sure I know how the data is handled for these ephemeral github runner use cases, so I can explain it to others. I can imagine this could be a security question in a architecture review/deep dive

Paul•10/29/25, 8:53 PM

Hey @Gabi | Containers and team - follow-up from my ephemeral GitHub runners discussion.

Confirmed Understanding:

Container disk is ephemeral and deleted on stop (thanks for clarifying!)

Only paying for active execution time

Inactive containers don't consume storage

Remaining Question:
While the container instances clean up properly, the Durable Object instances themselves accumulate in the namespace indefinitely.

Current Pattern:

Each job:

idFromName('job-{jobId}')

idFromName('job-{jobId}')

→ unique DO created

Container runs → stops → DO hibernates (but persists)
At 1000 jobs/day → 30K DOs/month → 365K DOs/year**Dashboard shows all these inactive DOs forever** (see screenshot from last week).**Questions:**
Is this accumulation pattern expected/acceptable for ephemeral workloads?
Do hibernated DOs (with empty storage via deleteAll()) have any cost or limits?
Should I implement DO pooling to reuse ~100 DOs across all jobs?
Or just call storage.deleteAll() + deleteAlarm() in onStop() and not worry about it?For context: GitHub Actions runners are true ephemeral workloads - each job should leave zero trace. Want to ensure I'm architecting this correctly for production SaaS.Current scale: 10 concurrent, but could scale up to 100-500 as usage grows.Thanks!

lambrospetrou•10/29/25, 8:59 PM

Do hibernated DOs (with empty storage via deleteAll()) have any cost or limits?

No.

You cannot remove DOs from the namespace list at the moment. It's not a containers thing, it's a DOs thing.

PPaul Hey @Gabi | Containers and team - follow-up from my ephemeral GitHub runners dis...

1984 Ford LaserOP•10/29/25, 8:59 PM

Are you storing anything in the DO storage currently? If you dont utilise storage in any way currently then they wont incur any storage costs at all

11984 Ford Laser Are you storing anything in the DO storage currently? If you dont utilise storag...

Paul•10/29/25, 9:13 PM

I don't think so but all of this is kind of magical so I don't actually always know what's happening behind the scenes, like are the container logs being stored as part of the DO storage? I don't know.

I'm coming form a cloud background, where I've seen lots of users get burnned becuase of massive CloudWatch logs bills for example.

PPaul I don't *think* so but all of this is kind of magical so I don't actually always...

1984 Ford LaserOP•10/29/25, 9:15 PM

Cloudflare products and the runtime definitely feel like magic sometimes. Logs don't cost anything to just have them emitted, there are products like Workers Analytics Engine or Logpush that do cost money, but simply having them be logged and viewing them live is free

Paul•10/29/25, 9:18 PM

Will I run into scalability issues, like just paging or searching my DO's if I have potentially millions of them? If they are basically ALL not used, it just seems wasteful. This is why I was thinking I might want to implement so kind of Pooling scheme, where I have a fixed number of DOs that get reused to spin up new container instances, this way I only ever have like 100 DOs.

PPaul Will I run into scalability issues, like just paging or searching my DO's if I h...

1984 Ford LaserOP•10/29/25, 9:23 PM

Yeah I wouldn't ever worry about having too many instances, especially if you aren't using any storage in them. There isn't any account limits to the number of DO instances you spin up, and theoretically you can scale up millions instantly. There's some mental blocks to jump over with DOs, I would focus on building before worrying about runtime stuff that basically isn't an issue

PPaul Will I run into scalability issues, like just paging or searching my DO's if I h...

Larry•10/30/25, 3:00 PM

I think there is a small mental model mismatch going on here. I never get the full list of DOs and walk it for just the reason you mention. Rather, the way I think everyone does it, is we keep a list of active ones somewhere else. This can either be a stringified version of the uniqueId, or more commonly, folks use getByName or the two-step equivalent of that (get the id by name, then get the stub from that id). The "name" is something we already use for other purposes in most cases. For instance, I use Stytch which creates a unique id for each organization in our SaaS product. That's the "name" I use for my OrgDO. How does that sit with you?

LLarry I think there is a small mental model mismatch going on here. I never get the fu...

Paul•10/30/25, 3:35 PM

Thanks Larry, this is inline with my understanding of best practices, thinking critically about the "partitioning" strategy for DO, basically how you uniquely name DOs. For named/identified things like organizations, users, cities, etc. this is perfect. The thing I'm struggling with is best practice for using DO's with single use identifiers (like a job run id). I think I just need to accept there will be lots of DO's lingering around forever or use a pool of 100x DOs like "runner-001", "runner-002", etc. and then just reuse those, so my OCD isn't triggered

My spider sense is telling me be careful about letting millions of resources just pile up, it could come back to bite you - but I get lots of feedback on this forum saying "don't worry about it"

PPaul Thanks Larry, this is inline with my understanding of best practices, thinking c...

Paul•10/30/25, 3:40 PM

Or maybe I need to think more about the partition key that actually might make sense for this use case, the account and repo and workflow name for example could be concatenated to create a unique slot. I could either use that or a hash of that to create a unique identifier. - this is probably the way...

Larry•10/30/25, 3:55 PM

I think you are aligned now. Just keep in mind that you'll have to keep that list of active ones somewhere. When you think one should go away forever, just make absolutely sure it's empty of data. Then delete that key from your outside maintained list. You could have a cron job somewhere that use the Cloudflare API to get the full list and crawl it to check that they are absolutely empty. That's not as trivial as it should be because there are some edge cases. I don't have them in my head but I bet someone else in this conversation does.

LLarry You can sense if that is happening by storing a counter in global context. That ...

hollowaya•10/30/25, 9:58 PM

Hey, did you mean that a value in globalThis will be the same if the DO instances are running in the same isolate?

Hhollowaya Hey, did you mean that a value in globalThis will be the same if the DO instance...

Larry•10/30/25, 10:15 PM

Exactly. Surprising but true. I used a Set of instance ids for my experiments. It was not unheard of but it was rare-ish for there to be two. I don't think I ever saw three. I stopped monitoring years ago because I stopped pre-loading stuff into instance variables and I now retrieve from storage just what I needed to handle that one Request/Message. It sounds inefficient, but it's not with an embedded database that has a cache... and it's more memory efficient. It's also cost effective because reads are dirt cheap.

LLarry Exactly. Surprising but true. I used a Set of instance ids for my experiments. I...

hollowaya•10/30/25, 10:19 PM

Amazing, thanks for explaining, we just added an id/counter to prod and hopefully it will shed light on our problem haha

Larry•10/30/25, 10:39 PM

Is the DurableObject base class in a repo somewhere that can look at?

LLarry Is the DurableObject base class in a repo somewhere that can look at?

1984 Ford LaserOP•10/30/25, 10:56 PM

Poking around

workerd

workerd

a bit, maybe this is of use? https://github.com/cloudflare/workerd/blob/aee8c81a780095b66f80c424545eb5a97a062452/src/workerd/api/workers-module.h#L43

11984 Ford Laser Poking around `workerd` a bit, maybe this is of use? https://github.com/cloudfla...

Larry•10/30/25, 11:13 PM

Thanks. I don't know C++ but this is the "interface" essentially. The "implementation" was in a link on the side of the page you took me to so thanks again. It looks like all it does it set

this.ctx

this.ctx

and

this.env

this.env

but there is some other C++ foo I don't follow if anyone knows?

1984 Ford LaserOP•10/30/25, 11:14 PM

I found other references to DurableObjectBranded that might also be of use

Larry•10/30/25, 11:30 PM

I think the implementation is here: https://github.com/cloudflare/workerd/blob/main/src/workerd/api/workers-module.c%2B%2B#L25. It's a c++ file and it does what I said. I'm guessing the other c++ foo is just allocating memory and housekeeping. I think I have what I need. Thanks again for the help.

GitHub

workerd/src/workerd/api/workers-module.c++ at main · cloudflare/wo...

The JavaScript / Wasm runtime that powers Cloudflare Workers - cloudflare/workerd

John Spurlock•10/31/25, 4:30 PM

recent message from over in the d1 channel that might be of interest to folks here eagerly awaiting DO storage read replication...

d1-database

Need_Not•11/1/25, 8:30 AM

how much slower is it to use sql reads directly instead of keeping an in memory

Map

Map

copy of the table to look up by PM?
Obviously in memory is going to be effectively instant but it's already a hassle to update data in both sql and in memory.

NNeed_Not how much slower is it to use sql reads directly instead of keeping an in memory ...

lambrospetrou•11/1/25, 9:17 AM

If you use SQLite DOs there is already an in-memory cache of your reads, so the difference should be negligible. Using in-memory state could make sense within the context of a single request but otherwise it should be fast enough.

NNeed_Not how much slower is it to use sql reads directly instead of keeping an in memory ...

Larry•11/1/25, 9:36 AM

I switched away from keeping instance variables (with a rare exception) a year or so ago and it was one of my best design decisions. We noticed no bump in cost because reads are so cheap and as you pointed out, you already need to do the writes. We noticed no performance penalty. We didn't know how to measure it but we suspect that cold starts got faster by a few ms, although we now believe that's driven by the size of the SQLite storage.

ALECKS•11/1/25, 2:21 PM

Has there been any discussion/consideration around adding some built in lifecycle hooks to Durable Objects? For example, these two would be super helpful:

async onWake() - called automatically after a DO is instantiated
async onEvict() - called automatically right before a DO is evicted

My current pattern is to call onWake() myself, but every time the DO is accessed, and it has a flag internally to check if it's already awake. Works, but annoying ergonomics.

For evict, this is trickier, I currently do not know how to catch this. Having this OOTB would allow us to keep DB connections open between multiple requests while the DO is active and serving. Right now, I have to open and close a pg connection for each request which isn't ideal.
I suppose I could use a setTimeout and close when that expires, and reset the timeon on each new request... but that also feels weird.

How are people solving this pattern?

Sstickman `onWake` is essentially equivalent to calling your `constructor`? I remember the...

ALECKS•11/1/25, 2:25 PM

The big problem with that is doing any sort of async work in the constructor, like initializing state with same data from a postgres call

Sstickman you can do async work inside `blockConcurrencyWhile`

ALECKS•11/1/25, 2:26 PM

in a constructor?

ALECKS•11/1/25, 2:27 PM

Oh yeah.. hmm even the docs show it: https://developers.cloudflare.com/durable-objects/reference/in-memory-state/

ALECKS•11/1/25, 2:28 PM

ok, that's great, missed this before

AALECKS ok, that's great, missed this before

Larry•11/1/25, 3:43 PM

BTW, I've been using Durable Objects for about 4 years now and it was just last week when I learned something new about it.

LLarry BTW, I've been using Durable Objects for about 4 years now and it was just last ...

ALECKS•11/1/25, 3:46 PM

hey since you have so much experience, curious... for DOs that need an identity, for ex, let's say you have a DO per tenant

ctx.DO.getByname(tenantId)

ctx.DO.getByname(tenantId)

since you can't know the state ahead of time, is this really the only way to call methods on it:

// first, tell it who it is
await stub.init(tenantId)

// then do the work
await stub.doStuff()

// first, tell it who it is
await stub.init(tenantId)

// then do the work
await stub.doStuff()

or is there some clever way to initialize a worker once, and not have to redo it every time?

AALECKS 🙂 hey since you have so much experience, curious... for DOs that need an ident...

James•11/1/25, 3:59 PM

I send the id as metadata on every rpc call since any given worker may or may not be initializing the DO given its a singleton.

AALECKS 🙂 hey since you have so much experience, curious... for DOs that need an ident...

Larry•11/1/25, 6:17 PM

You can't know it's name without doing something like James suggests or what you suggest with

.init

.init

. However, depending upon why you need it, you may just be able to get away with using

ctx.id

ctx.id

That address is always accurate and always present. It's that 64 hex digit string that you would use in

get(idFromString(id))

get(idFromString(id))

or maybe it's the actual id object so you'd use

get(id)

get(id)

. I let TypeScript tell me when I get it wrong and I'm on mobile so can't try it.

Most of the time, I only need that because I'm using it as the return address for something like @lumenize/proxy-fetch.

There is also another trick I use essentially every time now. I almost always use WebSockets from a browser. My

routeDORequest

routeDORequest

expects this format for URLs,

[/${prefix}]/${doBindingName}/${doInstanceNameOrId}[/path...]

[/${prefix}]/${doBindingName}/${doInstanceNameOrId}[/path...]

. That's always how my WebSocket upgrades happen so I always have the name in that

doInstanceNameOrId

doInstanceNameOrId

slot. There is also an undocumented header (I just added it and it's on my to-do list to document) that has it as well, in case you don't want to parse the URL again inside your DO's fetch handler. Since you have to use fetch for WebSockets and I'm always using WebSockets, I always have those.

AALECKS 🙂 hey since you have so much experience, curious... for DOs that need an ident...

lambrospetrou•11/1/25, 7:55 PM

Personally, I either do the

init()

init()

approach, or send the identifier all the time if the original request also contains the information to derive it.

Persistent disk All disk is ephemeral. When a Container instance goes to sleep, the next time it is started, it will have a fresh disk as defined by its container image. Persistent disk is something the Cloudflare team is exploring in the future, but is not slated for the near term.