One announcement, four contracts.
Deno says its whole team is joining Cloudflare. The company will publish monthly bug fixes and security updates for the Deno runtime for another year, then end its own runtime development. Deno Deploy will operate for six more months. Paying customers will get migration help for Cloudflare Workers. JSR will continue under infrastructure moved to Cloudflare.[1]
That is not one retirement date. It is a runtime support window, a hosted-service shutdown, a registry continuity promise, and a future open-source maintenance question. Put all four in the migration issue. A ticket titled "move off Deno" throws away the useful distinctions.
Source availability preserves an option. A rehearsed replacement preserves a service.
The acquisition points at a new target.
Cloudflare says Ryan Dahl and Bert Belder will lead work to make workerd self-hosting a supported route for the Workers programming model. The plan is to merge code and ideas from celld into workerd. The same post says the current open-source runtime has only single-instance Durable Objects, which Cloudflare describes as useful for local testing but not scalable.[2]
That limitation matters more than the acquisition slogan. A Deno Deploy application that uses state, placement, routing, or hosted operations does not become portable because another runtime repository exists. Inventory the managed behavior before choosing Workers, today's workerd, the future merged project, or a different host.
Read the runtime's own warning label.
The workerd repository describes it as the JavaScript and WebAssembly runtime built from the same code that powers Cloudflare Workers. It lists self-hosted application serving as a use. It also states that workerd alone is not a hardened sandbox for possibly malicious code and calls for another security boundary such as a virtual machine.[3]
The repository uses Apache 2.0. Deno uses MIT. Those licenses make source use possible. They do not supply release engineering, security response, distributed state, backups, observability, or an operator. Put each missing function beside the repository URL.
Migrate behavior before syntax.
Start with a production request and trace what it touches. Record runtime APIs, environment bindings, regional placement, storage, scheduled work, queues, WebSockets, deployment secrets, logs, rollback, and data export. Then run that route against the proposed target. A clean TypeScript build is only one checkpoint.
Cloudflare argues that compatibility dates let a worker retain earlier API behavior when the runtime moves forward. That can reduce accidental API drift inside the Workers model.[3] It does not test your data transfer, operational limits, or failure recovery. Pin the date, then replay real behavior.
Use the six-month clock first.
Deno Deploy has the shorter announced window. Export what the service holds, identify every deploy and rollback command, and place a small production-shaped route on the replacement before the final month. Keep the old service available long enough to compare responses and reverse a bad cutover.
The runtime window buys more time for local development and command-line usage. Do not spend that time waiting for a community maintainer to appear. Decide whether to stay on a community Deno, move to another runtime, or reduce runtime-specific code. Attach an owner and a test date to the choice.