I'm Syrus, from Wasmer. We built Edge.js in a few weeks after different trials trying to bring Node.js to the Edge. We used AI and Codex heavily for this project, as otherwise the timeline would have spanned to a year plus to develop.
The summary of this announcement is that Edge.js:
* Runs using WebAssembly when in `--safe` mode
* It's fully compatible with Node.js (passing all their spec tests for non-VM modules)
* It has a pluggable JS engine architecture: can work with V8, Javascript, SpiderMonkey, QuickJS, Hermes, etc.
Just wanted to chime in to say this is really cool. I dreamed of building something like this for the Extism ecosystem but it was a huge lift to unlock all the pieces. This looks like lots of innovation all the way down the stack. Kudos!
Only the current working directory will be exposed/mounted to the runtime (we do this to facilitate the DX when running local files without requiring the user to add extra flags).
As a fun exercise, you can try reading process.cwd() from edge in --safe mode and without it.
Interesting direction, but the real question is whether this survives hostile, real-world workloads.
Moving isolation into the runtime (WASIX + shims) sounds great for latency, but it also shifts a lot of trust away from the kernel. In multi-tenant scenarios, that tradeoff tends to break under pressure.
The bar isn’t “can it run JS fast”, it’s:
- can it safely run untrusted, adversarial code
- with full npm compatibility
- at high concurrency
- without escape vectors or resource abuse
Concrete question:
Would you be comfortable running something like OpenClaw (multi-tenant agent workloads, arbitrary user-generated code, long-running tasks) on top of this today?
If yes, what are the isolation guarantees and known failure modes?
If not, where does it break first — syscalls, native modules, or resource isolation?
This feels promising for LLM code execution, but that use case is exactly where things get adversarial fast.
The idea, as I understand it, is not to run edgejs multitenant in the sense that have multiple tenants under the same edgejs process. Instead, you spawn one edgejs process for each tenant. So in the openclaw example each sandboxed call would be a new edgejs process.
I still prefer Deno because I don't need a separate npm install command, which makes running code that much easier
Being able to import from "https://my-vpn.com/mypackage@1.2.3" or "npm:package@1.2.3" and just running code without having to worry about scaffolding node_modules makes sandboxing code much easier
Not sure I understand the use cases. I'm guessing people want to run unsafe nodejs code. Either cloud providers like for lambdas or on personal computer for AI coding? On cloud why is this better than firecracker, firecrack can run any programming language this is just nodejs so already useless for that use case?
For personal computer, people worried about the spin up time of docker? I think that is more of a tooling issue where you spin up one instance and run multiple jobs.
What am I missing? What are actually real use cases where this would be better?
Dumb question: could you run this in frontend js using the browser's js engine and wasm environment similar to WebContainers? Maybe `fs` is just in-memory, and some things like forking are disabled. It'd be cool to have "nodejs" in the web!
Ah and kudos to Syrus and his team for this release. Edge.js's architecture seems to have many similarities with BrowserPod. I see it as proof that we are both going in the right direction!
Do you have any specific test case that you would consider "very challenging" on the compatibility side? I'd be curious to check if BrowserPod can support that already.
I don't get it. You mention being able to choose your own JS engine, so it's not using Wasmer's WebAssembly implementation but that of the chosen JS engine's? In other words, can Edge.js use Wasmer? Or have you managed to compile V8/JSC into WebAssembly and are executing it with Wasmer? If so, amazing!
Question regarding the pluggable js engine: I have an electron app where I'm currently using QuickJS to run LLM-generated code. Would edge.js be able (theoretically) to use electron's v8 to get a "sanboxed within electron" execution environment?
naively, based on their install.sh script, you'd pick the correct edge.js executable and shell out to that. I'm sure there's some more integral means, but if you wanted a quick test, that should be easily setup.
Very interesting! On what platforms can this run? If it can run on iOS, how would you handle attempts to access to the file system or networking, is this already wired in somehow? If not is it easy to add custom handlers to handle these actions?
* a refactor of Node.js, but using a standardized API for JS engine interop
* Integration with the Wasmer CLI so it will run JS with v8 but, everything else in Webassembly
Interesting idea.
Could be a much lighter weight way to sandbox JS...
Hi Syrusakbary, I have to admit I still do not fully understand what this is.
First, I could not find usage examples on the edgejs.org page and the docs link points to the node docs, why?
If I head to github, there are some usage examples, but they confuse me more.
The first example: $ edge server.js
led me to think that this is a node replacement that runs in a webassembly sandbox, so completely isolated. But why the need of --safe then? What's the difference between using it and not using it?
But the next examples creates more confusion to me: $ edge node myfile.js
$ edge npm install
$ edge pnpm run dev
What is this doing? I thought that edge was a node replacement, interpreting and running javascript files, but it's now running executables (node, npm)... what is that? What happens when I run npm install... where does it install files? What's the difference between running edge node myfile.js and edge myfile.js?
> I could not find usage examples on the edgejs.org page and the docs link points to the node docs, why?
This was intentional, as a demonstration that Edge and Node should not diverge a bit. You should be able to replace `node` with `edge` in your terminal and have things running, so that's why we point to the Node.js docs.
> But why the need of --safe then? What's the difference between using it and not using it?
Edge.js currently runs without a sandbox by default. The main reason for this is two fold: native currently performs a bit better than with the Wasm sandbox (about 10-20% better), and because we wanted to polish more the Wasm integration before offering it as default.
> $ edge pnpm run dev
> What is this doing?
This is making the `node` alias available for anything that you put after edge.
This allows pnpm to use the edge `node` alias instead of your platform node.
Things will be installed as usual, in your `node_modules` directory
Wow! Node APIs in wasm(wasix)? Something that I have been thinking over for a long time is getting wasm (just wasm, not wasi or com) to be the unit of deployment/packaging for web apps like Nuxt/Next that only depend on, for example SQLite or Postgres. Slightly ignorant question, but would edge.js allow integrating with a caddy plug-in to handle serving the app from wasm?
I know of the extism project and played around with it in elixir, but I'm looking to have CF Workers DX with as little operational complexity as possible for many silly pet projects.
I'm Syrus, from Wasmer. We built Edge.js in a few weeks after different trials trying to bring Node.js to the Edge. We used AI and Codex heavily for this project, as otherwise the timeline would have spanned to a year plus to develop.
The summary of this announcement is that Edge.js:
Super happy to answer any questions you may have!Why is safe mode opt-in?
I think this is a cool demo for you to show, at least in my mind this might be a little mind blowing + maybe a db?
I know there are wasm dbs availble that are very light, but so that maybe it's a plus to consider.
As a fun exercise, you can try reading process.cwd() from edge in --safe mode and without it.
need docs
Curious how this holds up under hostile workloads, especially with native modules and libuv in the mix.
Moving isolation into the runtime (WASIX + shims) sounds great for latency, but it also shifts a lot of trust away from the kernel. In multi-tenant scenarios, that tradeoff tends to break under pressure.
The bar isn’t “can it run JS fast”, it’s:
- can it safely run untrusted, adversarial code
- with full npm compatibility
- at high concurrency
- without escape vectors or resource abuse
Concrete question:
Would you be comfortable running something like OpenClaw (multi-tenant agent workloads, arbitrary user-generated code, long-running tasks) on top of this today?
If yes, what are the isolation guarantees and known failure modes?
If not, where does it break first — syscalls, native modules, or resource isolation?
This feels promising for LLM code execution, but that use case is exactly where things get adversarial fast.
Being able to import from "https://my-vpn.com/mypackage@1.2.3" or "npm:package@1.2.3" and just running code without having to worry about scaffolding node_modules makes sandboxing code much easier
For personal computer, people worried about the spin up time of docker? I think that is more of a tooling issue where you spin up one instance and run multiple jobs.
What am I missing? What are actually real use cases where this would be better?
Dumb question: could you run this in frontend js using the browser's js engine and wasm environment similar to WebContainers? Maybe `fs` is just in-memory, and some things like forking are disabled. It'd be cool to have "nodejs" in the web!
Currently it supports Node, but we plan to add Python, Ruby, git, and more.
You can see it in action in this demo: https://vitedemo.browserpod.io
More info here: https://labs.leaningtech.com/blog/browserpod-10
Ah and kudos to Syrus and his team for this release. Edge.js's architecture seems to have many similarities with BrowserPod. I see it as proof that we are both going in the right direction!
And yes, it will allow running Node.js apps fully on the browser, in a way that’s more compatible than any other alternative!
Stay tuned!
I can see where that's going.
Awesome. I want to msg. you on LinkedIn but can't.
Question regarding the pluggable js engine: I have an electron app where I'm currently using QuickJS to run LLM-generated code. Would edge.js be able (theoretically) to use electron's v8 to get a "sanboxed within electron" execution environment?
We actually believe Edge.js will a great use case for LLM-generated code.
It should probably take a few hours with AI to get a demo for it :)
Roughly:
* a refactor of Node.js, but using a standardized API for JS engine interop * Integration with the Wasmer CLI so it will run JS with v8 but, everything else in Webassembly
Interesting idea.
Could be a much lighter weight way to sandbox JS...
What was the most confusing thing in the blogpost? I'd like to polish a bit more to make it clearer! Thanks a lot!
First, I could not find usage examples on the edgejs.org page and the docs link points to the node docs, why?
If I head to github, there are some usage examples, but they confuse me more.
The first example: $ edge server.js led me to think that this is a node replacement that runs in a webassembly sandbox, so completely isolated. But why the need of --safe then? What's the difference between using it and not using it?
But the next examples creates more confusion to me: $ edge node myfile.js $ edge npm install $ edge pnpm run dev
What is this doing? I thought that edge was a node replacement, interpreting and running javascript files, but it's now running executables (node, npm)... what is that? What happens when I run npm install... where does it install files? What's the difference between running edge node myfile.js and edge myfile.js?
Hope this helps.
This was intentional, as a demonstration that Edge and Node should not diverge a bit. You should be able to replace `node` with `edge` in your terminal and have things running, so that's why we point to the Node.js docs.
> But why the need of --safe then? What's the difference between using it and not using it?
Edge.js currently runs without a sandbox by default. The main reason for this is two fold: native currently performs a bit better than with the Wasm sandbox (about 10-20% better), and because we wanted to polish more the Wasm integration before offering it as default.
> $ edge pnpm run dev > What is this doing?
This is making the `node` alias available for anything that you put after edge. This allows pnpm to use the edge `node` alias instead of your platform node.
Things will be installed as usual, in your `node_modules` directory
I know of the extism project and played around with it in elixir, but I'm looking to have CF Workers DX with as little operational complexity as possible for many silly pet projects.
(A.K.A. are we IBM 360 yet?)