Deno joins Cloudflare: Deploy gets six months, runtime maintenance gets a year

Three products with different timelines

Deno Deploy will shut down after six months, Ryan Dahl announced on October 9, 2026, as Deno joined Cloudflare. The team committed to another year of monthly runtime releases with bug fixes and security updates before ending its runtime development. JSR, the package registry, will continue operating, with its infrastructure moving to Cloudflare.

Those commitments create separate planning windows. Counting from the announcement puts Deploy’s shutdown around April 9, 2027, and the end of the team’s runtime maintenance around October 9, 2027. These are calculated dates, not published cutoff timestamps. The announcement promises paying Deploy customers support for moving to Workers but does not specify the terms.

The immediate priority depends on which product an application uses. Deploy customers face a hosting shutdown; self-hosted applications face the eventual loss of the current team’s maintenance. JSR users have no announced registry shutdown or migration deadline. Treating all three as one retirement would obscure which work needs attention first.

Self-hosting leaves a maintenance decision

Installed Deno applications will not stop running because the team ends runtime development. Deno remains open source, and the announcement invites others to continue its development. Community maintenance is therefore possible, but the announcement establishes neither a successor maintainer nor a future security support arrangement.

Deno’s deployment documentation describes two self-hosting paths. Developers can bundle an application and its runtime with deno compile, or install Deno on a host and use deno serve, typically under a process manager. Moving a Deploy application to infrastructure running Deno may preserve more code than changing runtimes immediately. It also transfers infrastructure responsibility and leaves future runtime maintenance unresolved.

Compiled applications need rebuilding to incorporate runtime updates. A migration inventory should also cover formatting, linting, testing, benchmarking and dependency resolution. Deno’s documentation describes direct TypeScript execution and permission grants for file, network and environment access. A production service can move while its build scripts and continuous integration still depend on Deno.

Workers compatibility depends on API usage

Request and Response provide a starting point for a Workers migration. A handler using those web APIs may retain its internal logic while its server entry point and deployment configuration change. JSR’s Workers guide demonstrates an exported object with a fetch method. That illustrates a migration pattern without establishing that an arbitrary Deno service can move unchanged.

Workers supports web-platform APIs and a subset of Node.js APIs. Cloudflare’s documentation distinguishes native implementations from shims that permit imports but throw errors when called; its stub list includes node:child_process. A dependency that launches an external executable needs scrutiny beyond a successful installation or import. Migration tests should exercise optional paths and failure handlers alongside ordinary requests.

Cloudflare introduced node:fs and the Web File System API in Workers on August 15, 2025. According to its changelog, the virtual filesystem isolates temporary files per request, and those files do not persist across requests. Temporary-file operations may be portable, but data that must survive requests needs a separate persistence design.

Cloudflare’s compatibility documentation says nodejs_compat and nodejs_compat_v2 are enabled by default for compatibility dates of August 4, 2026, or later; older dates require explicit configuration. Record the selected date and flags alongside application changes. Cloudflare documents Wrangler as a command-line interface installed through Node.js and npm, while applications execute in workerd. It recommends wrangler types for matching type definitions, but successful TypeScript compilation still requires validation in the destination runtime.

JSR availability and package compatibility are separate

JSR’s continued operation removes a registry shutdown from the announced timetable. Its documentation already describes using packages in Workers through an npm compatibility layer. The example installs @std/encoding, imports encodeBase64 and returns a standard Response. Compatible packages therefore have a documented route to Workers without keeping the application on Deno.

Registry availability does not establish runtime compatibility. Review each package’s API usage, particularly calls beyond shared web standards. When using the JSR command-line interface, its guide says to commit the generated .npmrc so subsequent package installations work. Reproducible dependency installation belongs in migration testing alongside request handling.

Cloudflare’s infrastructure role also leaves questions open. The announcement promises continued registry operation, but the research does not settle JSR’s future operational governance. Developers can plan around the absence of an announced migration deadline while watching for details. Replacing every JSR dependency solely because runtime development is ending would not address the separate compatibility checks a migration requires.

Durable Objects require deliberate partitioning

In their joint announcement, Dahl and Kenton Varda described plans to bring celld’s code and ideas into workerd. Dahl illustrated Durable Objects through a chat application with one object per channel. Each object has an identity, SQLite storage and WebSocket connections. Deciding what belongs in each object becomes part of application design.

Cloudflare documents each Durable Object as single-threaded, with horizontal scaling achieved by creating multiple objects. Its FAQ gives a soft limit of 1,000 requests per second per object, with achievable throughput depending on the work performed. Excess traffic can queue and eventually produce overloaded errors. Dividing work by room, tenant or session may fit naturally; putting all coordination in one object can create a bottleneck.

Storage and execution limits need explicit tests. Cloudflare’s documentation supports a 10 GB storage limit per SQLite-backed object on the paid plan, but its limits table and FAQ differ on free-plan capacity. The limits page lists 30 seconds of CPU time by default for a Durable Object request, configurable to five minutes. These are workload constraints, not typical-performance claims.

Distributed self-hosting remains a development direction rather than an established replacement for Cloudflare’s managed service. The joint post acknowledges that existing open-source workerd support for Durable Objects is confined to a single instance. It names Dahl and Bert Belder as leaders of the self-hosting effort, with further announcements expected in coming months. Migration plans should not depend on an unannounced delivery schedule or recovery model.

Plan backward from the Deploy shutdown window

An editorial planning target is to start in October 2026 with an inventory of applications, data, domains, secrets, scheduled jobs and dependencies. Deploy customers should obtain written cutoff and migration-support details, then prototype the least portable application path first. Hosted state, queues and scheduled work need separate plans covering persistence, delivery and retry behavior. These are recommendations, not deadlines supplied by Deno.

November and December offer time to select a destination through functional tests and representative load, then design data transfer, reconciliation and rollback. January and February 2027 can cover rehearsals and checks of production behavior, observability, recovery and costs. A March production cutover target would leave contingency time before the inferred April shutdown window. Self-hosted applications have longer to establish a maintained runtime destination or credible ongoing support.

The available research does not support a defensible platform performance ranking, so migration decisions need application-specific measurements. Tests should record versions, plans, compatibility dates, client and database locations, caching, concurrency and duration. Measure latency distributions, errors, CPU use and billable operations, including retries and state bookkeeping. For Durable Objects, include uneven traffic and a heavily used individual object.

Ask providers to resolve the remaining operational questions before setting the final migration sequence. The inspected announcements do not establish the exact shutdown timestamp, data-export and retention arrangements, or migration-support eligibility and scope. They also leave the treatment of Sandbox and Subhosting unresolved. Written answers can inform data-transfer plans, support expectations and the timing of production cutover.