bun vs deno: one bundles Node compatibility, the other gates it with permissions

What each runtime is actually built on

Bun ships as a single executable called `bun`. The README describes a runtime written in Rust and powered by JavaScriptCore, positioned as a drop-in replacement for Node.js, with a command-line tool that also implements a test runner, script runner and Node.js-compatible package manager. The design goal is consolidation: instead of a node_modules tree plus separate bundler and test runner, one binary covers those jobs. `bun run index.tsx` executes TypeScript and JSX without a build step.

Deno is built on V8, Rust and Tokio, and its README describes it as a JavaScript, TypeScript and WebAssembly runtime with secure defaults. TypeScript runs without a build step there too, but the organizing idea is different: file, network and environment access sit behind explicit flags. The README's first program is a server run with `deno run --allow-net server.ts`, and the flag is not decoration, it is the access grant.

So the architectural split is not speed versus safety in the abstract. Bun reduces the number of tools you install and leans on Node compatibility to fit existing projects. Deno reduces the ambient authority a program has by default and asks you to name what it may touch. Our analysis of bun says the trade-off is that it asks you to trust one tool for four jobs. Our analysis of deno says the permission model is the part that changes how you write code, not just how you install it.

Getting each one running

Bun's README lists an install script for macOS and Linux, a PowerShell command for Windows, and installs through npm, Homebrew and Docker (`docker pull oven/bun`). It supports Linux on x64 and arm64, macOS on x64 and Apple Silicon, and Windows on x64 and arm64. Two constraints are stated plainly: Linux kernel 5.6 or higher is strongly recommended with 5.1 as the minimum, and x64 users who hit illegal instruction errors are pointed at the CPU requirements page. Upgrades run through `bun upgrade`, and a canary build is released on every commit to main, reachable with `bun upgrade --canary`. That canary channel is a real operational choice: you can track main, but you then track main.

Deno's README lists a shell installer for Mac and Linux, a PowerShell installer for Windows, and package managers including Homebrew, Chocolatey, WinGet and Scoop, plus build-from-source instructions. The first program is a `Deno.serve` handler returning a response, started with `deno run --allow-net server.ts`, which the README says should answer on localhost:8000.

The practical difference at install time is what you must decide. With Bun you decide whether to accept a runtime that also wants to own installs and tests. With Deno you decide which permissions each program gets, and that decision recurs in every deployment script and container entrypoint rather than being settled once.

Package management and the npm boundary

Bun implements a Node.js-compatible package manager with commands for install, add, remove, update, link, publish, patch, audit and more, plus workspaces, catalogs, overrides, a global cache and store, isolated installs and `.npmrc` support. The README states that its built-in tools are usable in existing Node.js projects with little to no changes. Our analysis of bun says to verify that your lockfile story is settled, because Bun writes bun.lock rather than package-lock.json. That is the concrete cost of adoption: a second lockfile format in the repository, and whatever your CI and review process assumes about the first one.

Deno's README points to JSR as an open-source package registry for modern JavaScript and TypeScript, and to the Deno Standard Library at jsr.io/@std. Our analysis of deno says to check that every npm dependency you rely on resolves through the npm specifier path before committing. That is a narrower promise than Bun's: Deno can consume npm packages, but the project treats Node compatibility as an ongoing effort rather than a parity guarantee, which is why the ext/node workspace exists.

For a codebase already deep in npm, Bun asks you to switch the installer and keep the ecosystem. Deno asks you to audit which dependencies survive the trip and to prefer its own registry and standard library where you can.

Permissions, isolation and what runs in production

Deno's permission flags are the feature with the largest downstream effect. A program started with `deno run --allow-net server.ts` has network access and, by default, nothing else. That changes container configuration, local development, and the review conversation about a dependency that suddenly wants to read the filesystem. It also adds friction: every new capability a service needs is an explicit grant, and a missing flag surfaces as a runtime failure rather than a silent success.

Bun's model is the Node model. The runtime is designed as a drop-in replacement, so a program gets the ambient access Node programs get, and compatibility is the selling point. Our analysis of bun says not to adopt it if your production runtime must stay byte-for-byte Node.js, or if you depend on native addons that the Node.js compatibility page does not list as supported. The compatibility page is the boundary to check, and native addons are where that boundary bites hardest.

