Edge.js: a JavaScript runtime that sandboxes code with WebAssembly

A runtime whose isolation comes from WebAssembly

Edge.js is a JavaScript runtime designed for edge computing and AI workloads. Its defining claim is about safety rather than speed: the project states that Edge.js uses WebAssembly for sandboxing when in --safe mode, so that even the most insecure programs can run on it safely.

That is a different isolation model from a container or a process boundary. The program is not merely confined, it executes inside a sandbox whose enforcement is the WebAssembly module itself, which is the property that makes the runtime interesting for AI workloads where the code being executed was produced by a model rather than written by you.

Four properties define the project according to its own documentation. It is fully compatible with Node.js. It is sandboxed by design. It is pluggable with any JavaScript engine, naming V8, JavaScriptCore and QuickJS. And it is compatible with any package manager, naming NPM, PNPM, Yarn and Bun.

The project is MIT licensed, its homepage is edgejs.org, and the last push to the repository was on 2026-10-07. There are no GitHub releases, so the install script is the supported path to a binary.

Installing with one shell pipeline, then running Node code unchanged

Installation is a single command that pipes a remote script into a shell:

curl -fsSL https://edgejs.org/install | bash

Once it is on your path, the runtime behaves like Node.js. The example the project gives is an ordinary HTTP server written with the node:http module:

const http = require("node:http");

http
  .createServer((_req, res) => {
    res.end("hello from edge\n");
  })
  .listen(3000, () => {
    console.log("listening on http://localhost:3000");
  });

The same file runs with the edge binary in place of node:

$ edge server.js

The Node compatibility claim is doing real work here. The module is required as node:http, the server listens on port 3000, and the only difference from a Node script is the command you type. For a team porting an existing service, that means the migration is about the runtime and its sandbox, not about rewriting the program.

One caveat belongs here rather than in a footnote. Installing by piping a remote script into bash means the code that lands on your machine is whatever the server serves at that moment. If you are putting this into a build pipeline, build the CLI from source instead, which is covered below.

Wrapping your package manager commands with edge

The runtime is designed to sit in front of your existing workflow rather than replace it. The documentation shows the same idea applied to the tools you already use, where edge stands in for the command:

$ edge node myfile.js
$ edge npm install
$ edge pnpm run dev

That single pattern covers most of the day to day work. Scripts run under the sandbox, dependencies get installed through the same package manager you had before, and the difference between a normal run and a sandboxed run is one prefix.

The claim about package manager compatibility is worth reading carefully rather than as a slogan. The underlying reason is visible in the WASIX packaging section: both WASIX packages expose npm as an alias for the bundled pnpm CLI, while the real npm is retained under the name edge-npm-internal, and pnpm's npm-path is configured to point at it for delegated operations. That arrangement exists to avoid recursive calls, where npm as an alias would call back into itself. It is a small detail with a large amount of machinery behind it, and it is the reason the runtime can sit in front of npm rather than asking you to switch package managers.

Yarn and Bun are named as compatible too, though the mechanism described above is specific to npm and pnpm.

The engine underneath is a choice, not a constant

Edge.js does not ship one JavaScript engine. It is described as pluggable with any JavaScript engine, with V8, JavaScriptCore and QuickJS named as the options.

That is the design decision with the widest consequences, and it cuts both ways. In favour of it, you can pick the engine that matches your workload or your platform, and the project builds against both native and WebAssembly engine variants. The build system reflects that: the Makefile has separate targets for native V8 and native QuickJS, for the QuickJS WebAssembly build, and for the N-API layers in both forms, along with framework tests that run across engine variants.

Against it, engine-dependent behaviour becomes your problem. Each engine has its own quirks, and the project keeps a set of parity checks for exactly these differences, including examples named for a string decoder mismatch and a buffer and string decoder parity check, plus smoke examples for dns, events, http, net, runtime modules and url and querystring.

If your application depends on Node.js specific behaviour rather than the standard library shape, the engine you choose matters, and you should expect to run the compatibility tests rather than assume parity.

A WASIX package that borrows the host's engine instead of embedding one

