FAQ

Common questions about what NanoVM is, what it can do, and where its edges are.

Is this a full operating system?

Not a full OS with device drivers or a bootloader — but it is built on a real kernel: a shared OS layer (an in-memory VFS, a process router, a bus, capabilities and services) that the runners sit on. It runs Linux programs, not hardware.

What are the runners?

Four execution tiers on one kernel: riscv (the RV64 VM that runs real ELF binaries — the fidelity oracle), node (Node.js on the host JS engine — fast, trusted), wasm (wasm32-wasip1 commands on the host wasm engine — capability-scoped), and boa (sandboxed JavaScript). The kernel routes each program to the right tier; they share one filesystem and never import each other. See Architecture.

Why emulate RISC-V?

The riscv runner is one of the four tiers, and the correctness oracle the faster ones are validated against. RV64GC is a clean, compact instruction set that decodes into a dense dispatch table — ideal for a fast WASM interpreter — with a mature Linux userland and toolchain.

Which Node version is included?

Node.js v25.4.0, with require, fs, path, crypto, http, streams, Buffer, EventEmitter and async/await all working — the real upstream binary, compiled for RISC-V and run unmodified. The npm toolchain bundles npm 11.18.0, TypeScript 5.9.3, ESLint 10.0.0 and Prettier 3.8.1.

Can I npm install from the public registry?

Yes, within limits. There is no raw TCP socket, but outbound HTTP/HTTPS is brokered through the host's fetch(), so npm install can pull packages over HTTPS when the registry returns permissive CORS headers (or you route through a CORS proxy). See the Networking page for the full story and the caveats.

How do I embed it in my own app?

Use the SDK, @userland-run/nano-sdk: a typed, ESM, zero-dependency package that boots the VM and gives you a filesystem, a process API, a shell engine, serve mode, scripting and a worker transport. Start with the SDK overview.

How fast is it?

It is an interpreter, so guest code is slower than native — roughly tens of times for I/O- and allocation-heavy work, up to a few orders of magnitude for tight compute loops. It is comfortably fast for editors, linters, type-checks, small scripts and demos; it is not a production compute runtime. See Performance.

How does it compare to WebContainers?

Both run a dev environment client-side and both need cross-origin isolation. The difference: NanoVM runs the real, unmodified Node.js binary (and other Linux ELF tools) by emulating RISC-V, rather than shipping a reimplemented runtime — and it is open source. The trade-off is emulation overhead. See the side-by-side on the Node-in-the-browser page.

Is it sandboxed?

Yes — guest code runs inside the WASM boundary with no access to the host filesystem or network beyond the small set of imports the host chooses to provide. Scripts run through the SDK's Boa engine are sandboxed further, with capability-scoped access you grant explicitly.

What does the browser need?

A WebAssembly-capable browser. NanoVM uses shared memory, so the page must be cross-origin isolated (COOP / COEP headers) — or you register the SDK's bundled service worker, which injects those headers on hosts where you can't set them yourself.