Deno
Deno 2.9.4 is a JavaScript, TypeScript and WebAssembly runtime based on V8, Rust and Tokio, with package management, tasks, formatting, checking, testing, compiling and default permissions.
What Deno provides
Deno runs JavaScript, TypeScript and WebAssembly with built-in formatting, linting, testing, tasks, compilation and dependency workflows. Deno 2 supports package.json, npm packages and many Node APIs, which can make migration gradual, but native modules, lifecycle scripts, filesystem layouts and edge APIs still need project-level testing.
Permissions and supply-chain boundaries
The default runtime restricts many filesystem, network, environment, subprocess and FFI operations. A broad permission flag removes that isolation, and permission controls do not replace dependency review. Lockfiles, registry choices, install hooks, remote imports and native extensions should be audited as executable supply-chain inputs.
Version and platform notes
Deno 2.9.4 provides Windows, macOS and Linux x64 or ARM64 binaries. Keep the runtime, lockfile, permission configuration and CI result together when migrating a Node project. Review date: 2026-08-23.
Save to your cloud drive
Open the cloud drive to get the file directly, or save it for convenient access on another device.
Quark Cloud Drive
RecommendedSave Deno to this cloud drive
Baidu Netdisk
Save Deno to this cloud drive
Deno 2.9.4 least-privilege runtime and Node migration guide
Run a no-permission script first, grant one directory or host at a time, and migrate a Node project on a separate branch while preserving its lockfile and test baseline.
Before you start
- Select the Windows, macOS or Linux package for the CPU architecture and prepare a test directory without production secrets.
- Record the current Node.js version, package manager, lockfile and CI result on a separate branch.
- List the actual filesystem, network, environment, subprocess, system and FFI permissions the script requires.
Installation steps
- 01
Install and verify the binary
Extract the matching 2.9.4 package, verify its checksum and executable path, add it to the current user's PATH and confirm the version.
- 02
Run a minimal script
Start with a script that prints text, then add one file or network action and observe the default permission error rather than enabling every permission.
- 03
Grant exact resources
Allow only the named directory, host, environment variable or subprocess, and record the permission set as part of code review and CI configuration.
Quick start
- 01
Pin dependencies and sources
Declare dependencies in deno.json, package.json or both, commit the lockfile and review JSR, npm and remote-import sources before execution.
- 02
Run quality gates
Execute formatting, type checking and tests in CI with explicit permission flags, granting network access only to the test service that needs it.
- 03
Migrate one Node workflow
Check package scripts, CommonJS, Node APIs, node_modules behavior and native plugins one by one; keep the original Node path available for rollback.
Usage tips
- A module graph or trusted registry does not replace dependency and install-script review.
- Allowing a script to launch another runtime can widen the effective permission boundary; restrict the executable and arguments or isolate the process.
- Native Node-API packages and FFI require a separate review even when ordinary npm imports work.
Troubleshooting and uninstall
Why does an npm package require node_modules or a native binding?
Determine whether the project needs automatic or manual node_modules behavior, review lifecycle scripts and Node-API bindings, and approve FFI only for a known dependency.
Why does CI fail without showing a permission prompt?
Non-interactive jobs do not ask for permissions. List allowed and denied resources explicitly in the job configuration and add only the smallest missing scope.
- Restore the original runtimeSwitch the Node project back to its verified version, reinstall from its lockfile and run the full test suite before removing Deno-specific tasks.
- Remove binary, cache and test credentialsRemove Deno from PATH, clear caches and build output as needed, and revoke private registry tokens or temporary environment variables used during testing.
Frequently asked questions
Does Deno's secure default make every unfamiliar script safe?
No. It restricts many I/O operations, but modules can still be loaded and a broad grant can expose files, networks, subprocesses or FFI. Use account, container or VM isolation for untrusted code.
Can Deno run every Node.js or npm project unchanged?
Many packages work, but native extensions, lifecycle scripts, node_modules layouts and edge APIs need separate verification. Keep the original toolchain until the project's tests pass.
What is the risk of granting all permissions?
It removes the default I/O isolation. Use it only for a deliberately trusted local task and prefer exact directories, hosts, environment variables and subprocesses in production.