The most interesting part of the project is the host-JavaScript WASIX package. The root wasmer.toml describes an engine-free package named syrusakbary/edgejs. Its WebAssembly module imports the standard N-API surface from napi and the EdgeJS extension surface from napi_extension_wasmer_v0, and it does not embed QuickJS or V8. A compatible host provides those imports using its own JavaScript engine.

In practice this means the runtime can be delivered as a small WebAssembly module that does not carry an engine inside it. The host, which already has one, supplies it. The alternative remains available: the embedded QuickJS package is published separately under quickjs-wasm/.

Building and validating the engine-free package takes three steps:

make build-wasix
make validate-wasix-imports
wasmer package build --check .

The documentation states that the build runs the import and engine validation automatically, so the explicit validation target is there for when you want to run it directly.

The trade-off is direct. The embedded QuickJS package is self-contained and predictable, while the host-engine package is smaller and reuses what is already there. You give up the guarantee that the engine behaves the same everywhere.

The host-engine mode is experimental, and says so

The project does not hide the rough edges of the host-engine mode. It is described as experimental. Two specific documents are named: the buffer ownership and synchronization contract, recorded in a plans directory under the dev_007 host JavaScript imported N-API work, and the deferred security work in SECURITY-HOST-JS-NAPI.md.

Buffer ownership is the specific hazard. When a JavaScript engine and a WebAssembly module share memory, the rules about who owns a buffer, who frees it and when the two sides must agree about synchronisation have to be exact, and the project has written that contract down as an evolving document rather than a settled guarantee.

The security work being recorded as deferred is a second signal. It is a work item, tracked in the repository, not a resolved issue.

There is also a browser regression gate, and its scope tells you what is being protected: package installation, timers, promises, workers, networking, HTTP, and a rendered Next.js development preview. That last item is a good signal of the project's ambition, since running a Next.js dev server inside the sandbox is a much harder target than a hello world server, and it is the closest thing in the documentation to an end-to-end statement of what the runtime is meant to support.

The roadmap puts production readiness in 0.x

The public roadmap in the repository is organised by version line, and it is the most honest document in the project.

The 0.x line is about production readiness: platform coverage across Linux, Windows, macOS, iOS and Android, reliability in constrained environments, security audits, and successful real production use. The 1.x line is about speed, with faster startup, faster core paths, and performance that competes with or beats Node.js, Bun and Deno on most workloads. The 2.x line covers enhancements, specifically first-class TypeScript support and a smoother developer experience.

Read that as a statement of what exists and what does not. The runtime today is a compatibility and isolation story, and the performance comparison with Node.js, Bun and Deno is a goal for a later line rather than a present claim. Nobody has published a benchmark comparison, and the repository does contain a benchmarks directory, so treat the gap as work in progress rather than an endorsement.

The building blocks for working on it are in place. The repository carries ARCHITECTURE.md for design detail, RELEASING.md and release-please configuration for the release process, VERSION.txt, a flake.nix and a rust-toolchain.toml, an ssl-certs directory, a bin-compat directory and an examples directory. Contributing goes through a public roadmap issue.

For a build from source, the CLI is a clone with submodules followed by a make:

git clone --recurse-submodules https://github.com/wasmerio/edgejs.git
cd edgejs

make build
./build-edge/edge server.js

The Makefile defaults the output directory to build-edge, the archive name to edge.zip and parallel jobs to 8, and it exposes the test entry points, including a Node.js test harness run against the built binary.

Editorial conclusion

Edge.js suits teams that need to run untrusted or generated JavaScript close to the user, and platform engineers who want a Node.js compatible runtime with a WebAssembly sandbox and a pluggable engine rather than one fixed engine. It is the wrong choice for a team that wants a production-ready runtime today, because the project's own roadmap still lists production readiness, security audits and real production use under 0.x, and for workloads that need the fastest possible startup, where the 1.x line is explicitly still ahead. Verify three things first: that your dependencies survive the sandbox in --safe mode, that the engine you plan to use is one of V8, JavaScriptCore or QuickJS as configured, and whether you need the experimental host-engine mode, whose buffer ownership contract and deferred security work are documented as unfinished.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. wasmerio/edgejs on GitHub