My point is, in all respect, if what they promise is right and they succeed the way they are rushing

My point is, in all respect, if what they promise is right and they succeed the way they are rushing right now, Cloudflare durable objects may become the blackberry of their iphone.

Pplgingras88 My point is, in all respect, if what they promise is right and they succeed the ...

João Castro•11/3/25, 2:18 PM

Its very rare that you see competition taking over in a sweep like it happened there, and this does not look like a paradigm shift, just some welcome competition in the space

Pplgingras88 Of course, but they also offer a cloud solution or even using CloudFlare and Dur...

Larry•11/3/25, 2:35 PM

using CloudFlare and Durable objects under the hood

The notion of "write once deploy anywhere" is appealing but it's extremely challenging from many dimensions (performance, DX, etc.). Think of it as a tradeoff between portability and avoiding leaky abstractions. This would be super-leaky and it would always lag DO features.

History is littered with these sort of things that sound great at first but get in the way more than help: The Serverless Framework, SDN (software-defined network), ORMs to a degree, Xamarin (although it pivoted and became .NET 2.x+), AWS Event Bridge, Azure Event Grid, etc.

I was a consultant for a huge project at Intuit to define their own least common denominator programming language that would compile down to Java or .NET. It took years and while they were trying to make it work well, they didn't release any new products and few new features because everyone was ordered to use this new programming language and it was always a few months from being ready. In the end, they gave up but they never got back those 2-3 years of wasted effort and near zero feature velocity.

That tamed my desire for portability, and I'm much happier because of it.

João Castro•11/3/25, 2:44 PM

Also choosing a product goes beyond one specific feature. Trust for example (both in terms of cybersecurity and longevity of the product/company) can play a big role. One of the biggest reasons I like Cloudflare as a platform is because of the direction that it goes towards and the team behind it rather than one specific thing that I like or dislike, because I think this is more likely to provide consistent value over time

João Castro•11/3/25, 2:48 PM

Its very easy to make something better in a single dimension, but designing it to be great as a whole package is very hard

