What Deno and Cloudflare announced

On October 9, 2026, the entire Deno team said it is joining Cloudflare. Cloudflare filed its own post under the Acquisitions tag, and neither company published the terms.

Deno is the JavaScript and TypeScript runtime Ryan Dahl started after Node.js. The same team ran Deno Deploy, a serverless hosting service, and JSR, a TypeScript-first package registry. The announcement gives each of those products a different future: a maintenance year for the runtime, a shutdown window for the hosting service, and a change of infrastructure for the registry.

Two posts carried the news: Dahl's note on the Deno blog and a joint post he wrote with Cloudflare's Kenton Varda. The first is a product notice. The second explains what Cloudflare wants from the team.

The runtime gets one year of maintenance

Cloudflare will support the Deno runtime for another year. Releases will continue monthly and will contain bug fixes and security updates. After that year, the company will end development of the runtime. Deno stays open source, and the Deno post invites others to keep developing it.

For teams that built production services on Deno, a year of fixes is support, but it is not a roadmap. New features should not be expected, and any dependency that needs an upstream change has to be resolved within that window or moved.

The team also said it will continue supporting rusty_v8, the V8 binding Deno depends on, and work toward integrating it into workerd. The engineering effort is moving into the shared Workers platform rather than staying in a standalone runtime.

Deno Deploy shuts down after six months

Deno Deploy will keep operating for six months, then shut down. The team says it will provide migration support for paying customers who move to Cloudflare Workers.

Neither post splits free users from paying customers, and neither gives a shutdown date beyond the six-month window. The scope of migration support is also unstated. Anyone running production traffic on Deploy has to plan around a deadline in the first half of 2027 and confirm their own terms with the provider rather than assume help covers their case.

JSR keeps running on Cloudflare infrastructure

JSR will continue to operate. Its infrastructure moves to Cloudflare, but the registry stays available, so publishing workflows pointed at jsr.io do not need an immediate change.

That makes JSR the one part of the announcement with continuity rather than an end date. Package authors should still watch how Cloudflare treats the registry over the next year, because ownership of the infrastructure now sits with the new employer.

Concept illustration of unlabelled software-package boxes moving along a conveyor from a small older rack into broad, stocked pale-green shelves, representing JSR continuing as its infrastructure moves to Cloudflare.
Concept illustration: JSR continues operating as its infrastructure moves to Cloudflare.

Self-hosted Durable Objects are the real target

The Cloudflare post explains why the company wanted this team. Varda writes that workerd, Cloudflare's open-source Workers runtime, has always had a production-readiness gap: Durable Objects run in a single instance in workerd, which is enough for local testing but cannot scale. He describes the production routing implementation as something no self-hoster would want, and notes that the gap has been documented in the code since the original release.

celld, which the Deno team released in August 2026, is a second implementation of Workers and Durable Objects designed to be self-hostable and scalable. Cloudflare plans to merge celld's code and ideas back into workerd. Dahl and Bert Belder will lead the effort to make self-hosting a supported way to run the Workers programming model, and Cloudflare promises more announcements in the coming months. Developers who do not want to wait can self-host celld or workerd today.

Varda also argues that Workers' differences are not a lock-in trap. He points to the open-source runtime and to Shopify's 2022 requirement that the runtime be open source before the company would build on Workers. That is Cloudflare's position, stated by an executive who benefits from it, and it should be read as an argument rather than a settled fact.

What to do if you depend on Deno

The three products lead to three different decisions.

If you run the runtime: check which dependencies still ship updates, decide how long you plan to stay, and watch for a community fork or successor project. Do not expect new runtime features.

If you host on Deno Deploy: start comparing Cloudflare Workers, celld, and your existing infrastructure now. Six months is a workable migration window for a small service and a tight one for anything with production traffic and custom configuration.

If you publish to JSR: keep publishing. The registry stays up, and the immediate risk is low.

What the posts do not answer

Neither post gives deal terms, an exact Deploy shutdown date, or a commitment about free Deploy users. The maintenance year has no published policy beyond monthly bug fixes and security releases. Whether celld survives the merge as a separate project is unclear, and so is the fate of any Deno features that depended on the runtime team's full attention.

What the announcement does make clear is the direction: Cloudflare is buying a team to make its programming model runnable outside its own network, and the standalone runtime is the part it is willing to let go. For developers with production traffic on Deno Deploy, the six-month window is the deadline that matters.