Deno's move to Cloudflare sets an April 2027 shutdown for Deno Deploy

The two dates bind different teams. Deno Deploy is a hosted service, so apps still on it stop serving when it goes dark around April 2027 ^[2]. The runtime stays open source ^[5]. A self-hosted Deno process keeps running after the company stops working on it; it just stops getting patches. Counting from the October 9, 2026 announcement ^[20], the guide's one-year end for runtime development lands around October 2027 ^[21]. If the extra year of maintenance releases runs from that point, the last security fix ships around October 2028 ^[22]. After that, self-hosted users rely on a community fork; the guide says one is possible ^[5].

The hard deadline belongs to Deploy customers. The guide's porting map puts little of their work in the HTTP layer. Its author says every Deploy app they have seen uses Deno.serve, state in Deno KV, and sometimes a cron ^[12]. Deno.serve() becomes an `async fetch(request, env, ctx)` method on a default export, because Workers are event-driven and have no server to start ^[13]. In the guide's example the routing body is identical on both sides and only the wrapper changes ^[13]. Deno.cron() becomes a Cron Trigger declared in the Wrangler file and run by a `scheduled` handler ^[15]. Static files go into the assets config, where Wrangler serves the directory and falls through to the Worker for API routes ^[17].

npm dependencies come down to one value. Workers turn on `nodejs_compat` by default for compatibility dates of 2026-08-04 or later, according to Cloudflare's compatibility flags docs as the guide cites them, so imports of Node built-ins run without extra flags ^[16].

State is where the port stops being mechanical. Six months ^[2] is enough to swap a server wrapper and less generous for a storage redesign under live traffic. The guide calls the Deno KV replacement the one real design decision: Workers KV for simple reads, Durable Object storage when the app needs transactions ^[14].

We'd take the guide as an accurate list of API equivalents and an untested account of behaviour under load. Its author says they checked every API detail against Deno's and Cloudflare's documentation and has not run a Deno Deploy app in production ^[18].

Cloudflare's own direction points the same way for stateful code. The Deno team is joining the Workers and Durable Objects teams ^[9]. According to the guide, Dahl writes that Durable Objects offer a mix that suits agent harnesses especially well: cheap serverless compute, persistent state, WebSocket support and a high-level JavaScript API ^[10]. The guide's author concludes that the destination is Durable Objects, not a standalone Deno runtime competing with Node ^[11]. We think that makes Workers with Durable Objects the default target for Deploy apps that hold transactional state. Its checklist still asks whether to migrate at all ^[19].