Neither approach is strictly better. Deno's flags buy a smaller blast radius per process at the cost of more configuration. Bun's compatibility buys a shorter migration at the cost of inheriting Node's trust model and depending on how complete the compatibility layer is for your particular addons.

Testing, bundling and developer tooling

Bun folds a test runner and bundler into the same binary. `bun test` runs tests, and the bundler covers loaders, plugins, macros, CSS, HTML and static sites, single-file executables, hot module replacement, and full-stack HTML imports. Our analysis of bun says to verify that `bun test` discovers the same test files your current runner does. Test discovery rules are the kind of difference that quietly drops files from a suite, and a suite that silently shrinks is worse than one that fails.

Deno's README is thinner on tooling in the section available, pointing to the documentation, the standard library and JSR rather than enumerating a bundler and test runner. What it does show is the direct execution path: write TypeScript, run it, no build step, with permissions declared on the command line.

The comparison here is breadth against a smaller, more declared surface. Bun gives you more built-in tools and expects them to behave like the tools they replace. Deno gives you fewer moving parts to configure and expects you to state what the program may do. Teams that already run a bundler and test runner they like will find Bun's versions optional and Deno's absence unremarkable.

Where each one falls short

Bun's weakness is concentration. One binary owning installs, tests, bundling and execution means a regression in any of those areas affects the others, and the canary-on-every-commit release model means the fast channel moves constantly. The custom licence that GitHub cannot classify is a real review item: the LICENSE file has to be read by someone qualified before this goes into a commercial product, and the facts table will not answer that question for you. Native addon support is bounded by the compatibility page, and the lockfile switch to bun.lock touches CI and code review.

Deno's weakness is the npm boundary and the permission overhead. Our analysis of deno says not to adopt it as a drop-in replacement for a large existing Node service, because compatibility is an ongoing effort and parity is not promised. Every permission a service needs must be granted explicitly, which is a benefit until a deployment fails because a flag was missed in one environment. The README's own framing, secure defaults and a great developer experience, is a positioning statement, not a compatibility claim, and the gap between the two is where migration projects stall.

Both projects are actively developed. Bun's last push was 2026-09-24 and its most recent release listed is bun-v1.4.0 on 2026-08-20. Deno's last push was 2026-09-25 and its most recent release listed is v2.9.6 on 2026-08-27. Neither repository is archived. The difference is cadence and channel policy, not abandonment.

Licence, governance and maintenance risk

Deno is MIT licensed, which is a known quantity for legal review and for redistribution inside a product. Bun uses a custom licence that GitHub cannot classify, and the README does not settle the question either; the LICENSE file is the only authority. For a runtime that will sit in production and be redistributed in containers, that difference in legal certainty is worth more attention than any feature comparison on this page.

Maintenance looks similar on the surface. Both repositories are unarchived, both pushed within the last week of September 2026, and both ship releases on a regular cadence. The divergence is in release philosophy: Bun publishes a canary on every commit to main and lets users opt in with `bun upgrade --canary`, while Deno's listed releases are numbered versions spaced weeks apart. A team that pins versions and audits upgrades will find Deno's rhythm easier to plan around, and a team that wants fixes immediately will prefer Bun's channel.

Governance is single-vendor in both cases, Oven for Bun and Deno Land for Deno. Nothing in the facts available indicates either is at risk of abandonment, but neither is a foundation-backed project with a neutral steering process, and that is a factor when a runtime becomes load-bearing infrastructure.

Bottom line

Pick Bun when the goal is fewer tools and a short path from an existing Node project: one binary for install, run, bundle and test, at the cost of a lockfile change, a custom licence to review, and a compatibility page that defines your native addon risk. Pick Deno when the goal is a new service or script where explicit permissions and direct TypeScript execution matter more than npm parity, and accept that every capability becomes a flag. Before committing to either, verify the two things that decide most migrations: for Bun, run `bun install` on a copy of your project and confirm `bun test` discovers the same files; for Deno, confirm your npm dependencies resolve through the npm specifier path and that `deno run --allow-net server.ts` answers on the port you expect.

Sources

1. oven-sh/bun repository
2. oven-sh/bun README
3. denoland/deno repository
4. denoland/deno README