Deno's entire team is joining Cloudflare. If you host an application on Deno Deploy, the announcement gives you a six-month operating window before the service shuts down. Cloudflare Workers is the destination named in the migration-support promise for paying customers. The Deno runtime has a separate, longer maintenance commitment, and keeping those two clocks separate makes the announcement much easier to act on.
TL;DR
- Deno Deploy will operate for six more months. Paying customers are promised migration help for moving to Cloudflare Workers.
- The current team will maintain the Deno runtime for another year, with monthly bug-fix and security releases, then end its development of the runtime.
- Deno remains open source. JSR, the JavaScript and TypeScript package registry, continues operating, with its infrastructure moving to Cloudflare.
- The proposed workerd/celld merger and distributed self-hosting effort are future work. Cloudflare's joint announcement documents a present scaling limitation for self-hosted Durable Objects.
Cloudflare Workers gains the Deno team
Ryan Dahl's announcement says the entire Deno team is joining Cloudflare. Dahl created Node.js and later Deno, so the move brings people with a long history of building JavaScript execution environments into the Workers platform. The announcement does not establish a deal price or enough corporate detail to infer a particular transaction structure.
Deno is a runtime: software that executes JavaScript and TypeScript outside a browser. Deno Deploy is the hosted service that runs applications for you. JSR is a package registry. Those names often share a paragraph, but they sit at different places in an application's dependency chain. A package registry staying online tells you where packages can be obtained. A hosting shutdown tells you where your application will eventually stop being served. A runtime-maintenance commitment tells you who will keep shipping fixes for the execution environment.
The joint Cloudflare post by Dahl and Kenton Varda explains the architectural direction. The team plans to merge workerd, the open-source Workers runtime, with celld, Deno's infrastructure system, and improve first-class self-hosting. Ryan and Bert will lead that effort. Further announcements are promised in the coming months.
That gives developers a direction to watch and an existing deadline to manage. The merged platform's eventual features cannot substitute for a migration plan you need to begin today. My dependency manager has many talents; hiring the next maintainer has so far escaped its scope.
Deno Deploy: turn six months into an inventory
The primary announcement says Deno Deploy will continue operating for six months before shutting down. It specifically promises migration support for paying customers moving to Cloudflare Workers. The wording supplies an operating window, without giving an exact calendar shutdown day in the statement cited here. It also leaves the extent of free-customer assistance unspecified.
I would start by listing everything the hosted application relies on. This is a practical recommendation, rather than a claim that Deno or Cloudflare has published a universal migration recipe. A useful inventory includes database connections, background work and stored data. Write down which service owns each piece and how it can be tested independently.
For database connections, identify the actual connection path and the credentials involved. An application successfully accepting an HTTP request tells you little about whether its destination environment can reach the same database. For background work, identify what triggers it and what happens if it runs twice or misses a run. For stored data, identify which data needs to move, who owns the export and how you would recognize a complete transfer.
Then choose a small, representative workload for a trial migration. Include the stateful operation you are most worried about, even if the landing page would make a prettier demo. Record the expected behavior before moving it. You want a result that can be compared with the current application, especially around persistence and retries.
Keep the migration assistance promise attached to its actual scope. Being a paying customer moving to Workers is the case explicitly named by Deno. That statement alone does not prove that every application is a drop-in replacement or that every Deploy integration has an identical Workers feature. The appropriate next step is to ask about your application's dependencies, with an inventory that lets someone give a concrete answer.
Six months is enough time to put this work on a calendar. It is also enough time to keep saying you will put it on a calendar until the calendar becomes the incident.
Deno runtime maintenance: name an owner
The runtime commitment is another year of monthly releases containing bug fixes and security updates. After that, the current team says it will end its development of Deno. The source remains open, and others are welcome to continue it. JSR continues operating, while rusty_v8 also receives continued support and work toward integration into workerd.
For a developer running Deno on infrastructure they control, this is a maintenance-ownership decision. The announcement does not say that an installed executable suddenly stops functioning on October 9. It changes the forward commitment of the people who maintain it.
An open-source license preserves the ability to inspect the code and continue development. Continuing maintenance takes people, time and a release process. A possible fork should be evaluated as an actual project when one exists, with evidence of who maintains it and how fixes are delivered. The permission to fork is valuable; a staffed maintenance effort still needs to be organized.
I would put a named owner beside the runtime in the same inventory used for the hosting migration. That person can track monthly releases, identify the features the application depends on and decide what evidence would justify staying with a future maintenance project. The choice may differ between a small internal tool and a service with a larger operational commitment.
Keeping JSR online helps preserve a separate part of the ecosystem. It does not answer every application's execution or hosting question. Treat each layer as its own dependency, so that good news about one layer does not hide a deadline in another.
Durable Objects and the self-hosting gap
The Cloudflare post describes a Durable Object as an individually addressable server with its own SQLite database, single-threaded JavaScript and WebSockets. Its example assigns one object to each chat channel. That distributes state and connections by channel, giving the discussion a concrete unit of ownership.
The important qualification is Varda's statement about workerd's current Durable Objects implementation: it is implemented “only in a single-instance way, good enough for local testing, but unable to scale.” The context is self-hosted Durable Objects. Applying that sentence to every workerd workload would make the claim broader than the source supports.
The proposed merger with celld is the positive counterweight. Dahl describes celld as a Rust binary whose only external service dependency is object storage. Bringing the systems together is intended to improve distributed self-hosting. That is a vendor architecture description and a future direction, rather than our independently reproduced operational result.
For someone evaluating self-hosting, the questions follow directly from this gap. What can the current system do? Which part needs distributed state ownership? What has actually shipped by the time you need it? A local test environment can be useful while a production deployment needs additional behavior. Keep both facts in view when reading the roadmap.
Also today: Microsoft MXC and Bevy 0.20
Microsoft MXC is an embedded SDK for running untrusted code, such as model output or plugins, under containment policies. Its 1.0 release was published October 7; its public-release history reaches June 2. Today's discussion should not turn that older history into a claim that the repository was created today. The SDK offers different execution backends, and their isolation boundaries differ. Its README explicitly warns that audit mode turns off all sandbox security for the workload being analyzed and must never be used to run untrusted code. Audit is for trusted policy analysis.
Bevy 0.20 arrived October 8. Bevy is a free, open-source Rust game engine. The episode uses the Solari author's real footage to show shadow-lag and reflection improvements, alongside the release's number-input widget demonstration. Solari remains experimental and requires ray-query support. Metal support comes with a missing built-in macOS denoiser; the release does not promise DLSS on a Mac. Optional ReSTIR is off by default, with documented shadow-quality tradeoffs, especially in motion with many lights. These are useful graphics improvements with hardware and quality qualifications attached.
Verdict: NEEDS REVIEW
I stamped this episode NEEDS REVIEW. Plan the hosting migration and name the runtime maintenance owner. The self-hosting roadmap is worth following, and the immediate commitments are specific enough to make the first decisions now. Keep the Deploy deadline and the runtime deadline on separate lines.
FAQ
Is Deno Deploy shutting down immediately?
The announcement says it will operate for six months before shutting down. It promises migration support for paying customers moving to Workers. An exact shutdown day is not supplied in the cited wording.
Will Deno remain open source?
Yes. The current team's runtime maintenance commitment lasts another year, after which it will end its development. Others are welcome to continue the open-source project.
Is JSR closing too?
JSR will continue operating. Its infrastructure is moving to Cloudflare, according to Deno's announcement.
Is distributed self-hosting ready today?
The workerd/celld merger and first-class self-hosting work are announced plans. The joint post explicitly identifies the current single-instance limitation for workerd's self-hosted Durable Objects.
Sources
- Deno: Deno is joining Cloudflare
- Cloudflare: joint announcement and self-hosting direction
- Microsoft MXC README
- Microsoft MXC 1.0 release
- Bevy 0.20 release
- Solari author: realtime raytracing in Bevy 0.20
- Bevy 0.20 experimental Solari feature requirements
Cover portrait: Ryan Dahl at YUIConf 2010, photographed by David Calhoun, CC BY 2.0, via Wikimedia Commons. Cropped, background removed and mirrored. It is a historical portrait.
This article expands on an episode of **The Daily Diff, a five-minute daily video on what shipped and what broke in tech.
Watch the episode · Subscribe on YouTube · the written diff lands in your inbox every morning at thedailydiff.dev.
Top comments (0)