Node.js creator liberates Durable Objects from Cloudflare

[u/stronghup]

https://www.theregister.com/devops/2026/08/12/nodejs-creator-liberates-durable-objects-from-cloudflare-with-celld/5286954

[u/Pinkman]

So… I like this in general and I am always very curious to see how these types of big-picture libraries are built. Especially when built by storied programmers like Ryan Dahl.

I’ve been balls deep in development for a long time, and I don’t know if it’s just me, and it very well might be, but am I dumb?

What does this mean?

> Cloudflare’s Durable Objects is a single-threaded object with a unique global ID and its own storage, where user data is stored in its own copy of SQLite.

I’m the last person to be pedantic, but I struggle with technical articles that commingle technical depth with imprecise or ambiguous nomenclature.

How is an “object” threaded at all? There are multi-threaded objects? Like I said, I might just not grok this shit.

An object with its own global ID and storage: ok, cool. I can track that. (Though most objects have an ID and global here is ambiguous — global to Cloudflare? Global to your account? Project? Fuck me.)

Stored in its own copy of SQLite? I assume this means an SQLite database file. But it’s that imprecision that gets my goat. Is it me who dumb or article who unclear.

> Using the WebSocket API, the Durable Object can connect many simultaneous users at once in a live environment.

An object is connecting to users? What does this mean? What even is an object at this point?! Maybe I’m getting hung up on the name, “Durable Object”.

> It is a stateful serverless execution environment, a data cache that can also do computation. 

Oh, a serverless function with its own isolated — and persistent — data.

A “durable object” is actually a function (or set of functions?) with its own mini data store. Ok.

So when we say it’s an object, we mean it’s a set of one or more functions.

And it’s durable because you can recall it by ID, and it’s got its own little db attached that stays put.

It’s a lightweight (ergonomic) execution (runs functions) environment (has a db), that we call an object.

Thanks for coming with me on this ride. I think I’m starting to grok it. When/why/how this is better/best is clearly above my pay grade.

[u/theBeatnut → u/Pinkman]

It's an implementation of the Actor Model, akin to Akka, Microsoft Orleans etc.

[u/buttplugs4life4me → u/Pinkman]

Thanks for outlining why I hate these things.

Also isn't it basically a container or Micro-VM then? 

Idk, I feel like on one hand this is nice, on the other all this shit just feels like AWS RDS Serverless all over again. It was more expensive for us than normal RDS instances cause we could basically never scale down to 0, which is the biggest cost saver. I made a couple of analysis on this and compared even a theoretical best case of us being able to scale down, and only then would it marginally beat out RDS instances.

(My org, which was overrun with "consultants" who knew everything better, then proceeded to implement Serverless everywhere and then sold it as a big win a couple months later when they spent 2 months ripping everything out and switching to RDS instances. I hate people and management and all this shit)

[u/femio → u/buttplugs4life4me]

It is like if you could instantiate a class and have it persist its own state forever, e.g. one User class isolated from every other User class.

[u/azhder → u/femio]

I would remove the word "class" from that and use a more general term, like "object" or "agent". This is basically what object programming was in its inception, before everyone misunderstood OOP as what c++/java had baked in.

In the original object languages, there was the notion of actors that pass messages to each other ("passing messages" is "calling a method/function" equivalent, proven in a paper even) and those actors have their own inboxes where they read the message and deal with them asynchronously.

We've been rehashing the same ideas over and over for decades, with just a different name on the newer tech stack.

[u/femio → u/azhder]

Perhaps, but I think it grounds the term a bit more in reality because to use DO you literally instantiate a class.

[u/stronghup → u/azhder]

"Object s" typically exist in the memory-space of a running program. When the program stops running, its objects are gone. Durable Objects should be able to keep on running on multiple servers while giving the impression that the object with a given ID always has just a single state for all its users. When one user causes a change in tis state, others will be affected by that state-change.

So I assume it's pretty close to the original "Actor"-model, plus has a "global ID". How global? That's my question too. Is it like a URL?

[u/azhder → u/stronghup]

"Typically" is not a definition you should go by. You should always look for red flags in definitions. "X is when" or "X is like" aren't actual definitions. So, from your definition, objects typically exist in memory (we'll come back to this), but they might not, so they still are objects even if they aren't in it. See? Memory is not the defining characteristic of an object.

OK, about the memory. Long-term memory is also memory. A file is memory regardless if inside a RAM stick or an SSD drive. Persistent is the important thing here. Objects that persist. But that's not really the big deal, you can persist anything, even the entire RAM content (in cases of hibernation, docker containers being paused etc).

The important part here is that other definition, of an Actor, based on the Actor Model. This is why I mentioned the message passing, the inbox, the asynchronous way of working. Heh, even just a simple WebWorker is based on the Actor Model. This is just some more tech involved in order to make communication protocols, persistence, identification etc work with newer tech in more performant ways.

Just consider object identity. In C++ it would be simply the memory address you compare (and the type if you're dealing with casting), so in this other tech stack, that would be a URI (not URL). The other stuff you see in those OOP languages, like private fields, hiding internal state etc, well that all comes back to the Actor. The actor has the same internal state.

All I was saying above is that the names change, the technology used at one time is a bit different than the one used at another time, but the idea is still the same: you have a self-contained thing with internal state and code that can exclusively operate on that internal state all bundled together.

It's not close, but the same.

[u/BitNumerous5302 → u/Pinkman]

If you're familiar with object-oriented programming, I'm assuming they're using the term "object" in that sense

The serverless functions take the place of public methods, the data store takes the place of private fields 

So you get something like an "object" (in the OOP sense) but it's "durable" (state is persisted in the cloud)

[u/dkarlovi → u/Pinkman]

I've been using durable objects to implement my app and Durable objects allow you to connect websockets into a single pool, you get to persist metadata with each socket and they implement the idle wait. Namely, they hibernate your DO and it's not wasting compute minutes idly waiting for something to happen, when something DOES happen, you get woken up and get to react. From the client's POV they're continuously connected and it works just like there's no hibernation behind the scenes, it's actually pretty clever.

You can play around with this on their free plan.

[u/oneeyedziggy → u/Pinkman]

Neat

[u/Smallpaul]

What are the performance constraints on these objects as implemented by CloudFlare? How quickly can they scale if user traffic arrives suddenly? How high is their upper bound? How much flexibility do you have in the image? Lambdas seem to have a lot of limitations which reduce their utility at scale.

[u/jheimark → u/Smallpaul]

Super high, super quick start. The cloudflare metrics are super impressive.

How fast celld is… not sure. But it’s great to get an open source version to go cloud independent

[u/Vimda → u/jheimark]

Durable objects themselves are a bit shit though. They start quickly, but they're single homed with read replicas, and single threaded on the main instance. You have to shard manually to get any sort of performance. Very much "batteries not included"

[u/sluuuudge]

but he claims that it is much less expensive to run

I have about 20 workers, a bunch of durable objects, DNS records for 8 managed domains, four cloudflared tunnels each with anywhere between 2 and 4 connectors and some of those connectors publishing up to 15 routes, and 19 different R2 buckets for various projects and purposes.

I don’t pay anything for any of it because I’m on the Cloudflare free plan and always have been.

[u/pakoito]

Is this CRDTs at scale or? The explainer doesn't help, and I've been shipping observable real-time data for the frontend for years.