Cloudflare has brought the Deno team inside.

At first glance, this may look like the acquisition of a runtime company or the hiring of a developer tools team. But the real meaning is larger than Deno itself. Together with the Deno team, Cloudflare is trying to make Workers and Durable Objects easier to run outside Cloudflare’s own network. In other words, Cloudflare is trying to expand its core programming model into more environments.

On October 9, 2026, Cloudflare published a post titled “Deno is joining Cloudflare.” Its message was clear: the Deno team is joining Cloudflare to radically simplify self-hosting Workers and Durable Objects, so that developers can use the same programming primitives in more places.

Ryan Dahl explained it even more directly.

The Deno team is joining Cloudflare, and workerd and celld will be merged. workerd is the open-source implementation of the Cloudflare Workers runtime. celld is a project Ryan Dahl created to run the Durable Objects model in a distributed way on self-hosted infrastructure.

This combination matters not because of a weakness in Workers, but because of its strength.

Cloudflare Workers operates differently from traditional server infrastructure. Rather than manually assembling server instances, regions, load balancers, autoscaling rules, and network placement, developers deploy applications into a lightweight JavaScript-based execution environment that can run globally at the edge. Cloudflare argues that Workers makes it simpler and cheaper to run applications across hundreds of locations.

But that difference has also been the source of criticism.

Cloudflare Workers does not work like traditional cloud platforms. Applications built with Durable Objects, in particular, have not been easy to move to other hosting environments. This has led to claims that Cloudflare deliberately created lock-in: if developers build applications on Workers, they may later find it difficult to move elsewhere.

Cloudflare’s Kenton Varda rejects that argument.

His position is that Workers is different because Cloudflare believes it is a better model. Workers was designed to make globally distributed applications simpler and cheaper to operate. Bindings make access to external resources easier and safer. Durable Objects make it easier to build real-time collaboration and distributed systems that would be difficult or impossible under a traditional three-tier web architecture.

Cloudflare’s argument is this:

Workers is not different in order to create lock-in.

Workers is different because Cloudflare is trying to build a better model for cloud applications.

But a better model is not always fully compatible with existing platforms.

This is where the Deno team’s arrival becomes meaningful.

If Cloudflare truly wanted lock-in, it would have little reason to make Workers and Durable Objects easier to run outside Cloudflare. Yet Cloudflare is now moving in the opposite direction. It wants to support a self-hostable Workers model more seriously, together with the Deno team. Varda argues that lock-in can actually harm Cloudflare, because large customers may avoid building critical systems on a platform if they do not have an exit path.

This is an important insight in the cloud business.

Locking customers in may look attractive in the short term. But enterprise customers calculate long-term risk. When they place important workloads on a platform, they ask whether they can leave that platform, operate the runtime themselves, respond to outages, or adapt to changes in pricing and policy. Cloudflare says this is one of the reasons it open-sourced workerd, the Workers runtime.

But workerd had a major gap.

Cloudflare made workerd available for production use, but it also acknowledges that it did not build enough of a self-hosting ecosystem and tooling around it. Durable Objects were the harder problem. workerd implemented Durable Objects, but in a way closer to a single-instance model, sufficient for local testing but not enough for scalable self-hosted production environments. Cloudflare’s actual production Durable Objects routing system depends on hundreds of locations, multiple external services, and SRE operations, making it unsuitable as a self-hosted package.

This is where celld enters the picture.

Ryan Dahl saw a powerful abstraction in Cloudflare’s Durable Objects. A Durable Object behaves like a small server: a distributed singleton with its own SQLite database. Each object is individually addressable. It has its own relational database. JavaScript execution is single-threaded, making the system easier to reason about. It can handle WebSockets and access its local SQLite database synchronously.

For a chat application, for example, assigning one Durable Object to each channel naturally shards both data and WebSocket connections, allowing the application to scale.

This point is important.

Durable Objects are not merely storage.

They are small servers and units of state management.

They are an abstraction that prevents developers from having to assemble distributed systems manually.

Chat, real-time collaboration, queues, key-value storage, durable execution, and Git-like storage can all be built on top of this model.

