Pimp My IDE / garage dispatchBack to the garage
October 9, 2026 / JavaScript runtimes / service exits

A merger is four migration clocks.

Deno's team is joining Cloudflare. The runtime, hosting service, package registry, and self-hosted Workers work now have different routes.

Inventory the dependency before choosing the replacement. A runtime pin, a hosted deployment, a registry import, and a Durable Object fleet do not share one exit plan.
CurrentNext route
Transfer ruleName the thing you depend on. Record its clock, data, replacement, test, and rollback before moving it.

The headline hides the operating work.

Ryan Dahl announced that the Deno team is joining Cloudflare. The same post gives four separate outcomes. Deno Deploy will operate for six more months. The Deno runtime will receive monthly bug fixes and security updates for another year, then Deno's team will stop developing it. JSR will continue while its infrastructure moves to Cloudflare. Work on celld will merge with workerd.[1]

Those are different commitments. A team that runs Deno on its own servers does not have the same deadline as a team on Deno Deploy. A project that imports a package from JSR may have no immediate application migration at all. A team testing celld has a product direction, but Cloudflare says more announcements will come in the next few months.[2]

Do not migrate a brand name. Migrate the runtime, service, registry, or state system you actually use.

Start with a dependency inventory.

Record where each application executes, where its state lives, which package URLs it resolves, and which vendor control plane deploys it. Pin the current runtime version and save the lockfile. Export service configuration and application data while the current route still works. Name the person who can approve a replacement.

Then build a small compatibility test. It should exercise the application's real imports, permissions, environment variables, storage calls, scheduled work, WebSockets, and deployment steps. A hello-world response proves almost none of that.

Open source is a route, not a maintenance contract.

The Deno runtime remains open source, and Dahl invited others to continue development after the team's one-year maintenance window. That preserves the code. It does not name a successor maintainer, release process, security response target, or funding source.[1]

The same distinction applies to self-hosting. Cloudflare's workerd repository describes a JavaScript and WebAssembly server runtime that can run Workers applications. Its README also warns that workerd alone is not a hardened sandbox for malicious code.[4] Cloudflare says it wants to make self-hosting a first-class supported route. That is a plan, not proof that the merged system already meets your production requirements.

Read the state contract before the install command.

The celld repository describes a fleet that stores long-term state in an object-storage bucket. It uses conditional writes for ownership and LTX logs for committed SQLite writes. The repository also says a single node waits for the storage bucket on every write, while a multi-node fleet can acknowledge after another node holds the data on disk.[3]

That design may fit some workloads. It also creates work around bucket custody, peer networking, recovery, version changes, and failure testing. Treat the current repository as evidence about the design and commands it documents. Do not treat an acquisition post as a production qualification report.

Build the exit while support still exists.

For Deno Deploy, use the six-month window to export state, reproduce configuration, test the replacement, and rehearse rollback. Paying customers were promised migration support to Cloudflare Workers. The announcement does not extend that promise to every user.[1]

For the Deno runtime, decide whether to stay through the maintenance year, move to another runtime, or accept future community maintenance. Make that decision against your dependencies and support needs. For JSR, keep registry URLs and integrity data in the inventory. For celld or workerd, wait for named releases and run failure drills against the exact build you plan to operate.

Interactive makeover / route selector plus review packet

Throw the right switch.

This browser-local board combines a dependency selector, its announced clock, a transfer route, review checks, and a copyable packet. It replaces one vague migration checklist with four specific routes.

IdentifyInspect contractPrepare transfer

Select the dependency

Choose the thing your project uses. The board updates its clock, next action, destination, and packet name.

Deno runtimeDecision required

Pin the current version, test the application on a candidate runtime, and record the support owner.

Traditional purpose replaced: one generic migration checklist. Better version: the selected dependency controls the deadline, destination, action, verdict, and receipt.

Selected routeRUNTIME

Runtime maintenance year

Monthly bug-fix and security releases are promised for one year. Development by the Deno team then ends. No successor maintainer is named.

Maintenance windowUse the window to qualify the runtime route your workload can support.
12 months
Packet structure0 of 4 sections selected
Transfer packet emptySelect the sections the review packet must contain. Selection does not attach evidence.
Sources read / October 10, 2026 UTC

Source log

Open the evidence boundary
  1. Deno, "Deno is joining Cloudflare", published October 9, 2026. This first-party announcement states the one-year runtime maintenance window, six-month Deno Deploy shutdown window, paying-customer migration support, JSR infrastructure move, rusty_v8 support, and planned work with workerd. Hacker News item 50019911 was verified through the official API and used as a discovery route.
  2. Cloudflare, "Deno is joining Cloudflare", published October 9, 2026. The joint first-party post describes the planned celld and workerd merge, the current single-instance Durable Objects limit in workerd, and Cloudflare's intent to support self-hosting as a first-class route. It says more announcements will follow.
  3. Deno's public celld repository, read October 10, 2026 UTC. Its README documents the bucket-backed ownership and state model, peer replication, supported service set, operational controls, limitations, security references, and Apache 2.0 license. The repository was inspected, not installed or operated.
  4. Cloudflare's public workerd repository, read October 10, 2026 UTC. Its README identifies the runtime as the code behind Workers, documents self-hosting and local-development uses, and warns that workerd alone is not a hardened sandbox for malicious code. The repository was inspected, not built or operated.

Scope boundary: the two announcement posts describe plans and support windows. The repositories document current source and stated behavior. This dispatch did not run either runtime, test a migration, or verify production compatibility. The interactive switch creates a review template only.