Four months ago we announced Edge.js: our fully sandboxed Node.js implementation designed to run at the edge using WebAssembly.

That means being able to run applications built with Next.js, Astro, Hono, or even Node.js MCP servers without requiring developers to rewrite them for a platform-specific runtime.

After several months of work, today we are incredibly excited to announce beta support for running Node.js applications locally with Wasmer and serverlessly on Wasmer Edge.

The beta is powered by QuickJS, with Node.js compatibility provided by Edge.js and faster Node.js workloads with V8 coming soon.

Why we started with QuickJS

Our initial Edge.js implementation used V8, the JavaScript engine behind Node.js and Google Chrome.

As we started integrating V8 more deeply into Wasmer Edge, we realized the work required was larger than we initially anticipated:

• We needed to improve our threading execution model to allow WASIX workloads on V8
• We needed to track the V8 memory usage separately on our Edge platform
• We needed a mature and stable N-API layer that we could depend on long term.

Our initial N-API implementation was still too primitive for that.

We also found that V8 had higher startup latency and memory usage than we wanted for small applications.

This is not a new problem. Amazon created LLRT for a similar reason: it uses QuickJS to provide lower startup latency and memory usage for JavaScript workloads on AWS Lambda.

Because the Edge.js architecture is independent from the underlying JavaScript engine used, we decided to ship QuickJS first. This gives us a few important advantages:

• The full JavaScript runtime could be compiled and distributed as WebAssembly
• We could avoid requiring a JavaScript-to-native N-API JS bridge on Wasmer
• We could continue maturing the N-API interface before depending on it for V8
• Most importantly, we could bring Node.js workloads to Wasmer Edge much sooner

Running WebAssembly from QuickJS

As we started testing more JavaScript frameworks with Edge.js (using QuickJS), we found that some applications didn’t work properly because they relied on JavaScript WebAssembly API.

QuickJS can itself be compiled to WebAssembly, but it does not provide built-in support for running WebAssembly modules from JavaScript.

Fortunately, Wasmer is already a WebAssembly runtime.

Instead of embedding an additional WebAssembly interpreter inside QuickJS.wasm, we implemented the JavaScript WebAssembly API (based on wasm_c_api) by delegating execution to the Wasmer runtime already running underneath it.

The architecture looks roughly like this:

Node.js application
        ↓
Edge.js using QuickJS, compiled to WebAssembly
        ↓
JavaScript WebAssembly API
        ↓
wasm_c_api imports
        ↓
Wasmer runtime

The strategy used is similar to what PrimJS (Alibaba’s fork of QuickJS) did to bring WebAssembly support to their runtime.

The main difference is that Edge.js exposes this through a shared runtime interface (N-API), rather than maintaining a separate implementation for every target runtime (JSC, or QuickJS)

With that, we now have a fully running JS interpreter in WebAssembly, that can actually run WebAssembly modules at native speeds! (including those generated by wasm-bindgen)

$ wasmer run wasmer/edgejs-quickjs # Requires Wasmer 7.2.1
Welcome to Edge.js 0.0.0-b1feaa2 (Node.js v24.13.2).
Type ".help" for more information.
> const wasmBytes = new Uint8Array([
  0x00, 0x61, 0x73, 0x6d, // magic: \0asm
  0x01, 0x00, 0x00, 0x00, // wasm version
  // Type section
  0x01, 0x07,
  0x01,
  0x60, 0x02, 0x7f, 0x7f, 0x01, 0x7f,
  // Function section
  0x03, 0x02,
  0x01, 0x00,
  // Export section
  0x07, 0x07,
  0x01,
  0x03, 0x61, 0x64, 0x64, // "add"
  0x00, 0x00,
  // Code section
  0x0a, 0x09,
  0x01,
  0x07,
  0x00,
  0x20, 0x00, // local.get 0
  0x20, 0x01, // local.get 1
  0x6a,       // i32.add
  0x0b        // end
]);
const wasmModule = await WebAssembly.instantiate(wasmBytes);
const add = wasmModule.instance.exports.add;
console.log(add(2, 3)); // 5

Making Edge.js production-ready

Running real Node.js applications helped us identify and fix many issues in the first versions of Edge.js.

We made several improvements to increase stability and reduce startup time:

• Fixed the memory leaks found in the initial releases, allowing applications to handle sustained and heavy workloads reliably
• Simplified and reduced the N-API surface (from 110 unofficial NAPI functions, to ~68)
• Added precompilation of JS modules to allow for 2x faster startup times (this is specially important in QuickJS: see benchmarks)

engine / lane	cold / disabled	warm precompiled/cache	cold -> warm
V8	102.4 ms +/- 0.6	60.1 ms +/- 1.4	1.70x
QuickJS	195.6 ms +/- 1.3	91.5 ms +/- 3.0	2.14x

