Deno: a Rust-built JavaScript and TypeScript runtime with permissions on by default

The problem Deno targets: a runtime that asks before it touches your machine

A Node process starts with the same access as the user who launched it. Any dependency in the tree can read ~/.ssh, open a socket, or read process.env, and nothing in the runtime stops it. Deno's answer is a permission boundary at the runtime level. The README describes it as "a JavaScript, TypeScript, and WebAssembly runtime with secure defaults and a great developer experience," and the repository layout backs the claim: permissions live in their own workspace crate at runtime/permissions, separate from the runtime crate itself. That separation is the design statement. The sandbox is not a library you opt into; it is a component of the runtime that the CLI consults before an operation is allowed to proceed.

The audience follows from that. Deno suits people who run code they did not write: CI jobs that execute a build script from a repository, serverless handlers, small internal tools, and anyone who wants TypeScript to run without a tsc step in front of it. It also suits people who are tired of assembling a toolchain. The README points to the standard library at jsr.io/@std and to JSR as "the open-source package registry for modern JavaScript and TypeScript," so a project can start with a registry that is not npm. That is a genuine convenience and a genuine lock-in question, which is why the npm compatibility work in ext/node and libs/npm matters more than any single feature.

How the runtime is put together: V8, Rust, Tokio, and a workspace of ext crates

The README names the three pillars: V8 for execution, Rust for the host, Tokio for async I/O. The Cargo.toml turns that into a concrete map. ext/ holds the JavaScript-facing capabilities as separate crates: ext/fs, ext/net, ext/http, ext/crypto, ext/kv, ext/webgpu, ext/websocket, ext/webstorage, ext/ffi, ext/canvas, ext/image, ext/cron, ext/telemetry, and more. libs/ holds the machinery underneath: libs/core for the V8 binding layer, libs/deno_v8 for the V8 build, libs/ops for the op layer that bridges Rust functions to JavaScript, libs/resolver and libs/node_resolver for module resolution, libs/npm, libs/npm_cache and libs/npm_installer for npm packages, libs/lockfile for lockfile handling, libs/eszip for the module archive format, and libs/serde_v8 for serialization across the boundary. The cli/ crate is the binary you actually run, and runtime/ holds the runtime crate plus runtime/permissions.

Two details in that file are worth reading twice. First, ext/node and ext/node_crypto and ext/node_sqlite exist as first-class workspace members, which tells you Node compatibility is maintained as an explicit surface rather than an afterthought. Second, the file carries a comment explaining an exclusion: tests/sqlite_extension is left out because it needs rusqlite's loadable_extension feature, which conflicts with the session feature used elsewhere in the workspace. That is a small thing, but it is the kind of constraint that shapes how the project builds, and it is documented rather than hidden. The tests/ tree mirrors the same structure with tests/node_compat, tests/napi, tests/specs, tests/unit and tests/integration, so the compatibility surface is measured rather than asserted.

Installing Deno and running a first server on localhost:8000

The README gives one-line installers for macOS and Linux, plus package-manager routes for Windows and Homebrew on Mac. The shell installer is the shortest path on a Unix-like system and drops a deno binary on your PATH.

curl -fsSL https://deno.land/install.sh | sh

On Windows the README lists PowerShell, Chocolatey, WinGet and Scoop. The PowerShell form is:

irm https://deno.land/install.ps1 | iex

If you prefer a package manager, Homebrew covers macOS with brew install deno, and Windows users can use choco install deno, winget install --id=DenoLand.Deno, or scoop install main/deno. The README notes that a fuller list of installation options lives in the docs, and that building from source is documented in .github/CONTRIBUTING.md.

For a first program, the README's example is a web server in a file called server.ts. It is TypeScript with no build step and no import of anything:

Deno.serve((_req: Request) => {
  return new Response("Hello, world!");
});

Run it with the permission flag the README specifies:

deno run --allow-net server.ts

The README states this should start a local web server on http://localhost:8000. That is the whole loop: write TypeScript, name the capability you need, run it. Note what the flag is doing. Without --allow-net the program cannot bind a socket, so a typo in the flag name fails loudly instead of silently opening a port. That is the trade-off in practice: a little more typing at the command line in exchange for a runtime that refuses to do things you did not ask for.

