Deno: Secure JavaScript and TypeScript Runtime

What Deno is

Deno, pronounced "dee-no", is a runtime for JavaScript, TypeScript and WebAssembly that runs code outside the browser, in the same space as Node.js and Bun. Its README describes it as a runtime with secure defaults and a great developer experience, built on Google's V8 JavaScript engine, the Rust programming language and the Tokio asynchronous runtime. The project was started in 2018 and is licensed under MIT.

Two ideas set Deno apart. The first is security: a program run with Deno has no access to the file system, network, environment variables or subprocesses unless you grant it, either with command-line flags or through an interactive prompt. The second is an integrated toolchain: TypeScript runs directly with no compiler to install, and the single deno binary also ships a formatter, linter, test runner, benchmarking tool, documentation generator, language server, dependency manager and a compiler that turns programs into standalone executables.

Deno 2 also leans hard into compatibility with the existing JavaScript ecosystem. It reads package.json, installs npm packages, supports node: built-in modules and CommonJS, and the docs say a typical Node project runs with one command to install and one to run. That makes the audience broader than early Deno's: backend and full-stack developers who want TypeScript without build configuration, teams looking for a safer way to run scripts and third-party code, tool authors who want to ship a single binary, and Node users who want Deno's tooling while keeping their npm dependencies.

How it works

At its core Deno embeds V8 to execute JavaScript, with the runtime itself written in Rust and asynchronous I/O handled by Tokio. When you run a TypeScript file, Deno treats execution and type checking as separate concerns. The TypeScript guide explains that deno run strips the types and hands the resulting JavaScript to V8, which is fast, happens in-process and is cached, but does not check whether the types are correct. Type checking is a separate step: deno check, or deno run --check, runs the real TypeScript compiler over the code without executing it, with strict mode on by default. The upshot, as the docs put it, is that type errors do not stop code from running unless you ask.

Modules can come from local files, npm (with npm: specifiers or a package.json), JSR (the open-source registry the Deno team runs for JavaScript and TypeScript), or remote URLs. Deno reads two configuration files, Node's package.json and its own deno.json, and both are optional. The configuration guide's rule of thumb is to use package.json for dependencies and scripts, and add deno.json when you want to configure Deno's own tooling such as the formatter, linter, TypeScript compiler options, tasks and lockfile behaviour.

Security is enforced by the runtime rather than the operating system. Code can freely execute other code at the same privilege level, through eval, dynamic imports or workers, but cannot touch sensitive APIs without permission. All code on the same thread shares one privilege level, so a dependency gets exactly the permissions the program was started with. Modules in the initial static module graph are loaded without consulting the permission system, so you don't need --allow-read to load local files or --allow-net to fetch remote imports, but once code runs, everything it does goes through permission checks, including import() calls with non-literal specifiers.

Node globals are handled pragmatically. The Node guide says process is available everywhere, while Buffer is not global in your own code and should be imported from node:buffer. __filename and __dirname are not defined in ES modules; the docs map them to import.meta.filename and import.meta.dirname. Projects with a package.json default to a manual node_modules mode, which is why an explicit install step is needed; setting "nodeModulesDir": "auto" skips it. If you forget, Deno names the fix in its error message, telling you it found the package in package.json and asking whether you forgot to run deno install.

Key features

• Secure by default. No file, network, environment or subprocess access without explicit permission. Permissions are scoped, for example --allow-net=example.com, --allow-read=./data or --allow-env=API_KEY, and --deny-* flags carve exceptions out of broader grants.
• Interactive permission prompts. When stdout is a terminal and no flag was passed, Deno pauses and asks whether to allow an operation instead of failing. Refused operations throw a Deno.errors.NotCapable error that code can catch.
• Runtime permission control. The Deno.permissions API lets a program query, request and revoke its own permissions, for example reading a config file at startup and then giving up read access.
• TypeScript with no setup. Run .ts files directly; an existing tsconfig.json works but is not required.
• Node and npm compatibility. The Node guide's compatibility table lists node: built-in modules, npm packages, Node globals, package.json dependencies and scripts, CommonJS, configurable node_modules layouts, Node-API native addons, and .npmrc private registries as supported.
• All-in-one CLI. Subcommands include deno run, serve, task, repl, add, install, outdated, audit, fmt, lint, check, test, bench, coverage, doc, lsp, jupyter, compile and deploy, among others.
• Standalone executables. deno compile bundles a program and its runtime flags into a single binary. From Deno 2.8, running it on a directory detects common web frameworks, including Next.js, Astro, Fresh, Remix, React Router, SvelteKit, Nuxt, SolidStart and TanStack Start, runs their build script and produces an entrypoint that starts them.
• Web-standard APIs. The README's first example serves HTTP with Deno.serve, which takes a handler receiving a standard Request and returning a standard Response.
• Standard library on JSR. The Deno Standard Library at jsr.io/@std provides officially supported utilities; modules at version 1.0.0 or higher are considered stable.

Getting started

The README lists several installation methods. On macOS and Linux, the shell installer:

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

On Windows, PowerShell:

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

Package managers work too, including Homebrew on macOS:

brew install deno

and Chocolatey, WinGet and Scoop on Windows. To build from source, the repository's contributing guide has full instructions.

The README's first program is a web server. Create server.ts with:

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

and run it, granting network access:

deno run --allow-net server.ts

That starts a server on http://localhost:8000. Without --allow-net, Deno either prompts for network access or, if no terminal is attached, refuses the operation.

