{"slug": "node-js-sandboxes-powered-by-quickjs-and-webassembly", "title": "Node.js sandboxes powered by QuickJS and WebAssembly", "summary": "Wasmer announced beta support for running Node.js applications locally and on Wasmer Edge, powered by QuickJS and WebAssembly, with Node.js compatibility provided by Edge.js. The beta, announced on August 31, 2026, enables running Next.js, Astro, Hono, and Node.js MCP servers without rewriting for platform-specific runtimes. Wasmer chose QuickJS over V8 due to lower startup latency and memory usage, and implemented the JavaScript WebAssembly API by delegating to the Wasmer runtime.", "body_md": "August 31, 2026\n\n# Announcing Node.js Support on Wasmer Edge, powered by QuickJS\n\n###### Syrus Akbary\n\nFounder & CEO\n\nFour months ago [we announced Edge.js](https://wasmer.io/posts/edgejs-safe-nodejs-using-wasm-sandbox): our fully sandboxed Node.js implementation designed to run at the edge using WebAssembly.\n\nThat 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.\n\nAfter 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.\n\nThe beta is powered by QuickJS, with Node.js compatibility provided by [Edge.js](https://edgejs.org/) and faster Node.js workloads with V8 coming soon.\n\n## Why we started with QuickJS\n\nOur initial Edge.js implementation used V8, the JavaScript engine behind Node.js and Google Chrome.\n\nAs we started integrating V8 more deeply into Wasmer Edge, we realized the work required was larger than we initially anticipated:\n\n- We needed to improve our\n**threading execution model** to allow WASIX workloads on V8 - We needed to track the\n**V8 memory usage** separately on our Edge platform - We needed a\n**mature and stable N-API layer** that we could depend on long term.\n\nOur initial N-API implementation was still too primitive for that.\n\nWe also found that V8 had\n\nhigher startup latencyandmemory usagethan we wanted for small applications.\n\nThis is not a new problem. Amazon created [LLRT](https://github.com/awslabs/llrt) for a similar reason: it uses QuickJS to provide lower startup latency and memory usage for JavaScript workloads on AWS Lambda.\n\nBecause 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:\n\n- The full JavaScript runtime could be compiled and distributed as WebAssembly\n- We could avoid requiring a JavaScript-to-native\n[N-API JS bridge on Wasmer](https://github.com/wasmerio/napi/blob/main/src/guest/napi.rs) - We could continue\n**maturing the N-API interface** before depending on it for V8 - Most importantly, we could bring Node.js workloads to Wasmer Edge much sooner\n\n### Running WebAssembly from QuickJS\n\nAs 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.\n\nQuickJS can itself be compiled to WebAssembly, but it does not provide built-in support for running WebAssembly modules from JavaScript.\n\nFortunately, Wasmer is already a WebAssembly runtime.\n\nInstead of embedding an additional WebAssembly interpreter inside `QuickJS.wasm`\n\n, we implemented the JavaScript WebAssembly API (based on `wasm_c_api`\n\n) by delegating execution to the Wasmer runtime already running underneath it.\n\nThe architecture looks roughly like this:\n\n```\nNode.js application\n        ↓\nEdge.js using QuickJS, compiled to WebAssembly\n        ↓\nJavaScript WebAssembly API\n        ↓\nwasm_c_api imports\n        ↓\nWasmer runtime\n```\n\nThe strategy used is similar to what PrimJS (Alibaba’s fork of QuickJS) did to [bring WebAssembly support](https://github.com/lynx-family/primjs/pull/212) to their runtime.\n\nThe 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)\n\nWith 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`\n\n)\n\n``` bash\n$ wasmer run wasmer/edgejs-quickjs # Requires Wasmer 7.2.1\nWelcome to Edge.js 0.0.0-b1feaa2 (Node.js v24.13.2).\nType \".help\" for more information.\n> const wasmBytes = new Uint8Array([\n  0x00, 0x61, 0x73, 0x6d, // magic: \\0asm\n  0x01, 0x00, 0x00, 0x00, // wasm version\n  // Type section\n  0x01, 0x07,\n  0x01,\n  0x60, 0x02, 0x7f, 0x7f, 0x01, 0x7f,\n  // Function section\n  0x03, 0x02,\n  0x01, 0x00,\n  // Export section\n  0x07, 0x07,\n  0x01,\n  0x03, 0x61, 0x64, 0x64, // \"add\"\n  0x00, 0x00,\n  // Code section\n  0x0a, 0x09,\n  0x01,\n  0x07,\n  0x00,\n  0x20, 0x00, // local.get 0\n  0x20, 0x01, // local.get 1\n  0x6a,       // i32.add\n  0x0b        // end\n]);\nconst wasmModule = await WebAssembly.instantiate(wasmBytes);\nconst add = wasmModule.instance.exports.add;\nconsole.log(add(2, 3)); // 5\n```\n\n# Making Edge.js production-ready\n\nRunning real Node.js applications helped us identify and fix many issues in the first versions of Edge.js.\n\nWe made several improvements to **increase stability** and **reduce startup time**:\n\n**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)\n- Added\n**precompilation of JS modules** to allow for 2x faster startup times (this is specially important in QuickJS:[see benchmarks](https://github.com/wasmerio/edgejs/issues/68#issuecomment-4712416406))\n\nengine / lane | cold / disabled | warm precompiled/cache | cold -> warm |\n|---|---|---|---|\n| V8 | 102.4 ms +/- 0.6 | 60.1 ms +/- 1.4 | 1.70x |\n| QuickJS | 195.6 ms +/- 1.3 | 91.5 ms +/- 3.0 | 2.14x |\n\nNode.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)\n\n**Smaller Node.js deployments**\n\nWe now use `@vercel/nft`\n\n(Node File Trace) to trace the JavaScript entry point and include only the dependencies required by it at runtime.\n\nFor one of Wasmer’s Astro websites deployed, this reduced the deployed `node_modules`\n\nsize from approximately 300 MB to 6 MB (uncompressed).\n\nThis makes deployments smaller, faster to upload, and faster to start, while keeping full compatibility for your apps.\n\n### Packaging Next.js applications\n\nWe also created `next-bundle`\n\n, a tool for packaging Next.js applications so they can run serverlessly using Node.js.\n\n`next-bundle`\n\nallows 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.\n\nYou can find it here: [https://github.com/wasmerio/next-bundle](https://github.com/wasmerio/next-bundle)\n\n# V8 is almost here!\n\nQuickJS works well for applications where startup time, memory usage, and low CPU overhead matter most.\n\nHowever, QuickJS is still an interpreter. For CPU-intensive JavaScript workloads, V8 and its JIT compiler are significantly faster.\n\nIn the coming weeks, you should be able to **choose the JS engine that will fit better your workloads**:\n\n**QuickJS**: for lower startup latency and memory overhead**- available now****V8**: for higher sustained JavaScript performance**- available very soon**\n\nWe are actively working on migrating Wasmer’s frontend from Vercel to Wasmer Edge.\n\nThe good news is the frontend already builds and renders correctly on QuickJS without requiring changes to its codebase or build process.\n\nHowever, 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).\n\nBefore rolling out V8 support publicly, we are aiming to run our high-traffic website fully with it to ensure correctness.\n\nRunning Wasmer’s existing Next.js 14 frontend under production traffic gives us a demanding real-world test before making V8 publicly available.\n\nOnce that works with production-quality, V8 support will be open to the public.\n\nWe expect to ship V8 support very soon. Stay tuned!\n\n# How Node.js in Wasmer compares vs Cloudflare?\n\nThe 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.\n\n| Feature / Platform | Wasmer Edge | Cloudflare |\n|---|---|---|\nFull Node.js support | ✅ Yes (except of `node:cluster` ) | ❌ Partial compatibility |\nSpecific Node.js versions | ✅ Yes (v24, v26 coming soon) | ❌ No |\nMultithreading & subprocesses (`ffmpeg` , `pandoc` ) | ✅ Yes | ❌ No |\nSupports Next.js apps (without migrating them to `vinext` fork) | ✅ Yes | ❌ No |\nCode changes required | ✅ None | ❌ Yes |\nSwappable JS engine | ✅ Yes (QuickJS, V8 coming soon) | ❌ No |\nV8 (Fast) Engine | ⏰ Coming (very) soon | ✅ Yes |\n\nYou don’t need to wrap or modify your already existing Node.js applications to run on Wasmer.\n\nThat means that your JavaScript MCP servers or your favorite Next.js apps will work without any modifications.\n\nWhile 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.\n\n## It’s a Beta, we want your feedback!\n\nThis is still a beta release, and there are some important limitations.\n\nAt the moment:\n\n- Node.js 24.x is the only supported Node.js version.\n- QuickJS is the only publicly available JavaScript engine on Wasmer Edge at the moment\n- V8 support is still being tested (and not yet publicly available)\n- Some Node.js modules may require additional compatibility work (\n[node:cluster](https://nodejs.org/api/cluster.html)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.\n\nWe are actively testing more frameworks, packages, and real-world applications.\n\nBug reports and compatibility feedback are especially valuable during this phase.\n\n# Try it!\n\nYou can deploy a JavaScript application by choosing one of the ready-to-use templates:\n\n- Next.js (\n[deploy now](https://wasmer.io/apps/create?template=next-react-server-components&intent=at_YnX3IVtaCPKb),[demo](https://next-react-server-components.wasmer.app/),[source](https://github.com/wasmerio/examples/tree/main/js-next-ssr)) - Astro SSR (\n[deploy now](https://wasmer.io/apps/create?template=astro-ssr-starter&intent=at_A2OPIqtPC5Kg),[demo](https://astro-ssr-starter.wasmer.app/),[source](https://github.com/wasmerio/examples/tree/main/js-astro-ssr)) - Hono (\n[deploy now](https://wasmer.io/apps/create?template=hono-starter-examples&intent=at_7nVEIotGCxQK),[demo](https://hono-starter.wasmer.app/),[source](https://github.com/wasmerio/examples/tree/main/js-hono)) - Express (\n[deploy now](https://wasmer.io/apps/create?template=express-starter&intent=at_ZR4qIGtVCp2Y),[demo](https://express-starter.wasmer.app/),[source](https://github.com/wasmerio/examples/tree/main/js-express)) - Remix SSR (\n[deploy now](https://wasmer.io/apps/create?template=remix-ssr-starter&intent=at_pneGIvtYCr52),[demo](https://remix-ssr-starter.wasmer.app/),[source](https://github.com/wasmerio/examples/tree/main/js-remix-ssr)) - XMCP (\n[deploy now](https://wasmer.io/apps/create?template=xmcp-starter&intent=at_YnZyIPtwClDK),[demo](https://xmcp-starter.wasmer.app/),[source](https://github.com/wasmerio/examples/tree/main/js-xmcp))\n\nOr connect your JavaScript Github repo and let Wasmer automatically build it for you! [https://wasmer.io/new](https://wasmer.io/new)\n\n*I’d like to thank *\n\n[Sonia](https://github.com/sadhbh-c0d3)to pull most of the hard work on Edge.js and QuickJS and\n\n[Arshia](https://wasmer.io/arshia001)to work on the last-mile improvements and many polishes in the last weeks (and congratulate him on his newborn!)\n\n##### About the Author\n\nSyrus Akbary is an enterpreneur and programmer. Specifically known for his contributions to the field of WebAssembly. He is the Founder and CEO of Wasmer, an innovative company that focuses on creating developer tools and infrastructure for running Wasm\n\n###### Syrus Akbary\n\nFounder & CEO\n\nWhy we started with QuickJS\n\nRunning WebAssembly from QuickJS\n\nMaking Edge.js production-ready\n\n**Smaller Node.js deployments**\n\nPackaging Next.js applications\n\nV8 is almost here!\n\nHow Node.js in Wasmer compares vs Cloudflare?\n\nIt’s a Beta, we want your feedback!\n\nTry it!\n\nDeploy your web app in seconds with our managed cloud solution.\n\n##### Read more\n\ncloudedgejavascriptnode.jsedge.js\n\n###### Edge.js: Running Node apps inside a WebAssembly Sandbox\n\nSyrus AkbaryMarch 17, 2026\n\nbenchmarkllvmphpreleaseruntime\n\n###### Announcing Wasmer 6.0 - closer to Native speeds!\n\nSyrus AkbaryApril 25, 2025", "url": "https://wpnews.pro/news/node-js-sandboxes-powered-by-quickjs-and-webassembly", "canonical_source": "https://wasmer.io/posts/nodejs-support-in-wasmer-edge-beta", "published_at": "2026-08-31 16:34:15+00:00", "updated_at": "2026-08-31 16:52:45.652679+00:00", "lang": "en", "topics": ["developer-tools", "ai-infrastructure"], "entities": ["Wasmer", "Edge.js", "QuickJS", "WebAssembly", "Node.js", "Next.js", "Astro", "Hono"], "alternates": {"html": "https://wpnews.pro/news/node-js-sandboxes-powered-by-quickjs-and-webassembly", "markdown": "https://wpnews.pro/news/node-js-sandboxes-powered-by-quickjs-and-webassembly.md", "text": "https://wpnews.pro/news/node-js-sandboxes-powered-by-quickjs-and-webassembly.txt", "jsonld": "https://wpnews.pro/news/node-js-sandboxes-powered-by-quickjs-and-webassembly.jsonld"}}