Deno alternatives after the Cloudflare deal: Node, Bun, workerd and celld for the runtime slot
As of 13 October 2026, a Deno project has four places to go, plus staying put while the fixes last: Node.js, Bun, self-hosted workerd with celld, or hosted Cloudflare Workers. The Deno team announced on 9 October that it is joining Cloudflare, that the Deno runtime gets monthly bug-fix and security releases for one more year, and that Deno Deploy shuts down after six months. For most projects, scripts, CLIs and servers alike, the pick is Node 26, which becomes LTS on 28 October.
What happens to Deno after the Cloudflare deal?
Deno's own post, by Ryan Dahl on 9 October 2026, says "the entire Deno team is joining Cloudflare". Neither company used the word acquisition or gave terms; TechCrunch and The New Stack call it one. The runtime gets "monthly releases containing bug fixes and security updates" for a year, then development ends, and it stays MIT-licensed.
The dates are counted from the announcement, because neither company published calendar dates:
| Piece | What the Deno post says | End point |
|---|---|---|
| Deno runtime | Monthly fixes for "another year", then development ends | About October 2027 |
| Deno Deploy | Runs "six months before shutting down"; migration help for paying customers moving to Workers | About 9 April 2027 |
| JSR | Keeps running on Cloudflare infrastructure | None given |
| rusty_v8 | Maintained, to be integrated into workerd | None given |
Fresh, Deno KV, @std, Subhosting |
Not mentioned | Unknown |
The last release is v2.9.7 from 17 September; none has shipped since the announcement. Dahl explained the decision on Hacker News: Deno "has been sucked into the gravity well of node compatibility, which forces it to behave exactly as Node does. Why reimplement Node? It works." A community fork, Dodo, was created on 12 October and has no releases yet.
How the options were chosen
The five options below are the runtimes a Deno codebase can move to without a rewrite into another language, plus staying. Hosting alternatives to Deno Deploy, such as Vercel or Fly.io, are a separate choice and are left out. So are Netlify Edge Functions and Supabase Edge Functions, which both run on Deno-based runtimes and have not said what the deal changes for them.
Each option below gets the same fact line: licence, owner, latest release, what it runs and when to pick it. Versions were checked on GitHub and nodejs.org on 13 October 2026.
Five runtimes a Deno project can move to
The five options split on one question: does the project need a general-purpose runtime that reads files, spawns processes and runs scripts, or does it serve requests? Node, Bun and Deno run anything. workerd and Workers run the Workers programming model, request handlers with bindings, and nothing else.
Deno, until about October 2027
MIT. Team now at Cloudflare. v2.9.7, 17 September 2026. TypeScript natively, per-path and per-host permission flags, npm: imports, built-in fmt, lint, test and compile. Pick it for scripts and CI tools you can pin and move later, with a calendar reminder for the month the patch releases stop.
Node.js
MIT, OpenJS Foundation. v26.11.1, 7 October 2026; v26 becomes LTS on 28 October and is supported until April 2029, while v24 LTS runs to April 2028. Type stripping is stable but covers erasable syntax only, so enum and parameter properties fail. The --permission model is stable, but --allow-net is on or off with no host list, and the docs say it "does not protect against malicious code". Pick it as the default.
Bun
MIT, with LGPL JavaScriptCore linked in. Owned by Anthropic since 2 December 2025. v1.4.3, 10 October 2026; 1.4 rewrote Bun in Rust and claims Node 26.3 compatibility. TypeScript natively and bun build --compile for single binaries, but no permission model: a pull request adding one was closed unmerged in June. Pick it for speed and an all-in-one toolchain when you do not need Deno's permission flags.
workerd and celld
Both Apache-2.0. workerd is Cloudflare's open-source Workers runtime, released daily (v1.20261013.1 on 13 October). celld, from the Deno team, runs a Workers app from your existing wrangler.json on your own machines, with a SQLite database per Durable Object and an object storage bucket as its only dependency; it is at v0.6.2, which its docs call beta. Cloudflare's post says Dahl and Bert Belder will merge "code and ideas from celld back into workerd", with no date beyond "the coming months".
Where a Worker request runs on a celld fleet. Image: celld docs by Deno Land Inc., Apache-2.0.
celld runs Linux and Apple silicon only, sends peer traffic as plain HTTP and is "not safe for hostile multi-tenant use", per its limitations page. workerd's own README carries a heading that reads "workerd is not a hardened sandbox", and its Durable Objects run single-instance, "good enough for local testing, but unable to scale" in Kenton Varda's words. Pick it for a request-serving app you want off any one vendor's servers, and wait for the merge before putting stateful production work on it.
Cloudflare Workers
Proprietary hosted service running workerd. Workers Paid starts at $5 a month with 10 million requests included, per the pricing page. Per request, CPU time is capped at 10 ms on the free plan and up to 5 minutes on paid, with 128 MB of memory per isolate. It is the only destination Deno promised migration help for, and only for paying Deno Deploy customers. Pick it when the app ran on Deno Deploy and fits the request model.
What breaks moving a Deno project to Node in 2026?
Moving a Deno project to Node breaks imports first: Node rejects jsr: and npm: specifiers with ERR_UNSUPPORTED_ESM_URL_SCHEME, and has no answer to https: URL imports, so all three move into package.json. Then every Deno.* call needs a node: equivalent. Neither Deno nor Cloudflare has published a migration guide, so the evidence is three ports done in the last two weeks.
- David Bushell's static site generator, ported to Node v26.10.0 before the deal was public (3 October): Deno's file API to
node:fs,Deno.serveto Hono's Node adapter,@std/pathtonode:path. Builds got 15% faster. Node refuses to strip types insidenode_modules, so he bundles his published packages with tsdown. - frugal-tokens (PR #90, 10 October): 98 files, Node 26 for native
Temporal, pnpm, all 20 task names kept as scripts, tests moved to Vitest, and tsx kept because Node cannot strip constructor parameter properties. - black-atom (issue #58, 10 October): Node 24 and npm workspaces, oxfmt for
deno fmt, ESLint fordeno lint,tsc --noEmitfordeno check. Landed in three commits.
Two pieces have no drop-in. Deno KV has no Node built-in: the exits are the @deno/kv npm client against a self-hosted denokv, or moving the data. deno compile maps to Node's single executable apps, still in active development, or to bun build --compile. Alan West's grep recipe finds the expensive calls fast: Deno\.(openKv|cron|serve|env|readTextFile|Command).
Deno features the Workers model does not have
The Workers model trades Deno's process access for bindings. A Worker reaches storage and services through capabilities named in its config, not through --allow-* flags, and Dahl says the model "does not expose the underlying linux system". That rules Workers and workerd out for CLI tools and scripts, and it changes how a server stores state.
| Deno feature | Workers and workerd |
|---|---|
--allow-read, --allow-net per path or host |
Capability bindings in the config |
| Real filesystem | In-memory node:fs: /bundle read-only, /tmp writable |
Deno.Command subprocesses |
node:child_process is a non-functional stub |
deno run script.ts |
None; workerd is "designed for servers, not CLIs" |
| Long-running work | Request-driven, CPU capped per request |
| Deno KV | Workers KV, D1, Durable Objects with SQLite, Queues |
Deno.cron |
Cron Triggers, which celld also runs |
deno compile |
None for apps; celld itself is one 58 MB binary |
The options side by side
The table repeats each option's fact line. The deciding rows are whether it runs scripts and which permission model it has: Deno is the only one with per-host network rules, and the only one with an end date.
| Deno | Node.js | Bun | workerd and celld | Cloudflare Workers | |
|---|---|---|---|---|---|
| Licence | MIT | MIT | MIT | Apache-2.0 | Proprietary |
| Owner | Deno team, now Cloudflare | OpenJS Foundation | Anthropic | Cloudflare | Cloudflare |
| Latest | v2.9.7, 17 Sep | v26.11.1, 7 Oct | v1.4.3, 10 Oct | v1.20261013.1; celld v0.6.2 beta | Hosted |
| Runs scripts and CLIs | Yes | Yes | Yes | No | No |
| Native TypeScript | Full | Erasable syntax only | Full | Via bundling | Via bundling |
| Permission model | Per path and per host | Stable, network on or off | None | Bindings | Bindings |
| Support | About October 2027 | v26 to April 2029 | Ongoing | Ongoing | Ongoing |
On Stackness, as of 13 October 2026, 6 real profiles list Node.js, 2 list Bun and 1 lists Deno, after removing bot accounts (data sources). The counts are too small to call a migration, though they point the same way as the State of JS 2025 runtime question, where 10,062 respondents used Node, 2,321 Bun, 1,294 Cloudflare Workers and 1,244 Deno. The Bun vs Node.js page puts the two side by side, among the languages, frameworks and runtimes developers list.
Which one for which project
- Scripts, CLIs and CI tools: Node 24 or 26, or stay on a pinned Deno until the patches stop.
- A server on Deno Deploy: Cloudflare Workers if it fits the request model, otherwise Node on any host, before about April 2027.
- A server you run yourself: Node 26 LTS.
- A project that needs speed and a single binary: Bun, if you can live without permission flags.
- A Workers-shaped app that must leave no single vendor: workerd now for one node, celld once it leaves beta.
- A project that relies on
--allow-netper host: stay on Deno and watch the Dodo fork; nothing else ships that rule. - A Fresh app: no Node port is documented; Fresh 2 deploys to Workers through Vite, but still needs the Deno CLI to build.
Which of these do you use?
Nobody on Stackness runs workerd yet. Tick what you use and be the first.