Ryan Dahl’s problem was clear.

The model was powerful inside Cloudflare, but difficult to run in distributed form outside Cloudflare. workerd was open source, but its Durable Objects support remained limited for self-hosted distributed use. Ryan wanted to run a distributed version of Durable Objects outside Cloudflare’s network: a model in which IRC channels, for example, could be distributed across multiple machines while the platform handled placement, routing, and durable storage.

That led to celld.

The goal of celld was simple.

After operating Deno Deploy, Ryan Dahl experienced how complex cloud infrastructure could become. Running a platform involved multiple public clouds, multiple databases, and deeply entangled services. celld aimed for the opposite: a single binary written in Rust, with only one major external dependency—object storage.

This is where Cloudflare and Deno’s interests met.

Cloudflare wanted to make Workers and Durable Objects self-hostable, but its production implementation was too complex to package as a self-hosting system. The Deno team, through celld, was already building a self-hostable and scalable implementation of Workers and Durable Objects. From Cloudflare’s perspective, Deno was building something Cloudflare had wanted to build for a while.

That is why this move is not simply an acquisition. It is the joining of two projects.

Ryan Dahl and Bert Belder will lead a new effort to make workerd self-hosting a first-class supported way to build and run applications using the Workers programming model. The plan is to merge code and ideas from celld back into workerd. Cloudflare says more announcements will come in the coming months, but developers can already self-host celld or workerd today.

This announcement matters because it shows where cloud competition is moving.

For a long time, cloud competition was a contest of infrastructure scale and service count. More regions. More databases. More managed services. More compute and storage. But from the developer’s perspective, the problem has become increasingly complex. Even small applications may require assembling compute, databases, queues, caches, storage, authentication, autoscaling, deployment, logging, and networking.

Ryan Dahl’s concern is precisely this complexity.

Node.js simplified server development by making asynchronous I/O easier to use. Deno improved the JavaScript and TypeScript runtime experience. But around the runtime, developers still had to assemble many things themselves. The larger problems in network applications were distributed computation, state coordination, data storage, and autoscaling according to demand.

Workers and Durable Objects offer one answer to that problem.

Design applications from the beginning as distributed units of state.

Let each Durable Object behave like a small server.

Give it SQLite for state.

Let it handle WebSockets.

Let the platform handle placement, routing, and scaling.

If this model becomes easy to run on self-hosted infrastructure, developers can use the same abstraction whether they deploy to Cloudflare or operate their own servers.

What Cloudflare gains here is paradoxical.

If self-hosting becomes easier, customers can leave Cloudflare more easily. But Cloudflare believes this may actually be good business. Customers are more likely to enter if they know they can exit. By reducing fear of lock-in, Cloudflare can encourage more companies to adopt the Workers model. Cloudflare has already open-sourced workerd, and it notes that some former customers have used workerd to leave Cloudflare. Yet it still argues that open source and escape hatches are good business.

This reflects a broader change in cloud platform strategy.

In the past, cloud providers kept customers through the convenience of managed services. The more deeply databases, queues, serverless functions, storage, AI services, and networking were integrated into a platform, the harder migration became. But as AI and developer-platform competition intensify, the ability to leave is becoming part of trust.

Cloudflare’s message is this:

We do not want to win through lock-in.

We want to win because the Workers model is better.

And for that to happen, the model must also work outside Cloudflare.

The Deno team’s arrival gives that message technical substance.

Ryan Dahl created Node.js and helped popularize the idea of server-side JavaScript. Later, with Deno, he tried to redesign the JavaScript and TypeScript runtime experience. Cloudflare sees Ryan and the Deno team as particularly strong at building developer experience around self-hosted runtimes—an area Cloudflare says it never fully solved with workerd.

This announcement also matters for the developer ecosystem.

Deno began as an alternative to Node.js. It aimed to offer a safer and more modern JavaScript and TypeScript runtime. But with this move, the Deno team’s focus expands beyond the runtime itself into a distributed application programming model. Deno’s own announcement says the team has decided to put future development work into the shared Cloudflare platform rather than continuing to develop a separate runtime and hosting service; Deno runtime support will continue for one year, while Deno Deploy will continue operating for six months before shutting down.

