Deno is joining Cloudflare

Deno is joining Cloudflare | Cloudflare Blog

Skip to content

The Deno team is joining Cloudflare to radically simplify self-hosting Workers and Durable Objects so developers can use the same primitives in more places. For what this means and how it came about, here’s the story from Ryan Dahl, Senior Principal Engineer, and Kenton Varda, Distinguished Engineer.

Ryan Dahl Deno (and now Cloudflare)

The Deno team is joining Cloudflare, and we're merging workerd and celld! For more on what's happening to the Deno runtime and our various efforts, see my post on the Deno blog.

Long ago, I stood in a Berlin warehouse and introduced Node.js with a 500-line JavaScript IRC server and live audience participation. Node.js was an exploration of what a purely asynchronous programming model could enable. Async I/O was already known to be important for fast servers, but it was difficult to wield. Removing sync networking made it easier to build systems that previously required much more machinery. What made the IRC demo exciting was how little code it took.

I started Deno to find more powerful abstractions like this — looking for places where we could simplify and remove capabilities while giving engineers ever more power. With Deno, we improved the experience of writing JavaScript, but we didn’t fundamentally change what developers had to assemble around the runtime. The bigger problems are around networked applications: distributing computation, coordinating state, data storage in general, and autoscaling to meet demand.

Something about that old IRC demo has always bothered me — it was a single server, single thread even. It could handle many user connections, but it would start getting slow if you had too many. Scaling IRC eventually means multiple machines with the channels shared across them. A modern chat app also needs to store message history, user accounts, and other data.

Could the programming model make partitioning across machines part of the design from the start?

The solution clicked into focus when I read about Cloudflare's Durable Objects. It provided a very powerful abstraction: the distributed singleton with a SQLite database. Each Durable Object is like a small, individually addressable server with its own relational database. Its JavaScript execution is single-threaded (which is easy to reason about), it handles WebSockets, and its local SQLite database can be accessed synchronously. By building a chat application using one DO per channel, you have sharded your data and WebSocket connections, and thus made your application scalable.

Much more than chat can be built with DOs. On top of this abstraction other services can be built: Queues, KV, Durable Execution (CF's Workflow API), even Git storage. The Durable Object abstraction is simple yet incredibly powerful.

But running this model outside of Cloudflare has remained difficult. Cloudflare’s network is great — but there are a million reasons one might want to run it themselves. Workerd is already open source, but its Durable Objects support is limited to a single instance. What I wanted was the distributed version: IRC channels spread across machines, with the platform handling placement, routing, and durable storage. The power of this abstraction is how it scales. That's why I started celld.

Building and operating Deno Deploy taught me how complicated cloud infrastructure could become: multiple public clouds, multiple databases, and deeply entangled services. With celld, I wanted the opposite: one binary, written in Rust, with object storage as its only external service dependency.

What excites me is the leverage this model gives developers: compute, relational databases, queues, and real-time communication primitives designed for applications distributed across machines. To run it, you manage many instances of celld and a single object storage bucket. Your application can contain many services without each requiring a separate infrastructure project. This is much closer to the simplicity I've been chasing since that first Node.js demo.

We’re joining Cloudflare to make the Workers programming model a mainstream way to build servers. By bringing celld and workerd together, we want it to be radically easy to build and operate distributed applications on your own infrastructure.

Kenton Varda Cloudflare

This may come as a surprise to some, but when the Deno team released celld in August, we were delighted.

Why a surprise? Well, as it happens, there is a popular theory that suggests we shouldn't be happy.

You see, it is commonly claimed around the Internet that we made Cloudflare Workers work differently from other cloud platforms in order to create "lock-in." The claim goes, software built on Workers is hard to move to other hosting platforms, therefore if you write your app on Workers you are "trapped" on Cloudflare forever. This is especially true of apps that use Durable Objects: they are not just written differently but architected differently. All this is, supposedly, a clever trap: once you are too deep to be able to switch, the rug will somehow be pulled out from under you.

Under this theory, celld is a threat: as an open-source implementation of Workers and Durable Objects, it allows applications built on Workers to seamlessly migrate to other providers. No more trap!

This theory is wrong

Workers is different because it is better

We built Workers differently because we believe it is a better way to build web applications.

The Workers design makes it dead simple and dirt cheap to manage an application that runs in hundreds of locations around the world, a feat which no other popular hosting platform has achieved. The pricing isn't a trick: we've genuinely created a novel architecture that is more efficient than competitors, and we've passed on the savings to you.

Workers' live environment design (aka "bindings") simultaneously makes configuring access to external resources easier and more secure. Usually, those two things don't come together!

Durable Objects make it easy to build real-time collaboration and distributed systems that are difficult or impossible in a classical three-tier web architecture.

In short, we believe we've simply created a better programming model for cloud software. But being better requires being different: we couldn't achieve these benefits while remaining perfectly compatible with existing platforms.

If we could offer these benefits and be perfectly compatible with...