Deno Team to Join Cloudflare as Runtime and Deploy Wind Down

The entire Deno team is joining Cloudflare.

Deno announced the plan on 9 October, stating that its engineers will combine work with Cloudflare's Workers and Durable Objects teams. Future development will go into that shared platform rather than a separate runtime and hosting service, according to the announcement. Deno announcement

The Deno runtime, the engine that runs JavaScript and TypeScript programs, will get one more year of support. Deno said it will ship monthly releases containing bug fixes and security updates during that period, then end its development of the runtime. The code will remain open source.

In practical terms, that schedule sets a clear window for operators. Twelve months of patches allows time to plan a migration or a fork without forcing an emergency rewrite. Development stops after that year, and maintenance does not continue indefinitely.

Deno Deploy, the hosting service for Deno apps, will continue operating for six months before shutting down. Paying Deploy customers moving to Cloudflare Workers, Cloudflare's global system for running code close to users, will receive migration support. Deno did not describe terms for free-tier projects or detailed tooling, only the commitment to assist paying customers in the move.

Two components have a longer future. JSR, the package registry for sharing JavaScript libraries, will continue operating, with its infrastructure moving to Cloudflare. Deno also said it will continue supporting rusty_v8, the Rust bridge to V8, the engine that runs JavaScript, and work toward integrating it into workerd, the open-source runtime behind Workers.

The broader context here is consolidation around a single isolate-based execution layer, a method for safely running code from many customers in the same process. Maintaining a production JavaScript runtime, a global hosting plane, a package registry and V8 bindings in parallel is expensive engineering. Pooling that work into workerd reduces duplication for contributors while leaving deployers with fewer divergent APIs to target.

Looking at what this means for production users, the timelines matter more than the destination. Runtime users have a year. Deploy users have six months. That asymmetry will shape priorities. Application code on Deno can continue to run while deployment automation, preview environments, cron, KV and other platform bindings get repointed first. Teams should inventory where they depend on Deploy-specific behavior versus portable runtime behavior, and test those paths on Workers early in the window.

In my view, the handling of JSR and rusty_v8 is the most instructive part. Registries and low-level V8 bindings are infrastructure that outlives any single runtime distribution. Keeping JSR operational under Cloudflare infrastructure preserves module resolution for existing graphs. Carrying rusty_v8 forward into workerd preserves the Rust bridge to V8 that both ecosystems need. The code that is hardest to replace gets sustained. The product surface that is easiest to migrate gets sunset.

There is a tradeoff here that deserves clear attention. A shared platform means fewer choices of runtime semantics and hosting primitives. For most workloads that is a net simplification. For teams that selected Deno specifically for its permission model, TypeScript-first execution or tooling opinions, the migration is not mechanical. It will require re-evaluation of build, test and policy controls on the new stack.

The optimistic read here is straightforward. A combined team focused on Workers, Durable Objects, a system for stateful cloud programs, JSR and workerd can direct engineering time to performance, observability and stateful primitives instead of parallel maintenance. If that work lands upstream in open source, self-hosters and fork maintainers benefit even after Deno ends active runtime development.