This means the next abstraction for JavaScript server development may no longer be the runtime alone. It may be distributed state and execution.

The question changes.

It is no longer simply: which JavaScript runtime should we use?

It becomes: how can we make stateful distributed applications simple?

How can we build chat, collaboration, queues, data storage, and real-time communication without assembling separate infrastructure each time?

How can the same model run outside Cloudflare?

The core of Durable Objects is state.

Serverless computing has long been strong at stateless execution. A request comes in, code runs, and the execution ends. But real applications need state: user sessions, chat rooms, collaborative documents, game rooms, job queues, long-running workflows, and database connections. Once state enters the picture, developers face databases, caches, locks, sharding, message queues, and routing.

Durable Objects bind state to small object-level units.

Each object provides single-threaded JavaScript execution, making concurrency easier to reason about. Each object has a SQLite database and can handle WebSockets. This structure is well suited to real-time collaboration and distributed state management. That is why Ryan Dahl sees Durable Objects as a simple yet powerful abstraction.

But if this model is tied only to Cloudflare, adoption has limits.

Enterprises may require multi-cloud, on-premises deployment, regulatory compliance, data sovereignty, cost control, disaster resilience, or internal platform standards. They want the option to operate critical infrastructure themselves. If workerd was open source but Durable Objects did not scale well in self-hosted form, then the Workers model could still appear strongly tied to Cloudflare’s network.

Deno and celld aim to loosen that bottleneck.

celld is designed to run distributed applications with multiple instances and a single object-storage bucket. Its own documentation describes it as a self-hosted, distributed Durable Objects system that can run Workers, Durable Objects, KV, Queues, D1, R2, Workflows, Cron, and static assets on a developer’s own machines, with state stored in a bucket the operator controls.

That simplicity may become increasingly important.

AI agents, real-time collaboration, multiplayer applications, personalized services, event-driven workflows, and global SaaS all require distributed state. If developers must assemble multiple cloud services every time, development slows and complexity grows. If the Workers and Durable Objects model becomes easy to self-host, developers gain a simpler mental model for distributed applications.

Cloudflare’s strategy is therefore interesting both technically and commercially.

Technically, it extends the Workers programming model beyond Cloudflare’s own network.

Commercially, it weakens lock-in criticism and reduces enterprise-customer anxiety.

Ecosystem-wise, it presents distributed state as the next abstraction for JavaScript and TypeScript server development.

There are risks, of course.

If self-hosting becomes easy, Cloudflare’s differentiation may appear weaker. Competing clouds or internal enterprise platforms could use the Workers model themselves. It may seem to reduce the reasons customers must remain on Cloudflare.

But Cloudflare’s judgment is the opposite. If the model spreads widely, the value of Cloudflare’s network, operations, global deployment, security, and managed experience may become even clearer.

This is a classic open-source platform strategy.

Open the technical standard to grow the ecosystem.

Allow self-hosting to build trust.

Win customers through the most convenient and powerful managed operating experience.

Cloudflare already open-sourced workerd. Now, through the Deno team, it is trying to address the weakness around Durable Objects self-hosting. If this strategy succeeds, Workers can become not only a Cloudflare product, but a broader programming model.

Ultimately, the essence of this announcement is not simply that Deno is joining Cloudflare.

The more important point is that Cloudflare is positioning Workers not as a feature that works only on its network, but as a new way to build servers. And to make that argument convincing, Cloudflare is strengthening the escape hatch.

This may be the paradoxically strongest platform strategy.

Let users leave so they feel safe entering.

Let applications move so the model can become a standard.

Let people self-host so the value of the managed service becomes clearer.

The Deno team’s arrival is a step toward executing that philosophy.

Ryan Dahl brought JavaScript to the server with Node.js. With Deno, he redesigned the runtime experience. Now, inside Cloudflare, he is trying to bring Workers and Durable Objects outside Cloudflare.

The next question in server development may no longer be, “How do we start a server?”

It may be, “How simply can we build stateful distributed applications?”

The combination of Cloudflare and Deno is one answer to that question.