For an existing Node project with a package.json, the configuration guide shows the two commands that replace the usual npm workflow:

deno install        # install the dependencies from package.json
deno task <script>  # run a script defined in package.json

deno install reads package.json and creates a node_modules directory so bare imports resolve as they do in Node. Scripts run through deno task in Deno's built-in cross-platform shell, and CLI tools in node_modules/.bin resolve automatically. To ship a tool as a single binary, the compile reference shows bundling a file server with its permissions baked in:

deno compile --allow-read --allow-net jsr:@std/http/file-server

npm command-line tools run without a global install. The Node guide uses this example, granting only read and environment access:

deno run -R -E npm:[email protected] "Hello there!"

The same specifier syntax, npm:<package-name>[@<version-requirement>][/<binary-name>], selects a specific binary from a package, which makes deno run a scoped replacement for npx. Scaffolding tools that need broad access, such as project generators, can still be run with -A, at the cost of disabling the sandbox for that command.

Day-to-day, most projects end up using a handful of the bundled tools: deno fmt and deno lint in place of separate formatter and linter packages, deno test with deno coverage for tests, deno check in CI, and deno lsp running behind an editor extension so type errors appear as you type. Because these ship with the runtime, a new project needs no dev-dependency setup before it can be formatted, linted, type-checked and tested.

Use cases

• HTTP services and APIs in TypeScript. Deno.serve and web-standard Request and Response objects make a typed HTTP server a few lines of code with no build step.
• Running scripts and third-party code more safely. Scoped permissions let you run a CLI tool or a dependency-heavy script with access only to the directories and hosts it needs.
• Shipping CLI tools as single binaries. deno compile produces a standalone executable with permission flags embedded, so users do not need Deno installed.
• Modernising a Node project's tooling. Teams can keep package.json and npm dependencies while using Deno's formatter, linter, test runner and type checker, adopting Deno incrementally.
• Deploying framework apps as executables. Framework detection in deno compile covers popular meta-frameworks, turning a Next.js or SvelteKit project into one binary.
• Data exploration. The deno jupyter subcommand runs Jupyter notebooks with a JavaScript and TypeScript kernel.

How it compares

Node.js is the reference point. The Deno docs draw the main contrast themselves: in Node, dependencies are automatically granted full access to all system I/O, while Deno denies it until you opt in. Deno also bundles TypeScript execution, type checking, formatting, linting and testing that a Node project typically assembles from separate packages. On compatibility, the Node guide claims that as of Deno 2.8 more than 75% of Node's own test suite passes in Deno and that most pure-JavaScript npm packages work unchanged, while acknowledging that some APIs are partial, native addons need a local node_modules, and a few tools assume npm's exact on-disk layout. Projects deeply tied to Node-specific tooling may still be smoother on Node.

Bun is the other runtime in the same category, also targeting fast TypeScript execution and Node compatibility with built-in tooling. Deno's distinguishing points are its permission sandbox and its emphasis on web-standard APIs and the JSR registry. Which runtime is faster for a given workload is best measured directly rather than taken from marketing claims on any side.

On stability, the release guide states that the Deno namespace APIs have been stable since 1.0.0 and that the team strives to keep code written for 1.0.0 working in later versions, while newer APIs go through an unstable phase first.

Things to know before adopting

• The sandbox has escape hatches. The security guide warns that --allow-run and --allow-ffi effectively grant full access: a subprocess runs outside the sandbox (and --allow-run=deno lets a script start a fresh deno with --allow-all), and native libraries loaded via FFI or Node-API can make system calls directly. It also warns against combining --allow-write with --allow-run on directories containing allowed executables. -A turns the sandbox off entirely.
• Type errors don't block execution. Because deno run only strips types, you need deno check or --check in CI or your editor to catch them.
• Release cadence and channels. A new stable minor version ships on a 12-week schedule with patch releases in between. Deno is distributed on stable, lts, rc and canary channels, and the channel is baked into the binary. A plain version number always resolves to the stable build, so an LTS user who runs deno upgrade with a version number moves off the LTS channel.
• LTS window. The LTS channel currently tracks the 2.9 line, starting at v2.9.3, and is maintained until 31 January 2027 with security patches and critical bug fixes only.
• Unstable APIs need flags. New APIs ship behind --unstable-* flags, such as --unstable-kv, and may change. Standard library modules below 1.0.0 are considered unstable and not recommended for production.
• Installer pipes to a shell. The quickest install path pipes a remote script into sh or PowerShell; teams with stricter policies can use Homebrew, WinGet, Scoop, Chocolatey or a source build instead.
• Hosted services are separate. Deno Deploy is the company's hosting platform, reached via the deno deploy subcommand; the runtime itself is MIT-licensed and runs anywhere.
• Licence. MIT, permissive, with no obligations beyond keeping the copyright notice.

Project activity

As of October 2026 the repository has about 108,800 stars on GitHub and roughly 6,500 forks. It was created in May 2018, is written in Rust and is licensed under MIT. The latest stable release at the time of writing is v2.9.8, published on 21 October 2026, and the main branch is under active development. The crate is published on crates.io, and the project runs a Discord server alongside its blog, YouTube channel and social accounts.

Source code is at github.com/denoland/deno, documentation at docs.deno.com, including the security and permissions guide and Node compatibility guide, the standard library at jsr.io/@std, and the project site at deno.com.