Secure Exec vs QuickJS

Secure Exec and QuickJS both run guest JavaScript, but they sit at different layers. QuickJS is a small, embeddable JavaScript engine: you link it into a host process and call its C API. Secure Exec is a full virtualized runtime built on V8, with a kernel, virtual filesystem, and capability policy around the engine. This page focuses on the security and performance characteristics of the core runtime layer.

At a glance

	Secure Exec	QuickJS
Engine	V8 isolate (JIT)	QuickJS bytecode interpreter
Isolation	Virtualized VM in a dedicated sidecar process	Interpreter embedded in your host process
Performance	JIT-compiled, high throughput	Interpreted, smaller working set
Language	Full modern ECMAScript	Mostly ES2023, smaller engine
Node/npm	Real npm packages and Node-compatible builtins	None built in
System surface	Kernel: filesystem, processes, sockets, PTYs	None (host C bindings only)

Isolation model

This is the most important difference.

• QuickJS is an interpreter you embed directly in your host process. Guest code shares the host’s address space, and anything the guest can reach is whatever your C bindings expose. There is no process boundary between guest and host by default, so isolation is entirely your responsibility to build and audit.
• Secure Exec runs guest code in a V8 isolate inside a separate sidecar process, behind a virtualized POSIX kernel. Guest code never calls real Node.js builtins, never opens a real host socket, and never touches the real disk. Every syscall is routed through the kernel and checked against a deny-by-default permission policy.

The practical consequence: with QuickJS you own the entire sandbox, including the boundary, the permission checks, and the host-bindings audit surface. With Secure Exec the boundary, the kernel, and the policy enforcement are provided and run out-of-process.

Process Isolation How runtimes and runs are isolated, and how to choose granularity.

Performance

The engines optimize for different things.

• V8 (Secure Exec) JIT-compiles hot code to native machine code, so sustained throughput on compute-heavy guest code is far higher. The trade-off is a larger engine and a heavier per-isolate baseline.
• QuickJS compiles to bytecode and interprets it. It has a very small footprint and fast startup for a single embedded instance, but interpreted execution is slower on throughput-bound work.

For Secure Exec, cold start is dominated by bringing up the guest runtime rather than provisioning infrastructure, and reusing a live guest process drives warm execution into the low-millisecond range.

Note

Treat these as the shape of the difference (JIT throughput vs interpreter footprint), not fixed numbers. See Benchmarks for measured cold-start, warm, and reuse numbers and the methodology behind them.

Language and ecosystem coverage

• Secure Exec runs full modern ECMAScript on V8, the same engine as Node.js and Chrome, so language features land as V8 ships them. Real npm packages run unmodified inside the VM, resolved over a faithfully mounted node_modules like a real filesystem, and Node-compatible builtins are wired through the kernel.
• QuickJS implements most of the ECMAScript specification in a compact engine, but it tracks the spec on its own cadence and lags V8 on newer features and edge cases. It ships no Node.js standard library and no npm resolution; any package or builtin support is something you bind in yourself.

System surface

• Secure Exec presents a virtualized POSIX environment to guest code: a per-runtime virtual filesystem, a kernel-managed process table (with node:child_process), a socket table for networking, pipes, and PTYs. Guest fetch(), node:http, and raw sockets all flow through the kernel and the permission policy.
• QuickJS has none of this built in. The bare engine exposes only ECMAScript globals; there is no filesystem, no process model, no networking, and no shell unless your host code adds C bindings for them. Every capability the guest needs is host surface you write and must secure.

Child Processes Spawn kernel-managed processes from guest code, or drive a long-running guest program from the host.

When to choose which

Choose QuickJS when you need the smallest possible embeddable engine, you are running short, self-contained scripts with no system needs, and you are prepared to build and audit any sandbox boundary and host bindings yourself.

Choose Secure Exec when you need full ECMAScript and npm compatibility, JIT throughput, and a ready-made isolation boundary with a kernel-backed filesystem, process model, networking, and a deny-by-default capability policy you control.

Process Isolation The isolation model in depth, plus how to pick isolation granularity.