JJoão Castro Also choosing a product goes beyond one specific feature. Trust for example (bot...

Larry•11/3/25, 2:50 PM

I love the way you think

plgingras88OP•11/3/25, 3:27 PM

Absolutely — I agree with much of what’s been said. Cloudflare DOs bring strong advantages, such as automatic geo-routing to the nearest instance, security, infra, and more. Rivet, on the other hand, gives you the flexibility to stay within that ecosystem or branch out to other platforms to overcome limitations like tight resource caps or vendor lock-in.

What really stands out is Rivet’s clean API and documentation. It’s impressive, offering several capabilities Cloudflare doesn’t (at least not yet). Rivet won’t replace DOs anytime soon, but projects like this are healthy for the ecosystem. Brayden built Outerbase and it pushed the industry forward, to everyone’s benefit. While I don’t expect Rivet to follow the exact same trajectory, I do think it sends a strong message that should motivate the DO team to address current constraints and refine their trade-offs.

plgingras88OP•11/3/25, 3:37 PM

Also, i see Rivet like Better-auth. This kind of project can be surprising despite being handled by few people. Great new projects take lessons from existing solutions and get the best out of them without dragging their debts.

Burrito•11/3/25, 4:09 PM

Idk about the trust tbh. With Cloudflare, it seems like you are just one failed payment away from having your account locked and getting stuck in support limbo.

ALECKS•11/3/25, 5:20 PM

How are people managing external DB connections in DO's... specifically, I'm really struggling to find a clean pattern of when/where to close db connections (for ex to Postgres)
Initially I thought I'd just get away with connecting at the start of a request/rpc, and disconnecting at the end. But this can get pretty messy (if there are a lot of early returns / throws, your code gets peppered with disconnect calls. Sure you can wrap in a parent fn, but still feels ugly).
Ideally I could use a pool, keep it open to serve multiple (possibly concurrent) requests, but I have no idea when to close it. This is where an eviction/hibernation hook would come in handy.

Anyone have any good patterns here?

AALECKS How are people managing external DB connections in DO's... specifically, I'm rea...

Hard@Work•11/3/25, 5:24 PM

I would use Hyperdrive

Cloudflare Docs

Hyperdrive

Hyperdrive is a service that accelerates queries you make to existing databases, making it faster to access your data from across the globe from Cloudflare Workers, irrespective of your users' location.

HHard@Work I would use [Hyperdrive](https://developers.cloudflare.com/hyperdrive)

ALECKS•11/3/25, 5:25 PM

I am, but I don't see how this solves my issue. as far as my code is concerned, HD just gives me a connectionString. I still need to have the pg driver connect/disconnect, no?

ALECKS•11/3/25, 5:25 PM

unless you're saying with HD, I don't need to explicityly disconnect, which would be something.

AALECKS unless you're saying with HD, I don't need to explicityly disconnect, which woul...

Hard@Work•11/3/25, 5:26 PM

Yeah, since the connection is within the runtime, IIRC the connection is just terminated automatically, and the pool doesn't disconnect

Hard@Work•11/3/25, 5:26 PM

Not sure if I worded that right, sec

Hard@Work•11/3/25, 5:27 PM

Basically, with Hyperdrive, you don't need to disconnect manually, since you are connected to the Hyperdrive pool, not directly to your Database.

ALECKS•11/3/25, 5:28 PM

Yes I understand the actual db is not involved here, I'm specifically talking about the connection from worker/do to Hyperdrive.

ALECKS•11/3/25, 5:28 PM

Are there docs anywhere that say you don't need to disconnect a db driver from Hyperdrive?

AALECKS Are there docs anywhere that say you don't need to disconnect a db driver from H...

Hard@Work•11/3/25, 5:31 PM

Maybe try in #hyperdrive

redsquare•11/3/25, 6:59 PM

I am getting a 500 when trying to use the data studio, the same sql works fine when I run it inside the DO "SELECT * FROM sqlite_master"

KKam I have some durable objects that run an alarm on a minute by minute cadence. I h...

Larry•11/3/25, 7:50 PM

Re set it in the constructor. That will get called next time it's accessed after the deploy.

Justin Schroeder•11/3/25, 8:21 PM

I want to publish an npm package for use in cloudflare projects that includes a pre-written durable object. End users would install the package, add a couple lines to their

wrangler.jsonc

wrangler.jsonc

(unless there is a magic way to not do this step) — and viola they have this particular durable object working.

I have 2 questions:

This import
```
import { DurableObject } from "cloudflare:workers";
```
```
import { DurableObject } from "cloudflare:workers";
```
assumes
```
cloudflare:workers
```
```
cloudflare:workers
```
can be resolved, but of course that is only importable with a build tool like vite. Should I bundle cloudflare:workers as an internal dependency? What would the CF team recommend?
How does the
```
class_name
```
```
class_name
```
property of wrangler's config work? Can it resolve a class that is in a dependency?

KKam Thanks Larry, I had considered something along those lines. Wouldn't that requir...

Larry•11/3/25, 8:24 PM

True. I hadn't thought of that. What if you set the new alarm at the beginning of your handler for the current alarm instead of at the end?

JJustin Schroeder I want to publish an npm package for use in cloudflare projects that includes a ...

Kevin•11/3/25, 8:38 PM

cloudflare:workers

cloudflare:workers

comes from

worker-configuration.d.ts

worker-configuration.d.ts

file that gets generated from config using

npx wrangler types

npx wrangler types

. Durable object is just a typescript class that you import to your project and add to your wrangler config.

Justin Schroeder•11/3/25, 8:40 PM

thats where typescript gets it, but it has a concrete implementation too doesnt it?

Kevin•11/3/25, 8:44 PM

I don't know the details about the runtime but since class_name must be the name of the class I guess thats how they know it.

JJustin Schroeder I want to publish an npm package for use in cloudflare projects that includes a ...

Hard@Work•11/3/25, 8:46 PM

You should mark it as an external dependency. Treat it like imports to

node:

node:

-prefixed packages

HHard@Work You should mark it as an external dependency. Treat it like imports to `node:`-p...

Justin Schroeder•11/3/25, 8:49 PM

Thanks, will do. As for the

class_name

class_name

property in the config, how does that resolve to the actual class? Seems a bit magical — would love to understand that part more.

JJustin Schroeder Thanks, will do. As for the `class_name` property in the config, how does that r...

Hard@Work•11/3/25, 8:53 PM

It's the name of the export in the Worker's

main

main

file. So for example, if your package exports a DO named

SuperDO

SuperDO

, it would look something like this:

// src/index.ts, or whatever their main file is
export { SuperDO } from "justin_utils"; // class_name: SuperDO
export { SuperDO as MyMadeUpDOClassName } from "justin_utils"; // class_name: MyMadeUpDOClassName

// src/index.ts, or whatever their main file is
export { SuperDO } from "justin_utils"; // class_name: SuperDO
export { SuperDO as MyMadeUpDOClassName } from "justin_utils"; // class_name: MyMadeUpDOClassName

Justin Schroeder•11/3/25, 9:26 PM

ok excellent. thank you for that clarification

Justin Schroeder•11/3/25, 9:27 PM

Last question (for now

) is there any way to "extend" a

wrangler.jsonc

wrangler.jsonc

from some base — sort of like a

tsconfig.json

tsconfig.json

JJustin Schroeder Last question (for now 😂) is there any way to "extend" a `wrangler.jsonc` from ...

Hard@Work•11/3/25, 9:32 PM

No, there is not

1984 Ford Laser•11/3/25, 11:00 PM

I just got the following warning in a Worker that creates a bunch of DO stubs in quick succession (and doesn't explicitly dispose of them). My understanding from reading the docs was that the disposal is technically optional as the runtime will do its best to dispose of them when necessary. Is there a certain limit I'm hitting where I need to start explicitly disposing?

An RPC stub was not disposed properly. You must call dispose() on all stubs in order to let the other side know that you are no longer using them. You cannot rely on the garbage collector for this because it may take arbitrarily long before actually collecting unreachable objects. As a shortcut, calling dispose() on the result of an RPC call disposes all stubs within it.

An RPC stub was not disposed properly. You must call dispose() on all stubs in order to let the other side know that you are no longer using them. You cannot rely on the garbage collector for this because it may take arbitrarily long before actually collecting unreachable objects. As a shortcut, calling dispose() on the result of an RPC call disposes all stubs within it.

11984 Ford Laser I just got the following warning in a Worker that creates a bunch of DO stubs in...

Larry•11/3/25, 11:48 PM

If you use

using

using

, the local resource is disposed but not the remote one. This is worrisome because it keeps the remote in wall clock billing mode. I don't think it matters, but I'm curious, are you doing DO to DO or are you using RpcTarget on the caller side?

LLarry If you use `using`, the local resource is disposed but not the remote one. This ...

1984 Ford Laser•11/3/25, 11:52 PM

It's RpcTarget but I definitely don't use

using

using

. Lemme add that in and see how I go

1984 Ford Laser•11/3/25, 11:53 PM

In this specific case it's only a single RPC call too so it doesn't even need to be a full stub necessarily. My VsCode autocomplete just does its own thing

HHard@Work You should mark it as an external dependency. Treat it like imports to `node:`-p...

Larry•11/3/25, 11:53 PM

I don't do this and it still seems to work. Where are you saying to specify this and how? I've never done it for a node:* dependency either, but my plain node packages go back to before they had node:*, I think.

LLarry I don't do this and it still seems to work. Where are you saying to specify this...

Hard@Work•11/3/25, 11:55 PM

I guess maybe it automatically guesses if deps are external or not? I meant more, if it throws errors because it can't find

cloudflare:whatever

cloudflare:whatever

, then you should mark it as external. If it already works, no need to change it

Burrito•11/4/25, 12:05 AM

(Also this only matters if your package project is built with a bundler)

LLarry If you use `using`, the local resource is disposed but not the remote one. This ...

1984 Ford Laser•11/4/25, 12:08 AM

This fixed it thank you, now I definitely need to go through and add

using

using

to like 20 different Workers

BBurrito (Also this only matters if your package project is built with a bundler)

Larry•11/4/25, 12:32 AM

Ahh, that makes sense. I use tsc now to prep for publishing to npmjs.com

LLarry As a thought... based upon your use of "additional work after returning", what a...

Need_Not•11/4/25, 7:25 AM

Wow Larry you put in a lot of work. As for the rquestion. The DO is like the controller and optimistic state which is called from a normal worker. So the functions have to return so that the worker can return back to the user.

One example is if old data needs to be purged to make room for new data. I simply save which data that is, set the alarm and then return back to the user. Some time later the alarm will fire and delete the data. At the same time the DO is meant to only be optimistic state so after inactivity or no longer relevant data it should just self destruct.

Need_Not•11/4/25, 7:46 AM

I'll give these a go

NNeed_Not Wow Larry you put in a lot of work. As for the rquestion. The DO is like the con...

Larry•11/4/25, 11:03 AM

Wow Larry you put in a lot of work

True, but a lot of what I'm doing right now is cleaning up and open-sourcing stuff we already use. It still requires cleanup, more tests, and documentation. As a side effect, we've fixed some bugs, improved the internal DX, and made it easier for our devs to work.

João Castro•11/4/25, 6:52 PM

About the 6 simultaneous outgoing connections limit, are there any plans to make it easier to work around it? I remember reading somewhere that 6 was chosen as the limit because its the default for some browsers, but acting as a server there are some real-world scenarios where we would benefit from having a higher limit.

Right now the options seem to be calling a worker through HTTP (so they don't share the resources and limits) or spawning a new DO instance, which is what I'm doing currently. Both sound very inefficient and can add unnecessary complexity for such a simple thing.

João Castro•11/4/25, 6:54 PM

This is a very noticeable bottleneck when dealing with Queues, for example

Pplgingras88 Absolutely — I agree with much of what’s been said. Cloudflare DOs bring strong ...

Nathan•11/4/25, 8:05 PM

We have automatic geo-routing at Rivet too. Additionally – a lot of folks run RivetKit on Durable Objects since Cloudflare provides unique features or run a hybrid of Cloudflare for managed & Rivet on-prem. Happy to chat in our Discord if you have any further questions to keep this channel on topic!

kchro3•11/4/25, 10:22 PM

hey folks, was poking around @Brayden 's actors library and thought it would be worth asking here.

suppose i have a UserDO where i want to store event logs per user. the id would be the user ID, so there would be a SQLite table representing every user event. i liked what the actors framework was doing, where you could have a dedicated "tracker" instance that would update on create / delete of every DO so that you can scan the other DOs.

i was also thinking that it could be helpful to:

support partitioning so that the users are collocated on the same tracker (e.g. if it's a b2b saas application, maybe you want the users to be partitioned by org so each tracker's ID would be org+tracker suffix; or maybe you want to collocate the tracker DO by geo)
add columns to the tracker's users (e.g. if a user has properties like age, createdAt, etc.), so that you could query them later
support repartitioning so that if the durable object for one tracker runs out of memory, it could fan out with a master-slave architecture.

have folks run into anything like that before or have thoughts on better approaches?

// src/index.ts, or whatever their main file is export { SuperDO } from "justin_utils"; // class_name: SuperDO export { SuperDO as MyMadeUpDOClassName } from "justin_utils"; // class_name: MyMadeUpDOClassName

An RPC stub was not disposed properly. You must call dispose() on all stubs in order to let the other side know that you are no longer using them. You cannot rely on the garbage collector for this because it may take arbitrarily long before actually collecting unreachable objects. As a shortcut, calling dispose() on the result of an RPC call disposes all stubs within it.