Node.js uses V8 snapshotting to reduce this timings even further. Edge.js is using bytecode caching as we believe it will be faster on the long run for most apps (similarly to Bun)

Smaller Node.js deployments

We now use @vercel/nft (Node File Trace) to trace the JavaScript entry point and include only the dependencies required by it at runtime.

For one of Wasmer’s Astro websites deployed, this reduced the deployed node_modules size from approximately 300 MB to 6 MB (uncompressed).

This makes deployments smaller, faster to upload, and faster to start, while keeping full compatibility for your apps.

Packaging Next.js applications

We also created next-bundle, a tool for packaging Next.js applications so they can run serverlessly using Node.js.

next-bundle allows us to run existing Next.js applications without requiring the vercel CLI to create a bundle (it forces you to deploy to Vercel), OpenNext, vinext, or another alternative runtime adaptation layer.

You can find it here: https://github.com/wasmerio/next-bundle

V8 is almost here!

QuickJS works well for applications where startup time, memory usage, and low CPU overhead matter most.

However, QuickJS is still an interpreter. For CPU-intensive JavaScript workloads, V8 and its JIT compiler are significantly faster.

In the coming weeks, you should be able to choose the JS engine that will fit better your workloads:

• QuickJS: for lower startup latency and memory overhead - available now
• V8: for higher sustained JavaScript performance - available very soon

We are actively working on migrating Wasmer’s frontend from Vercel to Wasmer Edge.

The good news is the frontend already builds and renders correctly on QuickJS without requiring changes to its codebase or build process.

However, when using QuickJS as the JS engine, the rendering of each page takes about 100ms instead of 10ms (as embedded QuickJS in Wasm engine is not as fast as native JIT’ed V8).

Before rolling out V8 support publicly, we are aiming to run our high-traffic website fully with it to ensure correctness.

Running Wasmer’s existing Next.js 14 frontend under production traffic gives us a demanding real-world test before making V8 publicly available.

Once that works with production-quality, V8 support will be open to the public.

We expect to ship V8 support very soon. Stay tuned!

How Node.js in Wasmer compares vs Cloudflare?

The main difference between Wasmer’s approach to JavaScript on the Edge and Cloudflare’s is that Wasmer’s solution is fully agnostic (it doesn’t tie your apps into Wasmer infrastructure) and supports 100% of Node.js workloads and frameworks.

Feature / Platform	Wasmer Edge	Cloudflare
Full Node.js support	✅ Yes (except of node:cluster)	❌ Partial compatibility
Specific Node.js versions	✅ Yes (v24, v26 coming soon)	❌ No
Multithreading & subprocesses (ffmpeg, pandoc)	✅ Yes	❌ No
Supports Next.js apps (without migrating them to vinext fork)	✅ Yes	❌ No
Code changes required	✅ None	❌ Yes
Swappable JS engine	✅ Yes (QuickJS, V8 coming soon)	❌ No
V8 (Fast) Engine	⏰ Coming (very) soon	✅ Yes

You don’t need to wrap or modify your already existing Node.js applications to run on Wasmer.

That means that your JavaScript MCP servers or your favorite Next.js apps will work without any modifications.

While we deeply admire Cloudflare, we believe this approach offers a stronger foundation for developers who want to run existing Node.js applications at the edge. By supporting unmodified Node.js workloads, applications remain platform-neutral and not tied to any infrastructure.

It’s a Beta, we want your feedback!

This is still a beta release, and there are some important limitations.

At the moment:

• Node.js 24.x is the only supported Node.js version.
• QuickJS is the only publicly available JavaScript engine on Wasmer Edge at the moment
• V8 support is still being tested (and not yet publicly available)
• Some Node.js modules may require additional compatibility work (node:cluster is not yet available on Wasmer Edge, even though is already available in Edge.js)
• Performance will vary depending on whether the workload is startup-heavy or CPU-heavy.

We are actively testing more frameworks, packages, and real-world applications.

Bug reports and compatibility feedback are especially valuable during this phase.

Try it!

You can deploy a JavaScript application by choosing one of the ready-to-use templates:

• Next.js (deploy now, demo, source)
• Astro SSR (deploy now, demo, source)
• Hono (deploy now, demo, source)
• Express (deploy now, demo, source)
• Remix SSR (deploy now, demo, source)
• XMCP (deploy now, demo, source)

Or connect your JavaScript Github repo and let Wasmer automatically build it for you! https://wasmer.io/new

I’d like to thank Sonia to pull most of the hard work on Edge.js and QuickJS and Arshia to work on the last-mile improvements and many polishes in the last weeks (and congratulate him on his newborn!)