Where the permission model costs you: flags, prompts and the wrong-tool cases

The permission boundary is the reason to pick Deno, and it is also the first thing that will slow you down. Every capability a program needs has to be granted at the command line, which means a script that reads a config file, writes a log and calls an API needs several flags rather than none. The README's own example is the minimal case: one flag, one capability. Real programs are not minimal, and the flag list grows with them.

There is a second-order cost that the repository makes visible. Deno ships an npm compatibility layer, but compatibility is a moving target, not a guarantee. The workspace contains libs/npm, libs/npm_cache, libs/npm_installer, libs/npmrc, libs/package_json and libs/node_resolver precisely because resolving and installing npm packages the way Node does is substantial work. If your project depends on a package that reaches deep into Node internals, or on a native addon with a build step, the compatibility layer is where you should expect friction, and the README does not claim otherwise.

The wrong-tool cases are worth naming directly. If you are maintaining a large Node service where every dependency is already working and the team knows the ecosystem, a runtime swap buys you a permission model you did not ask for and a compatibility surface you now have to verify. If your deployment target is a platform that only accepts Node binaries, Deno is not an option regardless of its merits. And if your build already depends on Node-specific tooling that shells out to node, the ext/node layer may cover it, but you would be testing that assumption rather than relying on it.

Deno compared with Node and Bun: what actually differs

Node is the incumbent, and the difference is not the language, since both run JavaScript. It is the default posture and the toolchain. Node grants a process the user's full access and expects you to bring your own TypeScript compiler, test runner, formatter and bundler. Deno runs TypeScript directly and gates capabilities behind flags. If you already have a Node toolchain you like, Deno's built-in tooling is redundant rather than valuable, and its permission flags are overhead rather than protection.

Bun is the closer comparison, because both are newer runtimes that bundle tooling and both aim at TypeScript. The repository does not describe Bun's internals, so the honest difference to state is architectural: Deno is built on V8, Rust and Tokio, and its repository is organized as a Rust workspace with ext/ crates for capabilities and libs/ crates for the layers beneath. That structure is what makes the permission system a runtime component rather than a wrapper, and it is also why the project carries a large test tree for Node and N-API compatibility. The practical question is not which runtime is faster, since no benchmark numbers appear in this repository, but which one already runs your dependencies.

JSR versus npm is the other axis. The README points to JSR as the registry for modern JavaScript and TypeScript and to jsr.io/@std for the standard library. A new project can live entirely in that world. An existing project cannot, which is why the npm specifier path and the libs/npm crates exist at all.

Maintenance, release cadence and the MIT licence

The repository is not archived, and the last push was on 2026-08-27, which is recent relative to the release history: v2.9.6 on 2026-08-27, v2.9.5 on 2026-08-06, and v2.9.4 on 2026-07-23. That is a patch release roughly every two to three weeks across the visible window, with no major version jump in the three releases listed. A Releases.md file sits at the repository root, so the changelog is part of the tree rather than only a web page.

The upgrade cost depends on which surface you touch. Pinning a version and reading Releases.md before moving is cheap, and the patch cadence suggests small deltas between releases. The expensive part is the compatibility layer: if a release changes how npm packages resolve or how Node built-ins are shimmed, the breakage lands in your dependency graph rather than in your own code, and the tests/node_compat tree exists because that surface is large.

The licence is MIT, stated in the repository metadata and in LICENSE.md. The Cargo.toml header also carries an MIT notice for the workspace. MIT is permissive: it allows commercial use and modification with attribution and no warranty. That is a summary of what the licence text provides, not legal advice, and anyone redistributing Deno inside a product should read LICENSE.md and the licences of the vendored components, particularly V8, rather than relying on this paragraph.

Editorial conclusion

Adopt Deno when you want TypeScript executed directly and a permission boundary around file, network and environment access, and when a single binary with built-in tooling is worth more to you than npm compatibility at the margins. Do not adopt it as a drop-in replacement for a large existing Node service: the ext/node workspace exists precisely because compatibility is an ongoing effort, and the README does not promise parity. Before committing, install it, run the server.ts example with deno run --allow-net server.ts, and confirm that localhost:8000 answers, then check that every npm dependency you rely on resolves through the npm specifier path.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes